he security focus in your organization is probably misplaced, according to two database security experts at the recent RSA Conference in San Francisco. Aaron Newman, Chief Technology Officer at Application Security, Inc., said, “We believe people are spending a lot of money to protect the entire enterprise?a big company can spend $5 million?and spending very little to protect the database, and that’s where the most critical assets are.” In his business, he’s found that organizations often allot more resources to protecting their workstations than their databases, which he sees as a glaring misappropriation. “If your workstation gets hacked, that’s bad. But if your database gets hacked, you’re out of business. People spending 1 percent of their budget on database security should be spending 30 percent.”
Michael Figueroa, a lead security engineer in the American Management Systems (AMS) Enterprise Security Group, agrees. We’ve forgotten that data is the core asset of enterprise applications, he said. We need to look at protecting data first.
Even when IT professionals secure their databases, according to Figueroa they pay little attention to the data inside. In his view, protecting the database while ignoring the data is like fortifying an airplane but letting its passengers freeze, and the main threat to data is the applications they support. A compromised application can bypass firewalls and other perimeter security and access the database through its app server connection. “If [an application] gets compromised, then the attacker has an open path to the database if he knows how to exploit that path, because the database is free to whatever that application wants to do,” said Figueroa.
To focus enterprise security where both men believe it should be, each gave a database security presentation at the conference. Newman’s “Protecting Your Database” presentation was a strong case for hardening your database. It demonstrated common, easily launched hacker exploits of database systems, including Microsoft SQL Server and Oracle 9i. Figueroa’s “Application Database Security” presented the concept of a database firewall, a logical layer of abstraction between the application server and the database.
Database Attacks: What You Don’t Know Can Hurt You
Newman demonstrated just how easily hackers can infiltrate databases. Using VMWare software to show how code that is readily available on the Internet can be utilized to gain access to Microsoft SQL Server, Oracle 9i, and Sybase Adaptive Server Enterprise database systems, Newman within minutes injected code into all three products (see Table 1). He retrieved sensitive data and gained a reverse shell with just a few keystrokes.
Newman acknowledged that Microsoft and Oracle are good at fixing what’s wrong?patching vulnerabilities as soon as they become aware of them?but they are not particularly good at monitoring and detecting these security holes prior to breaches. For example, Microsoft found 25 buffer overflow vulnerabilities in SQL Server 2000 and fixed most of them in Service Pack 3 (SP3), but while they were unchecked and for those SQL Server 2000 databases that have yet to install the updated SP, buffer overflows offer hackers easy access to the database.
The buffer overflows contained in the Oracle listener service, the proxy between the client and the database, leave it vulnerable to a known exploit that allows attackers to write arbitrary files to the network.
Vendors don’t bear all the responsibility, however. Newman believes it’s incumbent upon database administrators (DBAs) to remain diligent in installing the latest patches. But even when patches are installed, that doesn’t protect the data from those inside the firewall. Developers need to lock down the privileges of local users who have access to the databases as well.
Newman believes education is as important to database security as any technological solution. “I think most developers don’t even realize there are problems with coding a certain way. So a lot of it is education,” he said. His presentation was an effort to get the word out and inform developers and DBAs of the holes they may inadvertently leave open to attack?many of which have readily available remedies. “I don’t think most DBAs are even aware that there was a patch for Oracle [released during the week of April 7] or that there was a patch for Microsoft SQL Server. [It was] six months between when the [SQL Slammer] patch was released and when the SQL Slammer worm hit.”
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.
