Using Reverse Proxies To Secure Databases

Late last year, I discussed some of the evolutionary changes to database activity monitoring systems. Vendors are bundling in new features that both expand the reach beyond relational databases as well as incorporate new techniques to analyze transactions. But the really interesting stuff is the new methods of security policy enforcement, all of which are predicated on a "reverse proxy" deployment model.

Let's dig in to the technology a bit more, and then I'll describe some of the options that are being provided.

A reverse proxy system sits in front of the database, collecting incoming requests from users and applications. Each inbound query is analyzed, and those that don't violate a security or compliance policy are forwarded to the database. And, in some cases, the database output is scanned for sensitive data. Nothing new here, but this is now viable because false positives and poor reliability issues are now under control. Poor analysis methods would halt legitimate queries, wreaking havoc with application servers, often causing them to hang, time out, or simply crash. Query whitelisting, lexical analysis techniques, and content analysis go a long way to improving these efforts, as does the general maturity of the platforms after a decade or more in development.

So why is this interesting? Because when you sit in line with the transaction and can quickly and reliably process events, you can do some pretty cools stuff to protect data. Here are some things to consider:

In-line masking: Masking is nothing new, as IT shops have been using Extraction-Transposition-Load (ETL) for years when populating test databases. What is new is the dynamic nature of the masking. As data is inserted, say in a test database, the data may undergo some form of obfuscation or transformation to ensure real live customer data does not make it into a test system. Conversely, some systems will dynamically mask query results by redirecting the incoming query to a masked view: Rather than getting sensitive data, they get results from a table with masked content. This is a method of harnessing production database servers while still allowing tests to be performed.

Redaction: By examining both the attributes of an incoming query (user, location, application, time of day, etc.) and the columns being selected, the reverse proxy can substitute the query results with nonsensitive placeholders. In some cases, this is a simple substitution of Social Security numbers -- as an example -- with "XXX-XX-XXXX." In some cases, such as with credit card numbers, the proxy may return a token to the calling application or user. This is a simple way of augmenting application functions without altering database or application logic.

Query rewrites: Say you get a query you've never seen before, or one that looks similar but may have some extra stuff appended to the "WHERE" clause. Or maybeit's an extra table join or just a simple inclusion of a column that contains sensitive data. Rather than letting it pass as is -- as it's not triggered an alert from the analysis engine -- or block it, you rewrite into an acceptable (e.g., known) format. In essence, you substitute the malicious query for an innocuous one. When the analysis engine has mapped all of the acceptable queries that it should receive from an application, or has parsed the entire SQL grammar and has identified a valid subset of all queries, you can approximate a similar safe query for risky ones. The good side is the query is not just dropped on the floor, so if it was a legitimate query, the calling application will not fall on it's face. The bad news is users and programmers may get some unexpected results.

SQL Injection blocking: SQL injection remains a huge problem for database security despite our being aware of the threat for more than a decade. I used to advocate stored procedures for implementing many database calls, thereby taking advantage of the databases built-in ability to cleanse input variables. However, programmers simply are not interested in using stored procedures, much in the same way they're not all that interested in washing input variables of malicious code. Thankfully, several vendors offer the ability to screen queries, either by matching specific patterns in the query that look suspicious, or by simply blocking all query constructs that are not specifically approved. The former, usually known as query attack signatures, is only marginally effective. It requires great attention to detail in creating the signatures. The latter, query white listing, is incredibly effective. And it has a very low rate -- some claim 0 percent -- of false positives.

However, that's a bit misleading because you need to update the list of acceptable queries every time you update the application. And if your application generates dynamic query strings, you're pretty much out of luck. Technically, what I am describing is only blocking, which has been around about as long as database monitoring has, but the analysis techniques are what make it viable.

All told, these are cutting-edge capabilities. These features and functions are not in general use, rather only employed by a handful of customers. But as we hear more success stories in offering real-time protection, I expect to see much greater adoption because I'm not aware of any other technologies that can provide this fine-grained control over real-time application and database transactions.

Adrian Lane is an analyst/CTO with Securosis LLC, an independent security consulting practice. Special to Dark Reading.