Saturday, May 10, 2014

Key Management Systems & Cloud Encryption

Listening to SANS cryptography session. I've always wondered why there is so much focus on secure code for encryption but not a lot of discussion about key management. I've blogged and tweeted about this mystery in the past and caveat about the first link - I'm digging into cryptography a bit more right now and may be revising:

http://websitenotebook.blogspot.com/2009/05/java-encryption_24.html

http://websitenotebook.blogspot.com/2010/10/securing-encryption-keys.html

http://websitenotebook.blogspot.com/2014/03/encryption-protecting-key.html

Data needs to be protected at rest, in transit and protect the key. If you fail at any one of these your encryption is useless. A lot of people understand the first two. The third is often overlooked and possibly most important, because a short key length still takes some time to hack, but keys out in the open mean you might as well hand the data to the adversary.

Oh and about the "well it's on our internal network behind the firewall" argument, I hope anyone involved in a corporation of any size that is utilizing pen testing services and/or has been breached understands by now this is a completely naïve viewpoint. I used to have to argue with network admins at managed data centers who didn't want to set my outbound traffic firewall rules. Now outbound traffic is one of the primary ways for determining if you're hacked since all malware calls home. APTs have attackers infiltrating systems throughout corporate networks. If they get access to your data you want to have the keys that decrypt that data in a separate place.

So now that we understand that even if our key is in our own house we need to separate it from the data and protect it from people who might get access to the encrypted data, how and where do we store and manage the keys?

We need to store them away from the data, make them accessible to the applications that need to decrypt the data, protect the data in transit and rest (and in memory for things like credit cards on POS machines...)

There are conceptual discussions of protecting the key, and I understand you should put your key on a separate server, away from your data. But what is the best way to actually implement this solution?  What about protecting keys in conjunction with using a cloud provider where you want to protect your keys and have them completely managed by someone other than the cloud provider so anyone that gets access to your encrypted data in the cloud cannot access the keys?

One of the quandaries I have with using these vendors is the Trojan horse concept. If you're keys are the absolute most critical thing you need to protect because they provide access to all your data, giving your keys to a third party system is a bit scary.

One thing would be to make sure very limited amount of people have access to the keys. Additionally through separation of duties you can make sure the same people who manage the keys do not have access to the encrypted data. But how do you actually implement that?

I remember from a business school class a company that outsourced production of certain products to China. Their approach was to have different companies to produce different parts with no single company having access to the complete formula. Perhaps such an approach would work with key management, similar to multi-factor authentication. In order to decrypt you need multiple pieces of information. Of course this adds overhead to processing and slows things down.

The other issue is actually limiting access. After my first graduate degree in software engineering in 2000 I went out to look at technology for a couple of venture capital firms. I didn't have much security knowledge at that point but I remember going to look at some technology from a company one of the VCs was considering for investment. A Russian guy proudly explained how they were able to bypass corporate firewalls by tunneling through SSL ports. This freaked me out somewhat. If these guys can tunnel through an SSL channel which is supposed to be for SSL and completely bypass the firewall, it made the firewall kind of useless. I didn't understand all the ins and outs of networks, ports, packets, etc. at that point but I thought: what's the point of blocking all these ports if someone can use any old port to get into your network?

So clearly blocking access to your keys by just adding firewall rules for ports is not enough. You'll need authentication to limiting access to only specific IP addresses, authorized users and servers and you have to make sure no one can get into the servers, IP addresses or insert a man in the middle attack because then they can tunnel through to your key management store.

Obviously a number of layers of security are needed at different levels to protect your keys and make sure the only applications that should access those keys can get to them to decrypt only the data to which they should have access. There are complications with unencrypted data in memory as well. Thinking about the way SSL VPNs work - they download a thin client and everything runs in an encrypted RAM drive. Maybe something like that could be used for corporate applications running in the cloud.

Going to great lengths to encrypt every piece of data and protect it in every possible way can get very expensive and slow down system performance. Perhaps a better approach is to limit the risk of exposure to a reasonable degree, and add additional layers of detecting any malicious or unauthorized activity. Detection in this day and age of APTs and complexity which can be mind boggling at times, I would argue, is more important than prevention and have mentioned that in my own company in terms of auditing financial systems for data errors. This viewpoint was confirmed in SANS 401 class I took which has the motto: "Prevention is Ideal, detection is a must". So perhaps you limit your exposure and add a lot of auditing and alerts for unexpected activity.

I'm currently listening to Diffe-Hellman key exchange from SANS 401 (sans.org) which operates under the concept of asymmetric encryption and being able to do key exchange in the presence of an adversary. Being able to utilize vendor systems that can provide amazing value in terms of innovation, reduced time to market, segregation, fault tolerance, scalabilty and performance - without - a capital expenditure while minimizing the risk of loss of intellectual property, NPI data and credit cards at the same time is an interesting problem.

For the moment I'll be going through this list of vendors that have key management systems (from Wikipedia) and reading a few books on the matter ... to be continued (I know the suspense is killing you).

http://en.wikipedia.org/wiki/Key_management


Maybe we can get a panel from these vendors to do a presentation at an upcoming Seattle AWS Architects and Engineers meet up:
http://www.meetup.com/Seattle-AWS-Architects-Engineers/