Data security: don't be blind to the big picture

I've been told that I should start this first post with a comment indicating that this is my first post. OK, that was fun - I'm glad that is over with.

I read an interesting editorial this morning on the issue of database encryption that got me thinking about the parable of the 6 Blind Men and the Elephant. In the editorial, the author discusses the possibility of using database-level encryption as a means of protecting sensitive data from a user who was not allowed to see it.

What got me thinking was the fact that the author, who has worked or is currently working as a DBA, takes an approach that I think overemphasizes the importance of database security features in addressing data security while not addressing other areas of greater risk. He can be forgiven for this view - from my experience, DBAs tend to be very smart but very narrow in focus. Of course a DBA would attempt to address problems from the perspective of the database - it's what DBAs know and work with every day and it's what they are most comfortable with. So in that way, DBAs are describing the "elephant" of data security using the knowledge that they have "in hand".

While I won't claim to be able to see the entire elephant, I do believe that there is much more to data security than simply configuring database security settings. Most people would agree that when managed well, relational database management systems offer an extremely secure environment for sensitive data. Through the use of features such as authentication, authorization, permissions (user-level and group-level) auditing, and more, it is very, very difficult to accomplish unauthorized access to database information. Unfortunately, there always comes as time when the information stored in the database must be processed or consumed by an application and that is when the risk to the data becomes greater.

In a typical configuration, a production database is running on its own server while the application accessing it is located across a network on a separate client or server platform. If database encryption is employed, the data that is sent to the application must first be decrypted before being sent to the application over the network. In an era where quality network packet sniffing tools are available to anyone with a a little know-how and an internet connection, there is always a possibility of someone capturing and logging the packet information. Despite this possibility, articles like the editorial mentioned above fail to emphasize the importance of securing critical data once it leaves the security of the database and passes over the network.

Most commercial database vendors now support some form of encryption of data over the network, typically through the use of SSL or some related data encryption protocol. In this scenario, before data is transmitted over the network via TCP/IP, it is encrypted. Once across the network and received, the packets are then decrypted and processed appropriately. If intercepted in transit by a packet sniffer, the data is gibberish and useless. When used in conjunction with database encryption, such network encryption makes the overall data environment much more secure and much less vulnerable to viewing by inappropriate audiences.

To be clear - there is more to data security than database encryption and network encryption. All of the security features employed within a production environment must work together and compliment each other - in contrast to the blind men in the parable who each believe his own narrow view of the elephant is correct. If you don't consider all of the pieces of the application stack that handle your sensitive data - application, data connectivity, database, network, servers, etc. you could end up with a security infrastructure that protects your elephant's tusks, but not it's tail.

Technorati Tags | |database encryption database+encryption data+encryption SSL data+security database+security SSL+encryption network+encryption