Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Perimeter

4/12/2012
01:21 PM
Adrian Lane
Adrian Lane
Commentary
50%
50%

Using Reverse Proxies To Secure Databases

A look at database monitoring and reverse proxies

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. Adrian Lane is a Security Strategist and brings over 25 years of industry experience to the Securosis team, much of it at the executive level. Adrian specializes in database security, data security, and secure software development. With experience at Ingres, Oracle, and ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Gerry Grealish
50%
50%
Gerry Grealish,
User Rank: Author
4/18/2012 | 8:19:07 PM
re: Using Reverse Proxies To Secure Databases
I agree with your key-points.- My company, PerspecSys, uses a similar approach to protect sensitive data going into the cloud.- Our server is a Reverse Proxy that intercepts and encrypts or tokenizes values before they leave a company for storage or processing in the cloud, and we bring it back to clear-text on the way back in...all while preserving the cloud-apps functionality (such as "Searching" on encrypted fields).- Cool stuff enabled by the proxy deployment approach...--
MFEFERMAN9610
50%
50%
MFEFERMAN9610,
User Rank: Apprentice
4/13/2012 | 4:19:30 AM
re: Using Reverse Proxies To Secure Databases
It provides pre and post inline-processing on the data, in ways only limited by one's imagination. -And security is only one aspect of the coolness factor, but obviously the relevant one here, since we're talking about this on the 'Dark Reading' board.
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Our Endpoint Protection system is a little outdated... 
Current Issue
The Year in Security: 2019
This Tech Digest provides a wrap up and overview of the year's top cybersecurity news stories. It was a year of new twists on old threats, with fears of another WannaCry-type worm and of a possible botnet army of Wi-Fi routers. But 2019 also underscored the risk of firmware and trusted security tools harboring dangerous holes that cybercriminals and nation-state hackers could readily abuse. Read more.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-10694
PUBLISHED: 2019-12-12
The express install, which is the suggested way to install Puppet Enterprise, gives the user a URL at the end of the install to set the admin password. If they do not use that URL, there is an overlooked default password for the admin user. This was resolved in Puppet Enterprise 2019.0.3 and 2018.1....
CVE-2019-10695
PUBLISHED: 2019-12-12
When using the cd4pe::root_configuration task to configure a Continuous Delivery for PE installation, the root user�s username and password were exposed in the job�s Job Details pane in the PE console. These issues have been resolved in version 1.2.1 of the ...
CVE-2019-5085
PUBLISHED: 2019-12-12
An exploitable code execution vulnerability exists in the DICOM packet-parsing functionality of LEADTOOLS libltdic.so, version 20.0.2019.3.15. A specially crafted packet can cause an integer overflow, resulting in heap corruption. An attacker can send a packet to trigger this vulnerability.
CVE-2019-5090
PUBLISHED: 2019-12-12
An exploitable information disclosure vulnerability exists in the DICOM packet-parsing functionality of LEADTOOLS libltdic.so, version 20.0.2019.3.15. A specially crafted packet can cause an out-of-bounds read, resulting in information disclosure. An attacker can send a packet to trigger this vulner...
CVE-2019-5091
PUBLISHED: 2019-12-12
An exploitable denial-of-service vulnerability exists in the Dicom-packet parsing functionality of LEADTOOLS libltdic.so version 20.0.2019.3.15. A specially crafted packet can cause an infinite loop, resulting in a denial of service. An attacker can send a packet to trigger this vulnerability.