Lessons enterprises should learn from the recent wiki-leak

17.12.2010 by Martin Kuppinger

There has been a lot of discussion around Wikileaks publishing an incredible amount of data which has been classified as confidential by the US Government. I don’t want to discuss this from specifically – many people have done this before, with fundamentally different conclusions. More interesting is what this means for private organizations, especially enterprises. Wikileaks has threatened some of them: The russian oligopolies, the finance industry in general. That comes to no surprise. Wikileaks founder Assange rates them as “bad”,e.g. his enemies. Given that Wikileaks isn’t alone out there, there is an obvious threat to any enterprise. Some might think that construction plans of the defense industry should be published. Others might think that should be done with blueprints from the automotive industry after claimed incidents. Or with the cost accounting of the utilities if power or gas appears to be too expensive. I don’t want to judge about the reasons – I have my personal opinion on this but that’s out of the scope of this post.

Looking at that situation from an enterprise perspective, it becomes obvious that information security has to move to the top of the CIO agenda (and the CEO agenda!) if it isn’t yet there (and given that the enterprise isn’t willing to share everything with the public – blueprints, calculations, whatever,…). That requires approaches which are somewhat more fine-grain than the once which obviously have been in place in the US government, allowing a private (or something like that, I’n not that familiar with the ranks in the US military) to access masses of documents. It also requires to efficiently protect the information itself instead of the information system only. Information tends to flow and once it is out of the system the system-level security doesn’t grip anymore.

That leads inevitably to the topic of Information Rights Management (IRM) which is a frequent topic in the blogs of Sachar Paulus and me – just have a look at our blogs. However, implementing IRM the typical way in organizations requires using centralized policies, classifications, and so on. And classification obviously failed in the last Wikileaks incident. Thus, I’d like to bring in an idea Baber Amin recently brought up in a discussion during a KuppingerCole webinar. He talked about “identity-based encryption” which in fact means encrypting it in a way which is controlled by the single user. That leads to an IRM where the single user controls who is allowed to use information he creates or owns. It is not (mainly) the organization.

But: Will that work? Some arguments and counter arguments:

  1. Information is not accessible once the user leaves the organization: Not correct, there might be an additional “master” key to allow recovery and so on. Many lessons could be learned from Lotus Notes in that area, to name an example.
  2. There are no corporate policies: Not correct, these could be understood as a second level of protection, adding to the first level managed by the user. E.g. classical IRM and personalized IRM could be combined.
  3. It won’t work because the user doesn’t understand what to do: Not correct. Just look at how users are dealing with information security in their daily live. For sure some things are going wrong and lessons have to be learned (not to appear drunken on a photo in Facebook, for example), but overall that works pretty well. Combined with the corporate policies, that should turn out to be much better than corporate policies only. Trust the employee and the wisdom of crowds.

Simply spoken: Think about doing it different than before. It is not about adding new tools at the (perforated) perimeter and all these point solutions. It is about building few consistent lines of defense, including and especially the next-generation IRM. For sure there is some way to go and tools aren’t there yet. But when thinking about how to protect your intellectual properties and the secrets your organizations wants to have (for whatever reason – I don’t judge here…), you should definitely think beyond the traditional approaches of IT security – look especially at Information Security instead of Technology Security, e.g. the I and not the T in IT.

When you think that this topic is worth to think about, you shouldn’t miss EIC 2011 - the conference on IAM, GRC, Cloud Security and thus also about things discussed in this post. And don’t hesitate to ask for our advisory services ;-)


Creating new attack surfaces in VMs and Network Security devices

09.12.2010 by Martin Kuppinger

There is a good reason to add functionality to specific types of devices, especially in the network. Doing security at the edge can be highly efficient. Thus, implementing for example PEPs (Policy Enforcement Points) for access management into network access gateways is, from the perspective of efficiency, a pretty good idea. And when looking at what the network vendors like Cisco, F5 Networks, and all the others are doing, the number of add-ons which can be added to these devices and run locally has increased significantly.

Basically the same, still at a lower level, could be observed around VMs. Hypervisors tend to become more capable of doing things. And especially when looking to client-side hypervisors, there is a slight tendency to add more and more features to themĀ - starting with AV done centrally for many machines and probably ending with supporting the standard user interface at some point of time in the future.

However, as well network devices as hypervisors aren’t really secure by design. If we look at how many specific tools are out there to better protect these devices or software layers and if we look at the risks around privileged accounts especially for network equipment and VMs, it becomes obvious that there is a gap between what these devices or hypervisors can do and how they are protected themselves. Every new feature also provides sort of a new attack surface – in an environment which isn’t the dream of a security guy (maybe it’s the dream of an attacker, but that’s what we want to avoid).

The best would be to make these devices and software layers secure by design. Granular access control, centralized policy management based on XACML, tightly integrated with the provisioning and PxM (Privileged “whatever – user, identity, access, account” Management), standard auditing interfaces which allow integration across devices from different vendors without heavy integration work at the (still too technical) SIEM layer, and so on.

However, that will take some time. In the meantime there are two things you can do: Balance the values and the risks – can you afford to pay the price in security for better efficiency? And protect these devices consistently by management tools, PxM with support for these devices, maybe together with SSO, and auditing and analysis mechanisms.


Services
© 2014 Martin Kuppinger, KuppingerCole