Before we proceed with defining a process-oriented method of implementing a data security practice, let’s have a brief technical discussion about the data protection stack. This stack is rather important: I mentioned in my previous post, Fiscal Benefits of increased data utilization, that no other information security strategy, including access control, storage security, or transport security, can provide the same business benefits as data security.
The data protection stack concept was first published in 2008 by Luther Martin in an article appearing on Auerbach’s Information Systems Security web journal entitled Protecting Your Data: It’s Not Your Father’s Encryption. In this article, Martin describes how by that time, 218 million people had been victimized by breaches of sensitive data—and things have not gotten better since. He also proposed a data protection stack based on the same concepts of the International Organization for Standardization’s Open Systems Interconnection model. Martin’s original data protection stack had four layers.
Martin has revised his model to now include five data protection layers, in the following order: block storage, file systems, databases (including RDBMS and data warehouses), networking, and finally applications. Key to the model is the concept that if a higher level of protection is compromised, all protection below is of no value.What does this mean? Let’s start with the lowest level: block storage protection. This protects data at rest stored on hard drives, including solid state drives and storage provisioned via a hypervisor. Microsoft’s Bitlocker is a brand of block storage protection: Bitlocker encrypts storage blocks and stores the key in the computer’s Trusted Platform Module. If a disk is removed and attached to another computer, the attacker won’t be able to decrypt the drive without said key. This prevents a data breach due to physical theft, something that is increasingly important as we move to cloud or hybrid data centers.
Let’s say a user boots the computer and decrypts the drive. What level of security does Bitlocker now offer? None whatsoever: the authorized user sees only decrypted data and can access the drive normally. So can an unauthorized user who successfully steals an authorized user’s credentials.
Any data protection remaining must be provided by a higher layer, and the next layer is file system protection. This is encrypting files and folders within blocks on disk: operating systems write a directory system to a disk partition of raw storage blocks to create files and folders. Again, once security at this level is bypassed by a user, authorized or otherwise, the protection offered stops.
Going higher up the stack we have database protection, which is implemented as block storage protection of table spaces or in-cell encryption. This protection keeps database administrators and remote operators from snooping on sensitive data in tables. Yet once this system grants query access, data protection at lower levels has no effect.
Martin’s model now includes network protection as the next higher layer. And although this level of protection has improved substantially over the past few years, ostensibly due to the discovery of the Heartbleed bug, data protected during transport over a network is decrypted when it reaches an endpoint. So again, data becomes vulnerable if the data being transported is not itself protected. Which is what we do in the final layer.
The highest level of the data protection stack, application layer protection, provides the most protection. This is where application developers participate in the implementation of a data security practice and protect data within application memory before the data is written to a storage container such as a database, data warehouse, or file system. Even if all security layers below the application are compromised, for example by exploiting an operating system vulnerability to read database table space directly, security is not bypassed.
It is this characteristic of application level data security that provides the robust business and financial benefits we discussed earlier: even if an attacker makes off with data stored outside of the application, no sensitive data is exposed. And we can give third parties access to protected data yet still extract real value, for example the prescription abuse prevention use case discussed in my last post, Fiscal Benefits of increased data utilization.
Martin’s article goes beyond describing the data protection stack, delving into details about how it is possible to still use data in its protected state. He does this by describing Feistel finite set encryption and how this is technology preserves the original data’s format. Please ask questions in the comments which I’ll answer by either replying or writing another blog article. Or both!
In our next post, we’ll discuss how to implement a data security practice based on a methodology using formal processes with feedback metrics. Until then, please let us know if you have experience with application level data security and how that worked for you—the good, the bad, and the ugly: we want to hear about your real-world experiences.
Data security and encryption