When we talk about database and application security we are faced with a major challenge: It is difficult, apparently, to define what the terms include. Also, it is important to differentiate between the two definitions. Are database and application security the same things? Are they different? How and why? A quick browse of the web will not turn up many answers. Compare scholarly papers, vendor specifications and university presentation slide decks and one comes away with a hodgepodge of information.
We saw a bit of that vagueness as we looked at application and database security products. So, let's begin by defining a few things. The best security when it comes to data - whether in a database or as part of an application - is encryption. Interestingly, we did not see a lot of that this month. In fact, most of the tools' emphasis was on using application firewalls to keep the bad guys away from the data in the first place.
The notion of application firewalls is not new. The complexity of attacks against applications, however, is growing at a serious pace. Fault and vulnerability testing of applications is better than ever. However, that doesn't help much if you don't perform the testing during the development phase of internal products, of course. Also, there are lots of software applications that we use, but we did not develop. If those products are on our network and they have vulnerabilities, they could be a covert channel into your enterprise.
So why not add encryption? That depends on to what you are adding encryption. It is practical to add encryption to a database, but to a front-end application, perhaps not so much. Even with databases there is a problem. Encryption keeps the bad guys out of the database - unless they are hijacking a session. That, naturally, is because the database is open, the user is connected and the traffic is in clear text. Now, suppose that our bad guy somehow gets the password and spoofs a legitimate user? If your only protection is encryption - no matter how strong it is - the data is exposed and, if the bad guy can gain access, you will lose it.
So there is a very good rationale for using some form of application firewall to keep data thieves at bay. Having encryption is not a bad thing, though. With today's distributed architectures and fuzzy perimeters, defense-in-depth never has been more important. The way defense-in-depth is implemented on current enterprises is very heterogeneous. It may include a network firewall, an application firewall, data leakage protection at the gateway and the endpoint, encryption and application or web firewalls. The idea is that we need to protect the data wherever it lies, as well as in transit.
We were generally quite pleased with the functionality and feature sets of these products, and our sense is that this is a good representative mix for the type. Occasionally, we saw some narrowness in the feature set, but overall that was unusual. Support, as a rule, is solid and deployment straightforward.
When buying a product from this group be careful that it supports both a current and planned database deployment. Don't forget that there are, in many organizations - as well as in applications - versions of SQL that are not made by Microsoft or Oracle.
Architecture also is important. Look at where the product fits best, per the manufacturer's recommendation, into the architecture. Then, assess whether that is practical in the enterprise. These products should be part of an overall strategy, so if you are using a lot of software/hardware devices to protect the enterprise (IDS/IPS, firewall and more), make certain that your new application firewall is compatible.
Finally, there are application security devices, database security products and combinations of both. Check to see if you need one or both environments protected to make sure that your choice does exactly what you need. These can be tricky beasts to buy and deploy, but with just a bit of care and pre-planning you should be good to go.
