February 17, 2009

on H5: how to inject security into the SQL database

In comments to yesterday's H5, "AC2" asked:

Confused by the applicability of this particular hypothesis (and in general all of them)...

Are you primarily concerned with over the wire comms, especially outside the 'boundaries' (whatever they are) of an organisation's network?

If not, then would App to DB communication fall in its remit? H5 is pretty much broken in this space afaik, as such communication IS dependent on underlying infrastructure/ protocols to a great extent.. Unless you suggest that the app encrypt everything apart from the SELECT WHERE FROM etc in the SQL...

Posted by: AC2 at February 16, 2009 03:05 AM

Good question, and here comes a sweeping, hand waving answer.

Security is all-encompassing, top-to-bottom, left-to-right, from the requirements all out. This hypothesis says that the requirement to secure covers the entire space.

"App to DB" comms and SQL fall within that. So the answer is, yes, H5 decidedly covers everything, including SELECT WHERE FROM etc in SQL. That is, there is no point in securing the rest of it if your database is an open love letter to the attacker.

How do we apply this in practice? Here are two answers. The first answer could be called "don't do that!" I personally have not followed the literature on this, because I looked at SQL databases a long time ago (I used to port them into Unix systems, and repair broken ones for desperate clients) and decided they can't be economically made secure. So I don't ever use them. Period. I use things I can secure, which means, I write my own databases. Sometimes, these are known as "flat files" in the industry; I once saw an estimate that something like 30% of databases are of this form.

The second answer could be called "kick-back." Once we decide that the need is for end-to-end security, this changes a lot of things. One of the things is that we assume that the data can become public, or should be able to be public, without any loss. For example, in my digital cash work, if all the server-side transaction databases were viewable by an attacker, it wouldn't mean that he could steal money (although there is an obvious privacy angle here). For second example, refer to any Lynn.std.rant on x9.59 and you will find the same deal, in that because of the analysis revealing miles and miles of processes and steps, it was reasoned that there was no way to keep the stuff unviewable, so the only response was to neutralise the data. C.f., "naked and vulnerable transactions" cannot be protected with encryption.

So to come back to AC2's comment, yes, something is pretty much broken in this space. Whether one thinks it is H5, or whether one thinks it is the original decision to use an unsecurable and unreliable tool is rather a political choice for you. If your job is SQL programming, and you want to keep your job, I know which way you're going to call it, and nobody can fault you for that :) OTOH, if you did set the requirements for security, ... well, how serious was that requirement?

PS: in all the above, where I use the word "secure" I really mean the superset of "reliable", including in this case, security.

Posted by iang at February 17, 2009 03:37 AM | TrackBack

Honored to be mentioned in the blog and forced to respond to the content :-)

First, so the scope of H1 - H7 is 'everything'. Given this one would assume that as per H5, the application shouldn't even trust the Operating System it is running on. As someone has pointed out in your previous blog on this, NSA (!) has said that "secure applications require secure operating systems".

To apply this principle, your 'flat-file' approach would be severely compromised if the app couldn't trust the OS, as the OS could easily leak data out, either from memory or the file system drivers..

Unless of course you have written a JVM-like virtual machine over which your app runs, which in turn encrypts everything including data written to memory except for the CPU caches.. But even you can't be that paranoid ;-)

Clearly some part of payments data can't be public but am yet to see anything in payments applications that looks ANYTHING like your diagram above (though you of course have seen much more!).

Usually have seen payments apps that directly interact with DBs (that are not accessible to other apps/ users) or MQ queues.. And that communication is in turn protected by underlying protocols/ infrastructure that is 'trusted'

Posted by: AC2 at February 24, 2009 01:04 AM
Post a comment

Remember personal info?

Hit preview to see your comment as it would be displayed.