The last database activity monitoring (DAM) model I want to address is the proxy 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