The digital age is upon us. No longer is instant access to information a request – it is a business imperative. The backbone for instant access is the relational database management system. Databases serve as the warehouses of digital information, holding our most critical assets. To properly maintain the integrity and confidentiality of this data, the need for securing databases is growing. And one of the requirements for securing databases is to encrypt the information they store.
Unfortunately, there are many misconceptions surrounding what database encryption is and how it should be performed. Encryption is complex; proper implementations require a grasp of not only the theories behind encryption, but also the practical applications in the real world. All too often, the line between access control and encryption is blurred, and encryption solutions simply supplement the access controls already in place.
No single security solution can properly protect a system. A “defense in-depth” strategy, meaning more than a single layer of security, is required to adequately protect a system. A good example of defense in-depth is a castle. The castle contains multiple defense systems – a moat, castle walls, archers on the walls, etc. Individually, each defense system would not be able to deter an attacker, but combined, the castle becomes very difficult to penetrate.
Before considering implementing encryption, you need to ensure that proper access controls are in place. Database access control consists of creating users, granting them the privilege to act on objects and to perform various commands and tasks. The built-in controls and mechanisms within the database are the best means of providing access control.
Once the proper access controls are in place, encryption of sensitive data should then be implemented. Encryption provides an additional layer of data protection in case access controls are circumvented.
DATA-IN-MOTION VS. DATA-AT-REST
Encryption can be categorized into two types – encryption of “data-in-motion” and encryption of “data-at-rest.” The problems and approaches of each type of encryption are very different. Encryption of data-in-motion hides information as it moves across the network, between the database and the client. Data-in-motion includes traffic moving over your local network, the Internet, or even over a wireless network. The various standards for data-in-motion encryption include SSL (Secure Sockets Layer), TLS (Transport Layer Security) and IPSEC (Internet Protocol Security). Most database vendors have adopted SSL to allow users to tunnel all database traffic using a combination of modern encryption algorithms.
Encryption of data-in-motion is necessary to prevent someone from intercepting sensitive data as it travels between the client and the database, while also preventing session hijacking and replay attacks. These “tunneling” solutions are typically implemented at a session level – the network layer above the protocol being encrypted. When tunneling, all network communications are encrypted as they are being transmitted over the wire and decrypted as they are received at the other end. This provides for true end-to-end protection of the data as it traverses the potentially untrustworthy network.
Encryption of data-at-rest is the encryption of information stored in the database. Encrypting data-in-motion does nothing to protect data that is attacked at the end points. Consider that most attacks do not occur on data-in-motion. Most attacks occur against the end points, where data sits for long periods of time. While encryption of data-in-motion is already widely adopted, even the most “security-conscious” database administrators have not adopted encryption of data-at-rest. Why? It’s always been too difficult, too costly, or just too complicated.
Encrypting Data-at-Rest
There are several possible strategies to encrypt data-at-rest, each has advantages and disadvantages. One strategy encrypts the actual database files at the operating system level. This provides protection from theft of the disk, but can have a serious performance impact, and does not provide for granular user access control. A more efficient and effective way to encrypt information in a database is to encrypt on a column and row basis. This is a relatively new strategy, requiring tight integration with the database. When implemented properly, column and row level encryption solve the problems that have stopped database administrators from implementing data-at-rest encryption solutions in the past.
To better understand this concept, think of a table containing a list of customers, with the following information stored for each:
Customer ID
Customer name
Customer address
Customer credit card number
There is little reason to encrypt the Customer ID in this table; however it is likely that you would want the credit card information encrypted. There are several advantages to encrypting only your most sensitive data, which in this case are credit card numbers. With column level encryption, when the table is searched for a specific Customer ID, name or address, encryption has no performance impact. When matching records are returned, encryption adds minimal overhead, because the only data that must be decrypted is in the credit card column of the returned rows – a small subset of the table data.
Column-level encryption can also protect data from being read by administrators. By separating the roles of security administrators from database administrators, and building the proper infrastructure to protect the encryption keys, data can be secured from even the database owners. For instance, if an administrator can simply reset the password for an account, logon to the account and access the data, encryption has failed to protect the data. Effective encryption solutions need to use additional authentication methods such as passwords or tokens to thwart this type of attack.
One of the most important decisions when utilizing database encryption is selecting which data to encrypt. Database lookups are designed to be very efficient. Unlike typical file systems, databases are expected to look through millions of rows searching for specific items in seconds. This need for fast access and retrieval places additional hardships on encrypting databases. A database cannot afford to decrypt each data element it must search. Therefore, it is critical to consider how applications will use the database while planning to deploy encryption.
The most difficult problem an encryption solution must solve is key management. Very often we see encryption implementations that hard-code keys into a procedure or script. Even with the most robust algorithms and the strongest keys, this implementation provides little security as examining the code will reveal the keys.
Keys must be robustly protected, meaning all keys must be encrypted when stored, with access restricted to their authorized owners. Well designed systems operate largely autonomously, generating, storing and protecting keys with minimal user intervention. Mistakes or weakness in key management can quickly lead to system compromise, making this a critical focus area to evaluate when purchasing or building any encryption solution.
Conclusion
As the demand for more pervasive access to data of all kinds continues to rise, security risks abound. Databases are at the heart of most data storage systems, and therefore require special attention when it comes to protecting data. Encryption layered with proper access controls, vulnerability assessment, real-time intrusion detection and audit provide the strong protections needed for an organization’s most sensitive data, while also satisfying the tough requirements imposed by a myriad of federal, state and industry regulations. By choosing the right tools and using them properly, organizations can harden their defenses and prevent attacks, while continuing to offer ubiquitous connectivity to employees, vendors and partners, ensuring the flow of business continues uninterrupted.
About the Author
Aaron Newman is Co-Founder and the Chief Technology Officer of Application Security, Inc. (AppSecInc). In his current role, Aaron is responsible for defining the overall AppSecInc product vision. Widely regarded as one of the world's foremost database security experts, Aaron is the co-author of the Oracle Security Handbook, printed by Oracle press.