Security Laboratory

Security Laboratory

Security Laboratory: Cryptography in Business Series

We are grouping papers in this series to focus on the many facets of data encryption.

Other Related Articles in Security Laboratory: Cryptography in Business Series


The Pitfalls of Full Disk Encryption


Peter Giannoulis
Summary: You cannot pick up a technical magazine nowadays without reading about encrypting data at rest. According to a 2004 Gartner report, roughly 80% of Fortune 1000 organizations will be encrypting most of their data at rest by the end of 2007.[1] Organizations that are currently storing terabytes of data will be taking on a massive initiative to encrypt all of this data within a specified timeframe. Information Assurance managers should consider a few key issues related to full disk encryption before deploying a system.

United States bills, such as the Data Accountability and Trust Act, require organizations to encrypt their data at rest. More importantly though, the Data Accountability and Trust Act requires that organizations contact an individual if their personal information was stolen or used for unauthorized purposes.[2] The Fair Credit Reporting Act was created in 1971 and amended in 1997. Originally it provided guidance on the specific individuals who could actually access consumers' credit report information. The amended Fair Credit Reporting Act of 1997 included revisions under such sections as credit disputes and accuracy.[3] So, the basis for this is that if you're going to store private consumer information you should ensure that this information is secure at all times. But have these organizations taken the time to consider the pitfalls of such a deployment and the impact it's going to have?

Is the network ready for such a deployment? Encrypting data at rest or on the wire causes significant overhead. Many organizations have, or are currently implementing, gigabit networks to ensure that access to data is quicker without the use of encryption. By encrypting data at rest, are the networks that we barely finished upgrading to acceptable speeds ready for such overhead? What about the desktops or laptops that are used to access the encrypted data? Do they have the necessary horsepower to be able to encrypt and decrypt data on the fly? AES allows for three standard key lengths, 128, 196 and 256 bits and all factors being equal, the longer the key, the longer the encryption and decryption time required.[4, 5]

Organizations must consider the repercussions of encrypting all that data at rest. What happens when an encryption algorithm is no longer strong enough? The Advanced Encryption Standard (AES) became the new encryption standard in 2002[4] and it doesn't seem like it will be going away anytime soon due to the strength of the algorithm, but isn't this the same idea we had with regard to the Data Encryption Standard (DES), which was based on the Lucifer algorithm and published in 1977. What happened there? DES was supposed to be strong enough to take us past a certain date, but was abandoned in 1997 as a result of multiple vulnerabilities. [6] Will the same happen to AES? Maybe. What happens when an organization encrypts petabytes of data, and then discovers that the key they have been using for years is exposed or the algorithm is now considered weak? What do we do? We now have to decrypt all of that data and encrypt it again with a stronger key and/or algorithm.

What about key management? Many organizations are having a hard time implementing change control procedures which require that a chain of command be maintained with regard to changes made to the environment. Are we to believe that these same organizations can maintain the keys to decrypt all of the data at rest for the next 10, 15, even 20 years? I'm sure that some organizations do a reputable job of maintaining keys, but this is not always the case.

Planning has never been more important as it is when rolling out a solution such as encrypting data at rest. We recommend that you start on a System Development Lifecycle Plan (SDLC)[7]. There are a number of similar ways of describing an SDLC, one is shown below and a fleshed out example done by two SANS Technology Institute students is available here:

  1. System/Information Engineering and Modeling
  2. Software Requirements Analysis
  3. Systems Analysis and Design
  4. Cryptographic System Deployment
  5. Testing
  6. Maintenance

A bit of planning up front may save you a lot of time and money in the years to come. It's one thing to deploy encrypted communications between two corporate offices via a site-to-site VPN tunnel, and another to encrypt every piece of data which resides on your network systems. Wise Information Assurance managers think before they act.


Peter Giannoulis, GSEC, GCIH, GCIA, CISSP, is an information security consultant in Toronto, Ontario, Canada, as well as a Technical Director for the GIAC family of certifications.

NOTE: this research project is still under development. If you have created an SDLC for deploying full disk encryption and are willing to share or if you have links or comments to improve this article, please contact us, stephen@sans.edu.

References
1. http://www.networkworld.com/techinsider/2005/081505techinsider-data.html?page=2
2. http://www.cbo.gov/showdoc.cfm?index=7228&sequence=0
3. http://finance.yahoo.com/creditreports/basics/article/101242/The_Fair_Credit_Reporting_Act_Benefits_Credit-Active_Consumers
4. http://www.cpktec.com/performance.html
5. http://jce.iaik.tugraz.at/de/content/download/767/5659/file/AES%20Product%20Broch%C3%BCre.pdf
6. http://en.wikipedia.org/wiki/Advanced_Encryption_Standard
7. http://www.tropsoft.com/strongenc/des.htm
8. http://www.stylusinc.com/Common/Concerns/SoftwareDevtPhilosophy.php NOTE: this is actually a software development article, but the approach is similar enough to apply
9. http://www.sans.edu
10. http://www.sans.edu/resources/student_projects/200612_001.pdf