The "Database Firewall"
Figueroa is applying what he describes as AMS's inside-out security approach to the database. He proposes a database firewall that would act as an abstraction layer and a logic barrier between the database and the application. He said, "Developers know how their applications talk to the database, they know what queries are going across, and they know what structures the queries are using," he says. "They can use that information to configure a rules set so that this [database firewall] can filter the queries before they get sent to the database."
Basically, because developers use administrative privileges to work on their applications, they know exactly which queries these applications should be using to access data from the databases. They also know when an app initiates a transaction that isn't part of that app's function. That knowledge qualifies them to dictate which queries are legitimate and to out lock all others. "It's the simple idea of making sure that only the queries you know are valid are going against the database," said Figueroa.
This firewall would contain two components, a query filter and a query monitor. The filter would contain the business rules that the developer sets, while the monitor would scan for queries that contain malicious or potentially destructive code.
How would the database firewall concept stand up against the real-world database attacks that Newman describes? He said, "The database firewall is a good way to protect yourself from some attacks. It does a lot to stop SQL injection and various attacks like that, but you're going to have internal users who are going to be beyond the firewall and they're going to be attacking the database directly."
Patching the Developer/DBA Gap
Though Newman emphasizes keeping up to date with the latest patches, he isn't without empathy for how hard that can be for DBAs and developers. He acknowledges that "installing a patch usually breaks something" and describes the process as usually being "a huge hassle" that DBAs will fight "tooth and nail" unless they can have "six months of regression testing." Figueroa agreed. "DBAs can't just jump at a patch and say we're going to be more secure as a result, because they've seen things break before. And they feel the need to go through the testing because patches don't typically fix vulnerabilities, they shut off the functionality that the vulnerability was associated with."
When these functionalities are shut off, which ensures more restricted access, the applications that rely on the patched database are what usually break. This result can leave developers frustrated at the DBAs, who weren't particularly eager to install the patch in the first place. Security can become an easy scapegoat in these scenarios.
As Figueroa puts it, "DBAs and developers have different priorities. Developers just want things to work, because they get fired when things don't work." Conversely, Newman says a DBA is concerned with getting the best performance out of his or her database, maintaining availability, and making sure that backups are going well. Neither has security at the top of their priority list and the hassle of patches can leave them wondering whether database security is worth the effort. As Newman pointed out,
"No one gives [a DBA] a bonus because he locked a database down. They give him a bonus because he gets 20 percent more performance out of it."
Ignoring database security altogether and relying on perimeter enterprise safeguards (firewalls, intrusion detection systems, etc.) can seem like the easiest course. Newman and Figueroa want to put an end to this mindset by making IT professionals aware of the critical importance of protecting databases and the data that resides in them.