Is there a Gold Standard for Data-at-Rest Encryption?
So you had a breach – was your data encrypted? NO? Let the media shaming and lawsuits begin. So it has gone with recent breaches, and many organizations are responding with new encryption projects. Summary of discussion: Encrypt data in motion? Check. Encrypt mobile devices? Check. But what about applications, databases, server volumes, files, network storage and backups? Is that required? Can we do it? Can we afford it?
KEY: Attacks – P: Physical – L Logical – A Admin – Challenges: D: Develop – C: Compatibility – S: Platform Support – F: Feature loss – * Limited
Figure: Encryption in the IT Stack
A gold standard with clear guidance for data-at-rest encryption remains elusive. The figure above references what we have for increasingly prescriptive, widely-tracked US regulatory guidance. Along with performance and usability therefore, regulatory interpretation is a ubiquitous deployment challenge. Let’s dive in.
Get out of Jail Free Card
Some enterprises view their immediate problem as obtaining a “get out of jail free card.” They want to be able to say that “The laptop lost in the taxi cab with a trove of personally identifying information (PII) aboard was encrypted. No need to notify the public, according to many jurisdictional breach regulations.” But what if the credit card numbers that were on the laptop start getting exploited? Now the organization will have to notify. But at least it can answer the reporters: “Yes, the data was encrypted.” Check (for now).
The Court of Public Opinion
SSL and end user device-level encryption are broadly supported; an organization may well deserve to be pilloried if it does not at least have them. But what if a cyberattack strikes the credit card database on the server and it was not encrypted? Even if it had been in place, database encryption may not prevented a breach such as Anthem’s. When it comes to security in the server/storage infrastructure, technical questions get murky fast. The news media will lump all the should-have-encrypted scenarios together. That is not fair to those who do not encrypt, and (perhaps) gives too much credit to those that do encrypt.
A Patchwork of Regulations
Interest in encryption isn’t just driven by breaches, but also by regulations. So-called data residency laws are spreading across the globe, imposing a range of requirements on businesses. Some countries try to actually prevent citizens’ information from being stored outside their physical borders. Others seek to protect citizens’ PII wherever it goes, and encryption is one of the controls that may at least be encouraged to provide that assurance.
Regulations are in flux. Long-anticipated European privacy regime revisions will one day come into force. Meanwhile, the US has emerged as a hotbed of regulatory activity at the State level. In a change from earlier market-based approaches focusing on breach disclosure and risk management rather than prescribing technical controls, two states clearly mandate data-at-rest encryption. More are coming. According to a privacy officer we’re working with at a client site “Over 170 pieces of legislation are currently in process.” With lawyers and legislators wading into deep technical waters they’d once avoided, a tsunami of global regulatory confusion will likely result.
To the confusion one must add the enforcement dimension. Two clients we’ve worked with recently have performed global data residency law studies focusing on the countries where they do significant volumes of business. One of the studies addressed whether the laws in each country were enforced as well as their content. We expect a heavy report to drop on our desks soon, but it will be obsolete on arrival, so fast do these factors change across any set of more than 25 countries. Hopefully the report will recommend and provide guidance on organizational processes to keep itself up to date 🙂
Finding the Common Denominator
In the absence of a clear regulatory standard, the lowest common denominator could be encrypting data-at-rest to whatever layer of the stack has the lowest cost/benefit or risk/reward ratio. Or to the high bar set by all applicable and specific regulations. Since the encryption stack figure is conveniently ordered to reflect both market adoption and US regulatory guidance – which are relatively consistent – our direction seems clear.
Mature the Encryption Program and Move up the Stack
In general, Security Architects Partners offers the following recommendations here and in the sections below:
- Bring your team up to a basic technical understanding of the technology behind the encryption layers stack as well as the challenges and tradeoffs at each level. This article (and the Related Reading below) provide good starting points.
- Implement data-in-motion encryption as ubiquitously as possible in your environment.
- Implement end user device encryption for all organization-owned client systems. Understand that although end user device encryption only protects against physical attacks when equipment is lost or stolen, it covers physical attacks more thoroughly than higher layers of encryption that don’t protect swap space or temporary storage for device hibernation (e.g. data in use).
- Centralize key management and follow the good practices in the NIST 800-111 report referenced below. This will be even more important as a basis for maturity moving further up the stack.
For bring your own device (BYOD) scenarios: While some organization-controlled containerization solutions offering encryption are available for user-controlled devices, it would be risky to rely on them as your sole compliance-related control. Use policy, process, and data loss protection tools to ensure PII or other regulatory-sensitive data doesn’t reach the BYOD environment.
Go the Extra Mile (Into the Infrastructure)
Cheers. After covering end user devices, the organization will have complied with the most specific and obvious US regulatory guidance. But also:
- Implement backup media encryption (or very secure offline backup) for both end user devices and servers.
- Seriously consider implementing storage volume encryption for servers, SANs and public/private clouds. Note: Some may ask, who’s going to break into our guarded data centers and steal our hard drives, anyway? However, in some public/private cloud environments, an administrator with the right access might all-too-easily be able to snapshot entire unencrypted storage volumes and post them online to the public Internet…
Awesome. At this point, as long as the organization can verify through reporting that the technology works correctly, you are able to answer the reporters – “Yes! The data was encrypted” – for the most common technical breach scenarios. That should buy a reprieve in the court of public opinion – at least until less-technical people learn that these layers matter, and to ask more questions.
Buy the Organization Some Flexibility at Low Risk
Finally, seriously consider implementing file and folder encryption as a hedge against future compliance needs and to get more flexibility for targeted security risk reduction. File encryption technology is quite mature and relatively low risk to deploy. Although not as transparent or granular as database- or application-level encryption, file encryption offer some protection against logical attacks. But like all layers it’s vulnerable to malware running in the user or service account, and perhaps to administrators (depending on how it’s set up).
Take a Step Back as you Consider Database or Application Encryption
Many organizations could use a shared transparent database encryption capability to cover PII or sensitive data encryption for many applications. This capability is similar to file encryption, and entire database table encryption may even be provided by the same file and folder solution we already discussed. Transparent database column encryption, on the other hand, can help address specialized separation of duty requirements for administrators. But you should also be looking at database audit and protection (DAP) tools, access management systems, masking, tokenization and other alternatives as well.
Finally, consider application encryption in cases where one business unit has higher (or very different) security requirements than rest of the organization and doesn’t want to aggregate risk in shared database, file or storage encryption solutions at a lower layer. A development team ready to tread the application encryption waters may be given leave to do so, and could still consider using a centralized key management system with sufficient assurance.
Bottom Line
As regulations tighten and reporters wise up, it is important for organizations to build mature encryption and key management capabilities up to the file and folder level or higher. Make these capabilities available as services to the internal stakeholders. For multinational corporations, develop a process through which regional or country-level legal counsel and data protection officers track local regulatory developments to make the business case for consuming encryption services, or requesting changes. Once this framework is implemented, organizations have a get out of jail free card for some scenarios. They can answer “Did you encrypt the data?” affirmatively. They will be ready as regulatory requirements become more stringent and prescriptive, and the questions get more pointed. While they are it, the right level of encryption combined with the right complementary controls should also prevent many a breach.
Related Reading
One Response to Is there a Gold Standard for Data-at-Rest Encryption?