resources   /   news   /   events
Select Page

    Our Insights

    Thought Leadership and Industry Trends

    Encryption of Data at Rest: Keeping Corporate and Government Information Secure

    October 4, 2016

    By Chris O’Connor, Director of eDiscovery Strategy, CDS.

    Protecting data is a concern for every company. As my colleague, Milton Cervantes, noted in his blog post, “Why your data isn’t as secure as you think”; hosted data is at risk of manipulation, theft and eventual re-sale. In order to increase data security, utilizing encryption of data at rest is crucial. Data at rest generally refers to data stored in persistent storage (disk, tape). Encryption reduces the chance of financial information, commercial trade secrets, and protected government materials reaching the wrong hands.

    Methods for encrypting data at rest

    There are two methodologies for encrypting data at rest: server level encryption and file level encryption. The server level method allows for broad data encryption. Anything stored on the drive which has been encrypted is thus stored in an encrypted “container.” This is satisfactory for data stored behind a firewall, but it can create a number of issues when the container is decrypted. File level encryption allows each individual file to be encrypted and decrypted as needed and offers a higher level of encryption. Depending on the speed of access needed, encrypting at both levels offers the highest level of encryption, but this approach can be prohibitively expensive and, depending on the decryption time, can cause program level time outs.

    With the complications that may arise with data encryption, some may ask whether it is worth implementing. Who should consider the use of encryption of data at rest technologies?

    • Parties responsible for financial data of individuals
    • Parties responsible for commercial secrets
    • Parties responsible for personal health information (PHI)
    • Parties responsible for the hosting of data for the United States Government

    Commercial implementation of encryption of data at rest

    If you are responsible for the first three data types listed above, you should consider how to implement and secure that data utilizing file level encryption of data at rest. Though each party will have their own approach to benchmarking of technology, at the bare minimum, considerations should include: 1) the level of encryption (i.e. how secure is the encryption being used?); 2) speed to encrypt; and 3) speed to decrypt.
    The benefits of encryption are limited when the speed to either encrypt a file or decrypt it are extremely long. Different file operations will dictate to you what a tolerable timeframe is for these operations. If the process takes so long that you cannot access the data in the file before the file program times out, then the encryption software is, most likely, not right for you. Testing performance is a requirement for any implementation of an encryption at rest technology.

    Government implementation of encryption of data at rest

    In a memorandum issued on June 23, 2006, Deputy Director for Management Clay Johnson laid out a four step consideration plan for any device carrying agency information:

    1. Encrypt all data on mobile computers/devices which carry agency data unless the data is determined to be non-sensitive, in writing, by your Deputy Secretary or an individual he/she may designate in writing.
    2. Allow remote access only with two-factor authentication where one of the factors is provided by a device separate from the computer gaining access.
    3. Use a “time-out” function for remote access and mobile devices requiring user re-authentication after 30 minutes inactivity.
    4. Log all computer-readable data extracts from databases holding sensitive information and verify each extract including sensitive data has been erased within 90 days or its use is still required.

    As a supplement to this memorandum, Johnson also attached a checklist compiled by NIST. Though the memorandum set out guidelines to consider what should be protected by encryption, it does not spell out the manner in which that encryption should be applied. Encrypting data at rest allows agencies to comply with the mandate while also maintaining their individual agency’s need to operate. However, intra-agency sharing of encrypted data at rest is one place of potential concern if this technology is adopted.

    So what now? Once you have invested in encryption software, how do you determine what data elements should be encrypted? That will be the topic of our next installment.

    For more information about CDS’ comprehensive focus on security, visit or contact us about your eDiscovery project.

    About the Author

    Chris O’Connor, Director of eDiscovery Strategy, CDS New York

    As the Director of eDiscovery Strategy, Chris O’Connor advises clients on the use of technology in all aspects of the eDiscovery Reference Model (EDRM) from collection through production. He applies his deep knowledge of legal technology and processes to the design of case strategies and workflows to be implemented by clients and the CDS Project Management Team.