Perimeter
12/22/2011
10:28 AM
Adrian Lane
Adrian Lane
Commentary
Connect Directly
RSS
E-Mail
50%
50%

Database Security Proxies

Using DAM as a security proxy

The last database activity monitoring (DAM) model I want to address is the proxy model.

This is the final installment of my trends series, following the business activity monitoring, ADMP and the policy driven security model.

With the proxy model, DAM sits in front of the databases and all database requests are routed through the proxy. This is a deployment model shared with the ADMP and business activity monitoring models, allowing the proxy to detect and block malicious queries. But where it gets interesting is the other ways the proxy alters database output and function: In essence, the proxy model adds database functionality by modifying the results in non-standard ways.

The proxy model works is by intercepting inbound queries and after analysis, reacting with different technologies. One major feature is DAM recognizes incoming queries and provides the result directly to the user without passing the query to the database. The proxy system works as a database cache, lowering the resource demand on the database and improving query response times.

Another key feature is the proxy will protect sensitive information through masking or query re-writing. Depending upon the query, the data requested and the user credentials, the proxy will automatically alter the results a user would normally receive by either rewriting the query to omit sensitive data, or dynamically altering the result set. This masking model helps protect sensitive information without altering the database or encumbering it with overhead of data substitution. Finally, the proxy model of DAM acts as a firewall to protect the database from known attack signatures. Often called virtual patching, this feature protects the database from attacks and gives the database administrators some leeway as to when they apply security patches.

The downside of this deployment option is it's a one-to-one model, meaning one proxy serves one database. There are ways to minimize this, but at it's heart, the proxy is part of the database. Most DAM products offer a hierarchical deployment with end-point collectors to serve dozens -- if not hundreds -- of databases. Further, the proxy needs careful administration to ensure that the masks, caching, and attack signatures are working properly and do not interfering with normal business operations.

Finally, the implementations of this model are harder to use for compliance management. This is both for scaling policies across and organization, as well as full lifecycle integration with assessment, discovery, patch management, and protection. Some of the capabilities are present, but it's not as evolved as the other platforms.

With all of the DAM models I've discussed in this series, none are without concerns and side effects. Every option has detractors. The good news is between the four variations, there is likely a model that matches your security and/or operations model, making the system -- as a whole -- a better fit for your organization. And as I talk to a dozen large firms every month, I know every IT organization has their own peculiar way of doing things, and that's just the way it is.

It will take some time for you to understand DAM vendors' vision of security and compliance to see if it's in line with your IT operations model. You're not going to figure that out with your standard set of RFP/RFI questions, so start asking better questions that take into account your organizational oddities.

I want to make some final comments on this series as well. As DAM is morphing beyond databases and encompasses data and application security, what we ultimately call this/these new products is still up for debate. Unlike antivirus, which is a single-use tool, DAM is spreading across organizations for multiple applications and use cases. The commonality between the models discussed in this series is DAM is the cornerstone, and each model possesses and architecture capable of extending well beyond databases. The existing architecture readily accepts new capabilities (file activity monitoring is an example) and can handle a much broader array of security, compliance, and operations challenges than the original platform focus. It will be exciting to watch as customer choose which best fits their needs.

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
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-6306
Published: 2014-08-22
Unspecified vulnerability on IBM Power 7 Systems 740 before 740.70 01Ax740_121, 760 before 760.40 Ax760_078, and 770 before 770.30 01Ax770_062 allows local users to gain Service Processor privileges via unknown vectors.

CVE-2014-0232
Published: 2014-08-22
Multiple cross-site scripting (XSS) vulnerabilities in framework/common/webcommon/includes/messages.ftl in Apache OFBiz 11.04.01 before 11.04.05 and 12.04.01 before 12.04.04 allow remote attackers to inject arbitrary web script or HTML via unspecified vectors, which are not properly handled in a (1)...

CVE-2014-3525
Published: 2014-08-22
Unspecified vulnerability in Apache Traffic Server 4.2.1.1 and 5.x before 5.0.1 has unknown impact and attack vectors, possibly related to health checks.

CVE-2014-3563
Published: 2014-08-22
Multiple unspecified vulnerabilities in Salt (aka SaltStack) before 2014.1.10 allow local users to have an unspecified impact via vectors related to temporary file creation in (1) seed.py, (2) salt-ssh, or (3) salt-cloud.

CVE-2014-3594
Published: 2014-08-22
Cross-site scripting (XSS) vulnerability in the Host Aggregates interface in OpenStack Dashboard (Horizon) before 2013.2.4, 2014.1 before 2014.1.2, and Juno before Juno-3 allows remote administrators to inject arbitrary web script or HTML via a new host aggregate name.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Three interviews on critical embedded systems and security, recorded at Black Hat 2014 in Las Vegas.