Database Activity Monitoring may not carry the same burden of hype as Data Loss Prevention, but it is one of the most significant data and application security tools on the market. With an estimated market size of $40M last year, and predictions of $60M to $80M this year, it rivals DLP in spending. Database Activity Monitoring also carries the best DAM acronym in the industry
Sorry, couldn’t help myself.
DAM is an adolescent technology with significant security and compliance benefits. The market is currently dominated by startups but we’ve seen large vendors starting to enter the space, although products are not currently as competitive as those from smaller vendors. Database Activity Monitoring tools are also sometimes called Database Auditing and Compliance, or various versions of Database Security.
There’s a reason I’ve picked DAM as the second technology in my Understanding and Selecting series. I believe that DLP and DAM form the lynchpins of two major evolving data security stacks. DLP, as it migrates to CMF and CMP, will be the center of the content security stack; focused on classifying and protecting structured and unstructured content as it’s created and used. It’s more focused on protecting data after it’s moved outside of databases and major enterprise applications. DAM will combine with application firewalls as the center of the applications and database security stack, providing activity monitoring and enforcement within databases and applications. One protects content in a structured application and database stack (DAM) and the other protects data as it moves out of this context onto workstations and storage, into documents, and into communications channels (CMP).
Defining DAM
Database Activity Monitors capture and record, at a minimum, all Structured Query Language (SQL) activity in real time or near real time, including database administrator activity, across multiple database platforms, and can generate alerts on policy violations. While a number of tools can monitor various level of database activity, Database Activity Monitors are distinguished by five features:
- The ability to independently monitor and audit all database activity, including administrator activity and SELECT transactions. Tools can record all SQL transactions: DML, DDL, DCL, (and sometimes TCL) activity.
- The ability to store this activity securely outside of the database.
- The ability to aggregate and correlate activity from multiple, heterogeneous Database Management Systems (DBMS). Tools can work with multiple DBMS (e.g., Oracle, Microsoft, IBM) and normalize transactions from different DBMS despite differences in their flavors of SQL.
- The ability to enforce separation of duties on database administrators. Auditing activity must include monitoring of DBA activity, and solutions should prevent DBA manipulation of and tampering with logs and activity records.
- The ability to generate alerts on policy violations. Tools don’t just record activity, they provide real-time monitoring and rule-based alerting. For example, you might create a rule that generates an alert every time a DBA performs a SELECT query on a credit card column that returns more than 5 results.
Other tools provide some level of database monitoring, including Security Information and Event Management (SIEM), log management, and database management, but DAM products are distinguished by their ability to capture and parse all SQL in real time or near real time and monitor DBA activity.
Depending on the underlying platform, a key benefit of most DAM tools is the ability to perform this auditing without relying on local database logging, which often comes with a large performance cost. All the major tools also offer other features beyond simple monitoring and alerting, ranging from vulnerability assessment to change management.
Market Drivers
DAM tools are extremely flexible and often deployed for what may appear to be totally unrelated reasons. Deployments are typically driven by one of three drivers:
- Auditing for compliance. One of the biggest boosts to the DAM market has been increasing auditor requirements to record database activity for SOX (Sarbanes-Oxley) compliance. Some enterprises are required to record all database activity for SOX, and DAM tools can do this with less overhead than alternative approaches.
- As a compensating control for compliance. We are seeing greater use of DAM tools as a compensating control to meet compliance requirements even though database auditing itself isn’t the specified control. The most common example is using DAM as an alternative to encrypting credit card numbers for PCI compliance.
- As a security control. DAM tools offer significant security benefits and can sometimes even be deployed in a blocking mode. They are particularly helpful in detecting and preventing data breaches for web facing databases and applications, or to protect sensitive internal databases through detection of unusual activity.
DAM tools are also beginning to expand into other areas of database and application security, as we’ll cover in a future post. Today, SOX compliance is the single biggest market driver, followed by PCI. Despite impressive capabilities, internally-driven security projects are a distant third motivation for DAM deployments.
Use Cases
Since Database Activity Monitoring is so versatile, here are a few examples of how it can be used:
- To enforce separation of duties on database administrators for SOX compliance by monitoring all their activity and generating SOX-specific reports for audits.
- If an application typically queries a database for credit card numbers, a DAM tool can generate an alert if the application requests more card numbers than a defined threshold (often a threshold of “1”). This can indicate that the application has been compromised via SQL injection or some other attack.
- To ensure that a service account only accesses a database from a defined source IP, and only runs a narrow range of pre-approved queries. This can alert on compromise of a service either a) from the system that normally uses it, or b) if the account credentials are stolen and used from another system.
- For PCI compliance you can encrypt the database files or media where they’re stored, then use DAM to audit and alert on access to the credit card field. The encryption protects against physical theft, while the DAM protects against insider abuse and certain forms of external attack.
- As a change and configuration management tool. Some DAM tools offer this as a specialized feature with closed-loop integration with change management tools to track approved database changes implemented in SQL. Other tools can use this to track administrator accounts and provide change management reports for manual reconciliation.
In our next post we’ll cover the various technical architectures, including the big debate between agents and network sniffers, and follow with future posts covering major features to look for and how to run a selection process.
Reader interactions
8 Replies to “Understanding And Selecting A Database Activity Monitoring Solution: Part 1, Introduction”
Part 1 Part 2 Part 3 Part 4 Part 5
Part 1 Part 2 Part 3 Part 4
Part 1 Part 2
I think encrypting the database files, especially when used with Database Activity Monitoring, is an extremely effective security control. But it doesn’t replace field level encryption,
is, flat out, the poster child for database activity monitoring. As I described in my introduction to the technology, one of the use cases is to create separation of duties by allowing someone to do their job while
Very nice! But I was thinking Or HOTDAM (Heuristic Outcomes Through Database Activity Monitoring).
You covered the ground work, and the more I read, the more it looks like we share the same future vision of data security. I do want to add a couple of items that I think are important as they show trends in the space.
Database Activity Monitoring is a species of the Intrusion Detection genus. Much in the same way that many of the early computer security professionals have come from the network security & threat detection, the database activity monitoring came from a specialized need to capture/monitor specifically for databases related network packets, and detect events and behaviors that were distinct from what many IDS systems were looking for. Early on it was clearly differentiated from Database Monitoring because it was monitoring activity outside or against the database, as opposed to functions or activity inside the database. This was an important distinction as solutions that used native auditing capabilities caused serious performance problems, and closely coupled solutions (Stored Procedures and or Triggers) not only took a huge toll on resources, but their invasive nature was viewed by DBA’s and IT professionals as untenable. Network based solutions had no such interaction with the database, and could be inserted without penalty to the database itself. And as a way of creating a marketing distinction, the DAM moniker was born.
Over time, this differentiation has blurred. Pure network sniffing has turned to protocol stack sniffing, then intercept at the gateway, library or service level in order to get a more complete picture of activity. The biggest challenge was “what is happening at the console”, which these agents now solve by collecting all of the SQL activity at the cost of some database platform impact. And on the other side, the days of suffering a huge penalty for using native database Audit are long gone as well, with vendors like IBM and Oracle making order of magnitude improvements in performance. They are also including data that was previously not present or unreliable.
But to me, it is clear that the goal of DAM is/was DM, or Database Monitoring. I think this concept is occasionally lost in our efforts to market something palatable. And at the point in time we have convergence in understanding and availability of data, it will not longer be the problem we want to solve. It is probable that the DAM name will persist, but more because of the roadmap of where data security is heading than where we have been.
In your description, under, you say ‘transactions’. I am not entirely sure of which you meant. A transaction may include one or more SQL statements. For example, a call to a stored procedure may alter thousands of rows, fire triggers and call other stored procedures, and merely return something as innocuous as “result=0”. Or a rollback command may undo thousands of previous DML changes. And SELECT statements are usually individual statement transaction, unless used as a data feed into some other transactional construct (SELECT INTO). From my perspective, need to have statements, but transactions are no less important, so I ask for clarification under ‘‘Defining DAM’‘.
A question: There are thousands of other use cases, but because of its simplicity and overwhelming market demand, I was expecting to see ‘Failed Logins’ a use case here. Did you omit it because it is a problem that can be solved by SIM/SEM as well, and is not unique to DAM?
When do we get MUDSS (Mogull’s Unified Data Security Strategy)?
Hmm.. we definitely don’‘t want to go with Database Activity Monitoring and Protection 🙂 Or Database Activity Monitoring and Enforcement.
I’‘m thinking that just as DLP is migrating to CMF and CMP, DAM will migrate to ADMP- Application and Database Monitoring and Protection.
I think you really need the combination of activity monitoring and prevention, not just blocking. Basic blocking is definitely starting to creep in, but the more robust activity blocking at the transaction level is still extremely early. I’‘m guessing we’‘ll start with attack prevention and the virtual patching kinds of things you guys do, but are still years away from more logical/transaction blocking.
I’‘m really looking forward to this market growing- DLP gets all the attention, but DAM is nearly as big and just as valuable.
Rich,
What an excellent start – a definition of DAM is something that was lacking in this market space, and I like the way you structured yours, even if I’‘m not crazy about the acronym…
One thing I would stress in this regard that I think you only mentioned in passing is prevention capabilities. As is the case with IDS/IPS, users may be wary of prevention capabilities for fear of false positives, but they still want them. Some use cases are very robust – e.g. preventing the use of rogue applications, or blocking IP addresses (similar to your scenario #3), and we see this as something that people actually use. As the technology becomes more widespread and users are more comfortable with it, we’‘ll see more use and demand for prevention.
Perhaps the acronym should should be DAMP 🙂
The market drivers are as you described, but in terms of trending I would say PCI DSS is on the rise, as are security drivers. For example, I know a Fortune 500 company that kick started a project following the Fidelity Information Services breach.
Looking forward to part 2!