Wednesday, June 3, 2009

The Encryption Myth

Rich Mogull had an interesting post yesterday about some trends he has been observing in enterprise security. Rich is a guy with his ear to the ground when it comes to what security processes and products companies are actually implementing. Reading his assessment on the state of encryption got me thinking about why everybody is talking so much about database encryption and why so few people are actually doing it.

There are three encryption trends in particular that caught my attention - 

1. Laptop encryption is being commonly deployed
2. File and folder encryption is not in wide use
3. Database encryption is hard and not in wide use

Let's start with (1). Laptop encryption is the most no-brainer security mechanism out there for any organization dealing with personally identifiable information (PII). 

Do the math. Your organization will lose laptops. Some will contain personally identifiable information. And these days whether you like it or not most thefts or losses will be high profile enough that your legal department catches wind of them. And at that point if they're encrypted your IT department fills out a new PO and everyone gets back to work. And if they're not encrypted all of sudden you have a potential breach notification situation on your hands. Which isn't the catastrophe that security vendors make it out to be (and nothing like the $200-per-lost-record myth you hear bandied around) but unpleasant nonetheless. And certainly a situation that is worth shelling out a few bucks per laptop to prevent.

What about (2) and (3) then? Why is almost no one encrypting their file folders and databases server side?

The truth is that you just don't mitigate that much risk by encrypting files at rest in a reasonably secure environment. Of course if a random account or service is compromised on a server, having those database files encrypted would sure come in handy. But for your database or file folder encryption to actually save you from anything, some other control needs to fail.  

Contrast this with cleartext data traveling through a public network, where no further control needs to fail for your data to be compromised. Or in other words, depending on your definitions you could say that unencrypted Internet traffic is already compromised. This is why https is ubiquitous, while hardly anyone is using database encryption. 

This is not to say that database encryption or file folder encryption is useless - far from it. For the compliance and audit kudos alone there is much to be said for implementing these solutions. But if you only have one play to make, you are much much better off leveraging your organizational capital to actually make sure that your servers are locked down, your database permissions are not too liberal, and that your developers are coding securely. 

In good times it is easier to throw money (or a few extra DBAs) at a problem than to effect organizational change. There are organizations out there that have gone through painful database encryption implementations - with all the performance hit and complexity that comes with it - but have thousands of undermanaged accounts and weak configuration settings because the business owners of those processes are beyond the reach of the CISO. But during a recession, folks are only spending money when there is no alternative internal means of achieving the same goal.

There is also another simple reason for the failure of database encryption to hit prime time while laptop encryption is becoming more and more common. Database encryption - while kinda sorta required/recommended in PCI - doesn't naturally flow from any particular legal requirement. As Rich points out and as supported by the results of the OWASP Security Spending Benchmarks Report, compliance is the number one driver of security spending. Without a clearer regulatory paymaster, database encryption isn't heading anywhere in a hurry.
Posted by Boaz Gelbord at 12:02 AM
Labels: ,

3 comments:

  1. I do agree with the assessment that "The truth is that you just don't mitigate that much risk by encrypting files at rest in a reasonably secure environment." I do however disagree with the perspective that "... for your database or file folder encryption to actually save you from anything,some other control needs to fail." Why? Because file system level and database encryption, of the 'transparent' encrypt the entire database variety, the threat you are really addressing is when something physical containing data leaves the well secured organization. Servers or disk resold without scrubbing or backup tapes leaving the company are two examples. That is the threat model you are addressing.

    If I compromise and account or service, my likely attack vector is to leverage the application and the database infrastructure to help me get data. This may be anything from normal application usage, SQLi from the compromised account/service, or direct, ad-hoc database queries. It is in this case that blanket database encryption completely fails. Once you have compromised and account or credentialed service, the database will decrypt data on your behalf. This is where data encryption, or encrypting data within the database needs to be used. It is this form of encryption that helps address that type of attack, but is rarely used because of cost, complexity, and changes required to application logic. This level of protection can also devolve into a more elaborate game of user authentication ... to get access to the data in this scenario I need to gain access to an account that has permissions to use the data, and one that has access to the keys.

    I think this is part of the reason I am trying to settle on better terminology in the database encryption posts that Rich and I are working on, and a slightly confusing aspect of what we mean by database encryption and, more realistically, what protections you are gaining from taking on the effort.

    -Adrian
    ReplyDelete
  2. Physical theft or loss of a hard drive is definitely an example of a situation where database encryption would save you from a data breach. But that too is a case of a security control failing - failure to properly physically secure your data center or failure to follow the deletion process upon selling equipment. Tightening either of those controls is several orders of magnitude cheaper than encrypting a database.

    I definitely agree on the need for better terminology, since the term database encryption is used in many different ways. But like its cousin full disc encryption, none of the database encryption methods helps you if the account with decryption privliges is compromised. So really you are mitigating against the risk that a different account is compromised.

    This risk is highest when your database is running on a server with a bunch of web-facing apps, but in that case you should be redesigning your architecture before thinking about encrypting the database.
    ReplyDelete
  3. The reality is ...laptops get stolen because the junkie can take it to the local pawn shop for $300 combined with the fact that people have to have the data locally on the laptop.

    If we build database encryption into the lifecycle, it is easy, runs with little overhead and is free, i.e. Microsoft's TDE works great for data in SQL 2008 (AES 256, 3DES). Data in transit is relatively inexpensive to take care of too…Sometime I think we buy into the security vendors trap "you only have so much money, spend it here".
    ReplyDelete

Subscribe to: Post Comments (Atom)