Securing Data at Rest with Encryption

What is Data at Rest?

Data at Rest is data collected in a single place – be it on a file server, a workstation, a database, a USB stick, or the cloud. Data at rest tend to have a logical structure that betrays its contents and value, i.e. credit card information, bank account numbers, personally identifiable information (PII), and non-public information (NPI). Compared to data moving across a network, or data in transit, data at rest represents an easier target for hackers and threat actors.

Protecting Data at Rest

An organization must be able to answer the following questions before it can implement effective protection mechanisms for its data at rest:

1. Where does the data reside?
2. How is the data classified?
3. What is the format of the data?
4. Who has access to the data or requires access to the data?

Answering these questions equips an organization with the knowledge needed to enact a multi-level, circumspect data protection policy. Such a policy would have different rules for protecting employee documents stored on USB sticks vs. protecting financial records in a cloud database. However, two key principles are at the heart of both policies: encryption and role-based access control.

What is Encryption?

Data encryption is simply the process of translating data from its original format into a new format that unauthorized parties cannot make sense of. Suppose an employee saves a scan of a client's purchase order to their workstation. Such purchase orders can contain sensitive information, including payment and location information. If this data were to fall into the hands of an unauthorized party, the consequences for the employee's organization could be disastrous.

Data encryption is an integral procedure of any policy designed to adequately protect such data. If an attacker or threat actor somehow managed to exfiltrate an encrypted copy of the aforementioned purchase order, they would be unable to decipher its contents. By encrypting such data at rest, an organization can ensure that its data remains secure.

Encryption of Data at Rest

Regardless of the industry or the nature of the data being protected, the current best practice is to use encryption compliant with guidelines set forth by the National Institute for Standards and Technology – Federal Information Processing Standards (NIST-FIPS). These guidelines were originally developed for use by the federal government, but organizations in the private sector have begun using them to ensure their data is as secure as possible.

NIST-FIPS recommends encrypting your sensitive data with Advanced Encryption Standard (AES), a standard used by US federal agencies to protect Secret and Top-Secret information. Most commercial encryption products feature at least one implementation of AES.

FFIEC Encryption Guidelines

Another framework to use alongside NIST-FIPS is the cybersecurity framework set forth by the Federal Financial Institutions Examination Council (FFIEC) in conjunction with the Gramm-Leach-Bliley Act (GLBA). This framework stipulates that encryption of data at rest should be implemented such that:

• Encryption is of sufficient strength to protect information from disclosure until such time as disclosure poses no material risk
• Encryption is reliable and robust
• Endpoints involved in encrypted communications are secured
• Key management policies and procedures are well-defined, comprehensive, and effective

FFIEC Key Management Guidelines

The FFIEC guidelines state that key management should include a well-defined key lifecycle, e.g. key generation, pre-activation, activation, expiration, post-activation, escrow, and destruction. In addition, there should be policies and procedures governing physical and logical access to key servers. Finally, access to encryption keys should be governed by a user or role-based access policy.

Under the FFIEC guidelines, the aforementioned encryption keys should be:

• Logically and physically separated from the data that they protect
• Encrypted with a separate “key-encryption key”
• Stored inside of a dedicated key manager application
• Located in an environment that is physically and logically separated from and inaccessible to unauthorized users

Various Methods for Encrypting Data at Rest

The appropriate methods for encrypting data at rest vary depending on the format of the data. For instance, many contemporary databases support cryptographic operations on the data they contain, allowing for encryption at the level of a database record. Database encryption can be broken down even further, in some cases allowing for column-level encryption. Similarly, solutions for both symmetric and asymmetric database encryption exist.

Disk and filesystem encryption is more appropriate for devices not associated with a database, such as workstations, USB sticks, SANs, and fileservers. Options in this domain include software-based encryption, hardware-based encryption within the storage device, and hardware-based encryption. Many of these solutions allow for either disk-based or filesystem-based encryption.

Encryption in the cloud differs from the aforementioned methods in that it is usually provided as a service by a tenant's cloud provider. For instance, Amazon Web Services (AWS) provides tenants with the option to create encrypted filesystems for their EC2 instances. The filesystem contents are encrypted with AES using a 256-bit key length. The encryption keys are managed by AWS Key Management Service (KMS), which enforces the tenant's specified permissions while also handling the physical security and durability of the encryption keys. The KMS uses FIPS 140-2 validated HSMs to manage keys. All of these features are provided to the tenant transparently.

Further Reading

NIST FIPS 140-2, Security Requirements for Cryptographic Modules.

• https://csrc.nist.gov/publications/detail/fips/140/2/final
  
  

NIST FIPS 140-3, Security Requirements for Cryptographic Modules.

• https://csrc.nist.gov/publications/detail/fips/140/3/final

NIST Cryptographic Module Validation Program.

• Lists FIPS 140-2 validated hardware and software cryptographic modules.
• https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search

Future-Proofing

If the agency specifies that the information or data be cryptographically protected, then FIPS 140-2 (until September 22, 2026) or FIPS 140-3 is applicable. In essence, if cryptography is required, then it must be validated. Should the cryptographic module be revoked, use of that module is no longer permitted.