I was recently presented with a customer requirement to protect data in motion, data at rest, data in use, and data disposed. The first and last of these are relatively well defined and straightforward—data in motion is typically protected by using SSL/TLS or IPsec encryption of the data transmitted over the network, and data disposed by ensuring that any storage media is thoroughly wiped before it is discarded. Data at rest and data in use were a little less clear.
One proposed solution was to incorporate encryption by the Storage Area Network (SAN). This would protect data at rest from access by a rogue host or from physical removal of a storage device from the data center, but not protect data in use from rogue users or a compromised server. That is, because the virtual disk appears unencrypted to the server, an administrator on the server who has full access to the file system could see the unencrypted data even if not authorized to do so. (Similarly, if you rely on whole disk encryption on your laptop, you are protected from theft of the device when it is turned off, but if the device is on and your machine is accessed remotely the data is unencrypted.)
By adding file system level encryption, where an agent on the server controls the decryption process (either directly or by offloading the decryption to another server, so that the keys are not exposed on the server), a level of protection is added to keep unauthorized users from accessing the data. There is still risk of compromise from an administrator, as anything exposed to a normal user could potentially be accessed by the administrator, but it can raise the bar.
Clearly, data in use is the hardest to protect since it almost always has to be decrypted and thus exposed in order to be used (with homomorphic encryption systems being the exceptional case).
Another possible mechanism that could have been used was to encrypt more narrowly, such as just encrypting the specific data fields that contained sensitive information (e.g., tokenization of credit card primary account numbers, or using database encryption to encrypt specific columns of data).
For this case, it was important to understand what threats needed to be protected against:
- Were they unauthorized physical access to the drives after disposal? Self-encrypting drives, SAN encryption, and secure erase processes are all capable of offering an easy solution to this problem.
- Were they unauthorized access to the data from another server on the network? Self-encrypting drives, SAN encryption, file system encryption, and database encryption would all do the trick here.
- Were they unauthorized access to the data from a user or an administrative user on the database server? File system encryption that restricts data to some users could raise the bar, as could database encryption, but the best protection here would be encryption outside of the database of the sensitive data, and storing it encrypted, so that the decryption keys and decrypted data are never on the database server.
- Were they unauthorized access to the data from a user on the server where the data is used? Here, file system encryption that restricts to authorized users and database encryption could each provide protection.
- Were they unauthorized access to the data from an administrative user on the server where the data is used in decrypted form? Here, you may not be able to prevent someone with full administrative rights from gaining access, but you may at least be able to detect changes that would be required to do so by auditing the administrator’s activity.
For encryption to protect against a given attack, it needs to be the case that the decryption keys and decrypted data are unavailable to the attacker. In an environment where either the decryption keys or the decrypted data are in use, your main protection is going to be another mechanism—access controls, audit trails, monitoring, and so forth.