Perimeter
4/12/2012
01:21 PM
Adrian Lane
Adrian Lane
Commentary
Connect Directly
RSS
E-Mail
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: Apprentice
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
Cartoon
Current Issue
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-2595
Published: 2014-08-31
The device-initialization functionality in the MSM camera driver for the Linux kernel 2.6.x and 3.x, as used in Qualcomm Innovation Center (QuIC) Android contributions for MSM devices and other products, enables MSM_CAM_IOCTL_SET_MEM_MAP_INFO ioctl calls for an unrestricted mmap interface, which all...

CVE-2013-2597
Published: 2014-08-31
Stack-based buffer overflow in the acdb_ioctl function in audio_acdb.c in the acdb audio driver for the Linux kernel 2.6.x and 3.x, as used in Qualcomm Innovation Center (QuIC) Android contributions for MSM devices and other products, allows attackers to gain privileges via an application that lever...

CVE-2013-2598
Published: 2014-08-31
app/aboot/aboot.c in the Little Kernel (LK) bootloader, as distributed with Qualcomm Innovation Center (QuIC) Android contributions for MSM devices and other products, allows attackers to overwrite signature-verification code via crafted boot-image load-destination header values that specify memory ...

CVE-2013-2599
Published: 2014-08-31
A certain Qualcomm Innovation Center (QuIC) patch to the NativeDaemonConnector class in services/java/com/android/server/NativeDaemonConnector.java in Code Aurora Forum (CAF) releases of Android 4.1.x through 4.3.x enables debug logging, which allows attackers to obtain sensitive disk-encryption pas...

CVE-2013-6124
Published: 2014-08-31
The Qualcomm Innovation Center (QuIC) init scripts in Code Aurora Forum (CAF) releases of Android 4.1.x through 4.4.x allow local users to modify file metadata via a symlink attack on a file accessed by a (1) chown or (2) chmod command, as demonstrated by changing the permissions of an arbitrary fil...

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
This episode of Dark Reading Radio looks at infosec security from the big enterprise POV with interviews featuring Ron Plesco, Cyber Investigations, Intelligence & Analytics at KPMG; and Chris Inglis & Chris Bell of Securonix.