Years ago, Oracle’s responses to reports of SQL injection attacks against its database servers literally were focused on media damage control – ensuring that not too many customers get scared by them. (To be fair, Microsoft had the same policy.) The basic concept of SQL injection is all too simple: Feed intentionally malformed instructions into the system in such a way that the server responds with clues that could enable you to obtain unprivileged data – or sometimes, with the data itself.
How hard could it be, security engineers and college professors argued for over a decade, for a company like Oracle to deploy a ZoneAlarm-like firewall that could independently analyze incoming SQL instructions, parse them, and only permit those that meet specific criteria? For years, well-minded engineers were told in response that yet another firewall would render networks too slow and inoperative. Then in May 2010, Oracle learned it could just simply acquire Secerno, an emerging database firewall company.
That acquisition became, naturally enough, Oracle Database Firewall. This morning, Oracle announced its latest revision to the tool, which now covers MySQL Enterprise Edition.
What Secerno discovered was something that every punch-card operator and IBM job specialist had known since the 1960s: If you have a stack full of equivalent jobs, stated the same way and with the same size, then when they stack up, you should see a simple order. Looking down the list, you should see perfect stripes where all the like digits in the similar parts of the job line up with one another. Get one out of order and the whole thing looks wrong. A SQL injection attack should throw off the order of things in such a way that anything parsing the entire stack from a distance should notice something’s wrong, and should estimate where it’s gone wrong.
This is what SANS Institute learned last year (PDF available here) in its evaluation of the first edition of Oracle Database Firewall, produced following its Secerno acquisition. The pattern of so many similar instructions should produce a signature, a kind of common geometry. If something gets thrown off, the fracturing of that geometry should be noticeable no matter how small or large the instruction stack may be.
In other words, produce a signature for what an orderly database looks like, and keep an eye out for that. Instead of, for example, relying on some external researcher to produce a signature for a specific breed of SQL injection attack, and rely on antivirus-derived scanning to spot it when it comes down the pike. In a new white paper released today (PDF available here), Oracle finally admits the old way of doing things was not as “impenetrable” as first stated.
“Oracle Database Firewall examines the grammar of the SQL statements being sent to the database, analyzes their meaning, and determines the appropriate security policy to apply,” the white paper reads. “Grammatical classification and session-factor profiling provide a powerful method for tracking database access, and enables the Oracle Database Firewall to recognize changes in normal behavior, such as SQL injection attacks on applications, and block them before they reach the database. This highly accurate approach provides a significantly higher degree of protection than first-generation database monitoring technologies that rely on recognizing the signature of known security threats.”
A blacklist (for those still debating the technical meaning) is any published list of exclusions. Slides from a recent presentation at Oracle OpenWorld (a href=”http://www.oracle.com/openworld/lad-en/session-presentations/database/13440-enok-1436892.pdf”>PDF available here) indicate that this new version of the Database Firewall aims to encourage administrators to create whitelists – policies that state exactly how SQL instructions should be formed, and how exceptions are to be treated. This way, whitelisted (passed) instructions create patterns whose disruptions are easier to spot.
What’s more, asserted Oracle’s senior principal product manager, Kamal Tbeileh, the policy-based firewall lets the administrator declare rules that pertain to the meaning and intent of the instructions, including when they’re grouped together as a procedure. The result is the elimination of false negatives – instructions that are accidentally excluded, with results that could be as destructive as a genuine SQL injection would have been.
In addition to the MySQL EE support announced today, Database Firewall will continue to support IBM DB2, Microsoft SQL Server, and Sybase’s Adaptive Server Enterprise and SQL Anywhere, in addition to Oracle Database 11g.
