Guest Editor: Today’s post is from David Hazar. David is a security engineer focusing on cloud security architecture, application security, and security training. In this post, David will take a look at the encryption options for applications hosted in the cloud.
Over the last decade, due to new compliance requirements or contractual obligations, many, if not most, companies have been implementing encryption to better protect the sensitive data they are storing and to avoid having to report a breach if an employee loses a laptop or if backup media is lost in the mail. One of the more popular ways of adding this additional protection is to implement some form of volume-based, container-based, or whole-disk encryption. It would be difficult to argue that there is an easier, more cost-effective method to achieve compliance than to utilize this type of encryption. Also, although there are potential weaknesses to some implementations of the technology, it is pretty effective at protecting data from incidental exposure or non-targeted attacks such as the ones listed above. So, why does the steady rise of the use of this type of encryption concern me?
As referenced above, there are many legitimate uses for this type of encryption, and if you are looking to protect against those types of threats, it is a good choice. However, many companies and cloud vendors are now utilizing this type of encryption in the datacenter. Let’s review what type of threat we are protecting against when we use this type of encryption in the datacenter. If someone were to walk into a datacenter and walk out with some of the equipment, they wouldn’t be able to read the data on the disks stored within that equipment without breaking the encryption or brute forcing the key (this assumes they were not able walk out with the equipment still running and the encryption unlocked). More realistically, if the datacenter decommissioned some older equipment and did not properly erase the data from that system before selling or disposing of the equipment, this type of encryption would provide some additional protection. Although, even if it were not encrypted, in most datacenters, the data is probably striped across so many disks that the process of mining that data would be painful.
I am sure there are a few other examples of threats that would be mitigated by this type of encryption, but the point I am trying to make is that when the system is running and the disk, volume, or container are unlocked the data is unprotected. So, while you may be able to check “Yes” on your next audit, you would have a tough time claiming data was not exposed if unauthorized parties were able to get access to that system while it was running. The most interesting use of this encryption technology I have seen is to satisfy the need to encrypt database management systems (DBMS) that don’t offer some form of Transparent Data Encryption (TDE). This is especially true in the Cloud.
I will discuss TDE in more detail later, but first let’s focus on encrypting the database using one of the techniques we have already discussed. To shorten the discussion, I will focus on the encryption offered by Amazon RDS for their MySQL and PostgreSQL RDS instances (technically it is offered for Oracle and MS SQL as well, but you can also choose TDE for these types of instances). Here is some text from the Amazon Relational Database Service documentation:
“Amazon RDS encrypted instances provide an additional layer of data protection by securing your data from unauthorized access to the underlying storage. You can use Amazon RDS encryption to increase data protection of your applications deployed in the cloud, and to fulfill compliance requirements for data-at-rest encryption.”
Now the concern here is that the statement is vague enough that most individuals and smaller companies would read the statement, follow the simple enablement guide, and sleep soundly at night assuming that the data is now unreadable. However, if that is the case, how is your application not totally broken? Well, here is another statement from Amazon’s website:
“You don’t need to make any changes to your code or to your operating model in order to benefit from this important data protection feature.”
Great, I don’t have to do anything and now I am protected. Sounds great, right? However, the documentation fails to explain the extent of that protection. The reason your application is not totally broken is because, while the system is running, you have no additional protection. Therefore, you are not protected if someone gains access to the server or in the more likely scenario that you have a SQL injection flaw in your application.
With TDE, you get some additional protection because the DBMS will only decrypt the data as it is being used. Both Microsoft and Oracle offer the ability to encrypt the entire database or tablespace or to implement column-level encryption. However, at some point this data is rendered readable in memory and possibly on disk. While this may be a small concern for some, the larger issue is that, while the database is running, the application has access to all of the plain-text data. The process of decrypting the data is by name and definition transparent to the application. Therefore, we gain no additional protection from injection flaws unless we are following the principle of least privilege when establishing and using database connections within our applications.
Historically, we have used one connection per database and granted this connection all of the rights the application needs to function. In some cases, for ease of setup and maintenance, we have granted these connections even more privileges than necessary. This concept of having single database connection per application is very common and almost universally accepted. One example of this is the recommended “Integrated Security” model of Microsoft SQL Server. This method of connecting to the database is architected in such a way that making multiple connections to the same database is difficult since the connection to the database is made using the credentials assigned to the “Application Pool”. With this model, if the application must read and decrypt sensitive, encrypted data, then that data must be available to be read and to be decrypted for any database call using that connection.
To solve this problem, there are a few options. You can either manage the decryption of sensitive data at the application layer (more to come on the complexities of this at a later date), you can eliminate all current and future SQL injection vulnerabilities, or you can start following the principle of least privilege when connecting to the database (in a future post and upcoming webcast I will give some specific examples of this technique). While eliminating all current and future SQL injection vulnerabilities would be ideal, it is not always best to put all your eggs in one basket. Therefore, being able to reduce the access provided to the database by the application when making specific database calls can provide additional protection and additional benefits.
For example, if a SQL injection flaw is found in one of your endpoints using a connection string that does not have the rights to transparently decrypt data or that does not have rights to the sensitive columns or tables you are protecting with whole-disk or volume encryption, an attacker exploiting the injection flaw would not be able to access this data. Another benefit of this technique is that it will allow you to focus your code reviews and development efforts on securing the code which is using the connections that provide access to your most sensitive data. In some cases, this may only be usernames and password hashes. In other cases, your database may contain credit card numbers, national identifiers, personal health information, or any number of other sensitive data types. Maybe you are not as concerned about data disclosure as you are about data integrity. In that case, you could limit access to state changing SQL commands and focus your efforts on securing the connections that allow these types of operations.
I am not saying we stop using the forms of encryption provided by cloud providers or built-in to the DBMS. They provide value, they do not require a lot of effort to implement and maintain, and they are an essential part of your defense in-depth strategy. However, as we are increasingly removed from the responsibility to implement these controls ourselves through the use of cloud services, let’s take some time to focus on other potentially more realistic threats to our data and ensure we have protections in place for those as well.
About the author
David Hazar has been involved in information security since he began his career in 2000. In 2007, he took over the infrastructure and security teams for a business process-outsourcing firm in Utah to help them meet their own compliance requirements and contractual obligations and also those of their customers. This is where he began dedicating his time to security and has not looked back. David has worked in a wide variety of industries including government, healthcare, technology, banking, retail, and transportation. Over the last few years he has been focused on cloud security architecture, application security, and security training while working for the cloud services divisions within Aetna and Oracle. David also moonlights as an application security consultant-providing web and mobile application penetration testing.
David holds a master’s degree from Brigham Young University and the following certifications: CISSP, GCIH, GWAPT, GMOB, GCIA, GCUX, Certified FAIR Risk Analyst, ITIL v3 Foundation and the Microsoft Certified Database Administrator – MCDBA