Database Security Needs Evolve and Grow

Protecting the data in our enterprise databases is extremely important. But what exactly does that mean? Oh, at one level we have the database authorization and roles built directly into the DBMS products. You know what I'm talking about: GRANT and REVOKE statements that can be used to authorize access to database objects, resources and statements. Many organizations have adopted policies and products to migrate this type of security out of the DBMS and into their operating system security software.

Of course, granting and revoke authorization to database resources is important, but it is by no means sufficient for modern database security. Most DBMS products are evolving to deliver additional levels of data protection.

For example, DB2 offers multi-level security, providing ability to protect data and authorize its use at the row level. A multilevel security system allows the protection of data based on both traditional discretionary access controls, and controls that check the sensitivity of the data itself through mandatory access controls. These mandatory access controls are at the heart of a multilevel security environment, which prevents unauthorized users from accessing information at a classification level for which they are not authorized, or changing the classification of information they do have access to. These controls provide a way to segregate users and their data from other users and their data regardless of the discretionary access they are given though standard access lists.  The primary arena where multilevel security is valuable is government agencies that need a security environment that keeps information classified and compartmentalized between users. You’ve seen examples in the movies, right? “For your eyes only” or “top secret” data…

Another method to better secure database data is through encryption. But there can be problems when encrypting database data. First of all, encryption is supported differently in every DBMS, so you need to dig in and understand how your particular DBMS supports encryption, and whether the support is sufficient or if you need to augment it with third party software. Also, performance is an issue. It takes CPU cycles to encrypt and decrypt that data, so is security more important than rapid access? Probably so, but you need to make an informed decision.

Even more problematic can be indexed access. If indexed columns are encrypted on disk, the DBMS will sort the encrypted strings but query predicates will request the actual, unencrypted values -- and they won't match. Also keep in mind that some types of encryption require application code to be changed and nobody wants to do that, do they?

There are actually two types of encryption with respect to database data - encryption at rest and encryption over the wire. Encryption at rest involves encrypting the persistent database data on disk. But encryption can be specified for data before it is sent across the network and then automatically decrypted once it is received. Encryption over the wire is helpful to prevent surreptitious access to your data as it flies throughout your network, but it won't help combat thieves who target the database files on disk.

Another burgeoning field is database auditing, sometimes called data activity monitoring. This type of solution monitors database activity (INSERT, UPDATE, DELETE, and even SELECT) and reports on who is accessing and changing which pieces of data when. Such information can be very helpful to ensure that only appropriate personnel are accessing appropriate data within the database. Database auditing solutions can help you to track the activity of privileged users (such as SYSADMs). And they can be invaluable in terms of being in compliance with regulations such as PCI-DSS and HIPAA.

Taking things yet another step further, auditing data can be achieved in an active manner - - let’s call it data trend monitoring. This type of solution monitors all database requests as they happen and discovers access patterns and trends. You can then configure policy-based access and control such that invalid data requests and/or modifications can be stopped and alerts can be generated when such actions are attempted. Trends can be monitored so that any behavior outside of the norm can be highlighted and investigated. This can be important, for example, to watch for suspect activity initiated by authorized users. Some analyst's suggest that such activity is more pervasive and potentially damaging to data than external attacks. And it can be very hard to detect.

All of these evolving database security features and products can be very useful to bolster existing database security and auditing tactics. So database security is evolving to enable better control over the precious information stored in enterprise databases. And like biological evolution, I would expect that we will see even more types of database security offerings over time... although the timescale will most certainly be much shorter than the geological timescale of biological evolution.