listen to this article:
If there is one constant in the tech news, it is the reality of the varied sorts of individuals and countries who are all trying to steal the most valuable data generated and used by enterprises. When you think about the many defense-in-depth security approaches that organizations are taking to protect their networks — from using firewalls and intrusion protection systems, protecting endpoints, setting up strong passwords, etc. — it’s easy to assume that your data is safe. However, while these approaches are all designed to ensure that the data your organizations create and use to run your business is protected, there is one fundamental question that needs to be asked: Why aren’t businesses doing more to protect the data itself?
Encrypt to Secure Sensitive Data
We should take at face value that there are two primary types of attitudes toward encryption that organizations have today: one, of those organizations that are taking steps to strategically think about securing their data because they have been breached; or two, of concerns among those organizations that may have been breached but just don’t know yet (e.g., the SolarWinds breach). ) No matter what type of organization you and your team hail from, however, it is clear that encryption and the measures taken to secure both the access and usage of those keys are crucial security elements that organizations must consider implementing to prevent unauthorized access to your most sensitive data.
This is as basic as it gets in breach prevention. If you encrypt, in theory, you secure – but additional consideration must be taken on how best to manage and secure the keys that are used to decrypt sensitive data.
The Challenges with Enterprise Wide Encryption
According to the Ponemon Institute 2020 Global Encryption Trends study, just 48% of organizations have an encryption strategy which applies across the organization. Having a enterprise-wide strategy does not imply that encryption standards, usage policies, access controls, etc. can be uniformly applied across the organization. At the same time there are many common-sense reasons to encrypt data, so why aren’t more organizations encrypting all of their sensitive information and ensuring that the keys that protect that data are managed with trust? The reason is fairly simple: it’s hard to do and it’s difficult to manage operationally on an ongoing basis. Let’s take a look at a couple of examples of traditional areas of infrastructure that are encrypted: database encryption and virtual machine (VM) encryption.
Database Encryption: Different Vendors
Database encryption is a set of native capabilities that databases like Oracle or SQL Server provide that simply need to be “turned on.” When you turn this feature on (called Transparent Data Encryption or TDE), first you have to manage a key that is generated called the Data Encryption Key (DEK). If you want to report on what is happening with the data encrypted by TDE, you can do so using the native log files provided by Oracle and then again by SQL Server. Not surprisingly, both systems log and record information differently in different formats. Most organizations have more than one database vendor creating a management challenge for each of the encryption keys generated and a reporting challenge for the logs generated by each vendor.
VM Encryption: More Keys to Manage
Similarly, turning on VM encryption is easily enabled in vSphere. Once this feature is turned on two additional encryption keys are created and need to be managed: the DEK to encrypt the VMs and the Key Encryption Key (KEK) that is used to encrypt or “wrap” the DEK. Reporting on what is happening with your VMs is separately available in the native audit logs provided by VMWare. Similar to the database encryption challenges described above, now there are two more sets of encryption keys to be managed and another vendor’s log file format to contend with for reporting.
The above provides a window into some of the challenges organizations face when attempting to just encrypt just two fundamental aspects of your infrastructure. Today, to ensure all of your data is safe, you have to:
- Manage 3-4 separate types of encryption keys.
- Integrate the audit reporting formats provided separately by Oracle, SQL Server and VMWare into your SIEM infrastructure.
Management and Reporting
Let’s take this a step further. Now, what if those databases and VMs need to be replicated across geographies or into the cloud? What if you want to encrypt your storage, or the data your applications consume and create? What if you want to tokenize sensitive data in your database to ensure that if your database is compromised your customer’s PII/PHI is not useable by the attackers?
The challenge described above is simply related to the management and reporting aspect of encryption. I would argue the bigger challenge is how you are securing the keys that can decrypt this data. Many unregulated organizations store encryption keys on the same database server that the encrypted data sits on, or on the same vCenter servers that house the VMs they rely on. For many regulated organizations, there is not an enterprise-wide policy on how to encrypt and where to store/protect these keys. Would you store the keys to your house in the lock to your house or the keys to the safe that protects your personal belongings on top of the safe? Of course, not and by analogy, this is what organizations are doing when they store encryption keys in the same location as the data that those keys are intended to protect.
Managing Keys Centrally
At the bare minimum, organizations should consider managing their encryption keys centrally. Central management greatly improves an organization’s operational efficiency. If you are simply storing encryption keys on your network, you should bring them into a secure key store – ideally one that is software based. If you take this tact, we recommend selecting a key orchestration platform that enables you to:
- Apply your encryption policy uniformly across your enterprise,
- Improve compliance through centralized audit function that will provide details on how cryptography is being consumed across your organization including who is accessing what encryption keys to operate on what data.
Ideally this system would also have the ability to integrate with your SIEM for real-time notification of anomalous behavior.
Preventing Key Misuse
Lastly, if you can, you should be able to apply a policy that prohibits users from accessing key material or performing a cryptographic operation that they are not expressly authorized to perform. (At Unbound, we call such a policy a “cryptographic firewall.”) This mechanism makes prevention of key misuse vs. attempting to stop key theft possible. When compared to traditional key stores that are designed to thwart key theft, prevention of key misuse is a significant security advance. If a key is stolen, it can be used until that key is revoked. Key misuse prevention on the other hand ensures that the key is never used but for intended purposes.
Encrypt more of your data. Manage, report, and secure your encryption keys, enterprise wide for all use cases. Protect what bad actors are after: your data. Do so in a way that reduces complexity and risk while greatly enhancing the security of your organization’s most important assets.
Watch our whiteboard session where Professor and Unbound CEO Yehuda Lindell maps out how keys are managed in multiple encryption scenarios.