Building Up Data-at-Rest Encryption
Previously, Security Architects Partners posted “Is there a Gold Standard for Data-At-Rest Encryption?” We noted that enterprises are under pressure to encrypt data, but the compliance landscape is confusing and the risks or threats actually mitigated through cryptography vary considerably with the implementation. Today, we’ll try to bring more clarity to these questions, and also highlight where a number of solutions – such as Amazon EBS and S3 encryption – can be used as examples.
The above figure depicts data-at-rest encryption – also referred to as infrastructure-level encryption – throughout multiple levels of the IT stack. Both “native” and “3rd party” solutions are available for such encryption.
Various Native Solutions
Native encryption solutions include those built into backup or storage media hardware devices, volume-level encryption software (such as Microsoft BitLocker) or cloud computing platforms (such as Amazon Web Services (AWS) Elastic Block Storage (EBS) encryption and AWS S3 storage encryption). They also include those built into database platforms such as Oracle’s Transparent Database Encryption (TDE) product or Microsoft’s MSSQL encryption product, as well as many applications with built-in encryption.
3rd Party Solutions
There’s no Gartner Magic Quadrant for vendors supporting multiple levels of infrastructure encryption (volume, file/folder, database and application) and multiple platforms (Windows, Linux, Unix, Oracle, Amazon, etc.). The challenges for would-be 3rd party providers constitute the same reasons enterprises require them:
- Breadth of platforms requiring well-integrated encryption
- Importance of centralized and robust encryption key management
- Complexity and variety of international regulations on encryption strength, key length and handling, and technology export
Although infrastructure encryption is still a market in the making, leading providers – such as Gemalto’s SafeNet, Thales’ Vormetric and HyTrust – have found it to be a profitable niche. Even with native solutions – such as Seagate self-encrypting disk drives, NetApp encrypted appliances or Oracle TDE – it’s often beneficial for compliance, assurance and manageability to utilize a 3rd party centralized key management solution that works with the native encryption engine. For example, storing the keys separately from a credit card database is a PCI/DSS requirement.
Picking the Right Level to Encrypt
The infrastructure encryption figure above depicts the way that granularity, transparency and complexity change as we ascend the levels of the infrastructure encryption stack.
- Granularity: Since encryption is basically a way to achieve confidentiality by controlling access to the encrypted (or plaintext) information, the granularity of the cryptographic keys used in the process is an important characteristic. Typically, only a single key is required to encrypt storage volumes or devices, but different database-level or application-level objects each have their own key. Thus, granularity increases the higher up the stack you go. For example, volume encryption can be effective at keeping unauthorized network users or media thieves from getting at the plaintext, but it takes a higher level of encryption to protect against the perils of excessive privileged user access and to meet PCI/DSS (or other separation of duty-related compliance requirements).
- Transparency and complexity: On the other hand, the higher up the stack you go before encrypting the data the harder the job gets. At the database level, searching, sorting and other functions aren’t possible without workarounds such as format preserving encryption algorithms that preserve parts of the plaintext. At the application level, code changes must be made to call encrypt/decrypt APIs. On the other hand, encryption is generally transparent to applications and databases when it is performed at the volume, file or folder levels.
Notes from the Field
Security Architects Partners is currently helping multiple clients tackle encryption, data loss prevention (DLP) and cloud security challenges. Our clients are trying to pick the right level of encryption for each use case, minimize the vendors required and (where possible) centralize key management.
At one client, we are evaluating both native and 3rd party infrastructure encryption solutions for a breadth of use cases:
- Amazon EBS encryption can encrypt boot volumes for Amazon virtual machine instances. Similarly to Microsoft BitLocker (usable for Windows Servers) EBS encryption utilizes embedded key management. Both BitLocker and EBS encryption are delivered free of charge.
- Amazon also offers S3 system storage encryption with 3 choices of key management: embedded/transparent, customer-managed or customer-controlled. The latter choices do create usage-based costs. Functional, cost and assurance tradeoffs must be compared to 3rd party solutions supporting S3.
- Large Oracle-based applications are running in premise-based and managed service environments. In some cases, Oracle TDE is already in use and it has the built-in functionality needed to encrypt transparently for applications. Oracle TDE is a premium product, but the license has already been paid for. Assurance can be improved with 3rd party, centralized key management for Oracle TDE.
- For other use cases, applications must decrypt key material in a key management system to authenticate themselves on the network, or to encrypt/decrypt certain data objects they read and write. A REST-based interface is needed to interface the applications to the key manager.
Large, global enterprises require a mix of native and 3rd party solutions to support the breadth of use cases, platforms, and operational or compliance scenarios in their environments. Before committing funds and other resources, they should develop an architecture that provides logical patterns and guidance for infrastructure level encryption. They should also build a centralized center of excellence to advise developers, operations and key custodians in the business.