The open-source SecurEntity project grew out of an ongoing engagement we have with a Fortune 100 company. We needed to develop a custom line of business application relating to the management of IT security exceptions. From an implementation perspective, a SQL based solution for storing the application data was appropriate, but there’s a major bureaucratic hurdle in that approach: SQL requires the provisioning of new onsite physical hardware (not a virtual machine), a place in the datacenter to put it, and a commitment for 24/7 infrastructure support. None of those three things was going to be available in the timeframe requested by the LOB team.
SQL in the cloud was the obvious alternative, but we had to meet the security bar for offsite storage of sensitive data. Thus, this is one half of what SecurEntity does: implement a proxy to handle encryption and decryption between an onsite application server and cloud-based SQL in a way that’s transparent to the application code.
It’s our belief that the encrypting proxy alone would be sufficient to meet the formal security requirement (i.e. “data must be encrypted”) that most organizations will apply when in a similar situation. However, careful analysis shows that encryption alone isn’t enough to ensure that the data can’t be maliciously tampered with in subtle ways. For example, by swapping two encrypted rows in the DB, could a malicious administrator at the cloud data center affect our IT security LOB application in such a way that an unwanted policy change becomes enacted?
In order to mitigate that threat, the second half of what SecurEntity does is perform a cryptographic integrity check on each object, and the objects it references, each time they’re read from the cloud.
This is an important consideration: encryption alone does not make your data tamper proof. Currently, application-layer solutions such as SecurEntity are the only way to both protect your cloud data from malicious tampering as well as from unwanted disclosure.