Several of you might have heard about the NASDAQ hack in which a few Eastern European hackers managed to cause damage well over a hundred millions dollars. We will show how if NASDAQ has used CipherDB to protect their data, their losses would have been close to zero. The NASDAQ hack revolves around a class of attacks called “SQL injection”. Essentially, “SQL” is the database technology used by most web or server applications to store data – sensitive or not. Developers may note that I’m oversimplifying an otherwise highly technical topic – this is intentional because we have a wide audience here, ranging from deeply technical system architects to non-technical marketing or business leaders.
Before proceeding, another important note of data risk – even if your organization doesn’t place a high value of loss of data, it’s likely your customers or partners or suppliers might consider the loss of data as “very high”. Something to keep in mind as your organization considers its cyber security readiness.
Normal case
Let’s consider a typical online application – something like your bank’s website or your online shopping site. Typically, the user provides some data to the web server via their browser. The web server then accomplishes the user’s task, talking to the database server as needed. Since the NASDAQ case involved exploiting the “Reset my password” webpage, let’s examine that in detail to see what “usually” happens. A picture is worth a thousand words, so we use illustrations to show what goes on.
Usually, a User enters their email address and the application server (or web server) stores this information in the database. A secure link is created which is emailed to the user’s email address. The user logs into their email, clicks the link and simply generates a new password.
Clever hacker case
A clever hacker notices that a user has full control over specifying their email address. A server application may not perform a rigorous check on those inputs, so a hacker can do some investigation to see what works and what doesn’t. A carefully crafted input can be quite damaging, as the next figure demonstrates.
Essentially the hacker “injects” additional SQL commands into what should have been just data. This alters the normal processing of the server application and a hacker can accomplish things not originally envisioned by the developer (usually bad things). In this case, the hacker is able to inject some commands that just grab some social security numbers (or credit cards). This data is then conveniently emailed by the compromised application server back to the hacker at some (presumably) throw away email address. The specifics of the hack change with the creativity of the hacker, so instead of emailing back the sensitive data, some hacks might display the data in the browser itself (if possible) or send to some log file or upload to a file elsewhere.
CipherDB protection
With CipherDB the protection comes in multiple layers. As a reminder, with CipherDB, all sensitive data on the database is encrypted via military grade cryptography and the encryption keys themselves have multiple layers of encryption and isolation. CipherDB’s data protection is for both data-at-rest as well as data-in-transit.
Layer 1 protection – ORM
CipherDB builds upon a fast and popular Database API – Microsoft Entity Framework. Technically, it’s an “ORM” and all input is “parameterized” before it’s sent to the database server. Parameterization simply means that some sanity checks are made and no SQL commands are allowed to be “injected” as data. This means a hacker attempting to do so will run into an error thrown back by the server application.
Layer 2 protection – Strong cryptography and secure key management
Even if Microsoft Entity Framework is compromised or the database is accessed from another point of breach, a second layer that is 100% within CipherDB kicks in. This second layer of encryption is one involving AES encryption at 256 bits, used in GCM mode to obtain authenticated encryption. Authenticated encryption is far stronger than regular encryption since it’s both tamper-resistant as well as tamper evident. As we’ve said before, even the NSA considers this secure enough to protect TOP SECRET military data. In fact the laws of physics and computational science dictate that breaking AES 256 encryption would require all the energy of the known universe and about 5×1050 years (five followed by 50 zeros). That’s five hundred thousand, trillion, trillion, trillion, trillion, trillion years. For comparison the universe is estimated to be about “just” 16 billion years old. If your data security lifetime exceeds the lifetime of the universe, please get in touch with us, we want to know more about you 🙂
The point is, this layer 2 protection ensures your data is always safe and protected. Both level 1 and 2 are illustrated above.
Beyond SQL injection
A major point to make is that CipherDB goes beyond just SQL injection protection. By bringing in strong cryptography at a very fundamental level, it protects against almost every conceivable data security attack. We advise against the following experiment but even if your SQL server administrative credentials were leaked and someone was to download the entire database onto their system, they would not be able to decrypt or see your sensitive CipherDB protected data.
Conclusion
Had NASDAQ used CipherDB’s database security software, they could have saved themselves 100+ millions of dollars’ worth of damages. As organizations rely more on cloud computing and interconnected systems, they must take the necessary steps to protect their data in the best possible manner possible. For most organizations data breaches involving sensitive data is a matter of (business) life or death. Much like auto insurance, you don’t want to get into an incident and then wish you had some insurance coverage.
About CipherDB
At Crypteron, we would love to get your organization started with CipherDB to protect your data. Get in touch with us today and we’ll get you started.
