In-Depth
Database Security: Why Patching Isn't Popular with DBAs
Database security patching is a tricky business. It's so tricky, in fact, that some DBAs prefer to rely on defense-in-depth controls to protect their systems.
What's the most secure of the mass-market, commercial, off-the-shelf RDBMS offerings -- a category that doesn't include MySQL, Ingres, Postgres, and other open source software (OSS) DMBS products?
It's likewise a category that doesn't include Oracle Corp.'s eponymous DBMS. That's largely because Oracle has produced more than its share of DBMS vulnerabilities for the last half-decade.
It's a category that does include Microsoft Corp.'s SQL Server, which -- based on an independent analysis of vulnerability data -- has produced the fewest security vulnerabilities of any major DBMS over the last eight years.
That's according to veteran market watcher Laura Didio, a principal with Information Technology Intelligence Consulting (ITIC).
Didio bases her assessment on data published by the National Institute of Standards and Technology (NIST), which tallied 321 Oracle-related security vulnerabilities since 2002.
In fact, the NIST rates Microsoft Corp.'s SQL Server as the most secure of all of the mass-market RDBMS offerings -- including at least one OSS product: My SQL. According to NIST's Common Vulnerabilities and Exposures list, MySQL racked up 98 vulnerabilities from January of 2002 through June of 2010.
In this regard, even the second most secure of the mass market DBMSes -- MySQL -- arguably pales in comparison: it generated twice as many security vulnerabilities (98) as SQL Server, according to the NIST's CVE roll.
In addition, ITIC conducted a Web survey that Didio says is consistent with the NIST CVE data. Rank and file users seem to have a similar impression of SQL Server: it's perceived as being an extremely secure DBMS offerings. In fact, says Didio, a full 83 percent of respondents said that SQL Server security was "excellent" or "very good."
No one gave SQL Server a "poor" rating, while a clear majority (87 percent) of those who said that they had experienced security issues with SQL Server (some 2 percent of the overall sample) attributed these problems to third-party tools or configuration errors, Didio reports.
"In fact, database administrators, CIOs and CTOs interviewed by ITIC expressed their approbation with Microsoft's ongoing initiatives to improve SQL Server's overall security and functionality during the last decade starting with SQL Server 2000," she writes.
Databases in the Crosshairs
When it comes to security vulnerabilities, SQL Server, Oracle, DB2, and other DBMSes have each come under fire at different times.
For example, even though SQL Server has fewer identified vulnerabilities than any other mass-market DBMS -- and even though the NIST tally of SQL Server security vulnerabilities consists of a mere 49 identified flaws over an eight-year period -- one such flaw was SQL Slammer, a blockbuster worm that infected approximately 75,000 systems in January 2003.
Six months before, of course, Microsoft had identified and patched the very vulnerability that SQL Slammer so successfully exploited. Security patching in the early '00's -- before Microsoft developed its Windows Server Update Services (WSUS) offering -- was something of a from-the-hip proposition.
Oracle, for its part, first moved to a quarterly patching schedule in early 2005, following criticism of its disclosure policies -- precipitated by a wave of attack exploits in October of 2004 -- from users and industry watchers alike.
Those exploits targeted a vulnerability that Oracle had actually patched two months prior, in August. Sound familiar?
As it happens, security patching is an issue that's of particular salience in the Oracle space: two years ago, for example, database security vendor Sentrigo Inc. published a study which found that two-thirds of Oracle DBAs routinely did not patch known Oracle security vulnerabilities, regardless of how critical Oracle (or security watchers) adjudged them to be. (The Sentrigo study was based on a survey of 305 Oracle DBAs.)
Patching a database -- like patching a mission-critical server -- is a non-trivial proposition. That's one reason so many Oracle DBAs (in the Sentrigo survey) were reluctant to do so.
According to a CISSP with a prominent professional services firm, most shops prefer to exhaustively test patches -- even in cases in which known exploits are in the wild -- before deploying them. There are cases, however, in which this CISSP can't explain why a system remains unpatched.
"With some [companies], whatever they want to patch has to go into test for the better part of a month before they'll consider putting it into production, and that includes critical patches as well," this person told Enterprise Strategies. "In terms of security test evaluations that I have done, you'd think that a brand new installation would be patched and up to date; even then, that isn't always the case."
White hat security pros can use any of several tools (of varying degrees of sophistication) to quickly scan a database system and identify potential security vulnerabilities. Crackers have access to the same tools.
"If you use any of the automated scanning tools, the very first thing it checks is [if] the latest patches that are available [have been] applied. [This is something that] always shows up as a high-impact find if it's an unpatched system," the CISSP says.
It's often a case of striking a balance between quickly implementing a patch and compromising an important system or relying on existing -- or "defense-in-depth" -- controls to mitigate or constrain potential exposure. In other words, even if a database is unpatched and vulnerable, it isn't necessarily exposed.
"In terms of risk acceptance, it's weighing the benefits of having a system stop working versus a patch, which may require you to get past a bunch of defense-in-depth controls," this CISSP explains.