There are a lot of things I love about working for myself, but I have to admit sometimes it’s hard to keep everything balanced. For a while there I was taking whatever work came in the door that aligned with my goals and didn’t violate my objectivity requirements. Needless to say, the past few months have been absolutely insane; deadline after deadline, 2-3 trips a month, and a heck of a lot of writing.

The upside is I’m ahead on my goals for the year. The downside, other than a little stress, is that I haven’t been able to keep the content on the blog up as high as I’d like. How can I tell? This is part 3 of my series on Database Activity Monitoring, and I last posted part 2 in the beginning of November.


With that mea culpa out of the way (assuming Jews are allowed to mea culpa), let’s jump back in to DAM.

Part 1 Part 2

Today we’re going to start on the basic characteristics of the central management server, including aggregation and correlation and policy creation. Tomorrow (for real) we’ll cover alerting, workflow, and reporting.

Aggregation and Correlation

The one characteristic Database Activity Monitoring solutions share with log management or even Security Information and Event Management (SIEM) tools is the ability to collect disparate activity logs from a variety of database management systems. Where they tend to exceed the capabilities of these related technologies is their ability to not only aggregate, but to normalize and correlate events. By understanding the Structured Query Language (SQL) of each database platform, they can interpret queries and understand their meanings. While a simple SELECT statement might mean the same thing across different database platforms, each database management system (DBMS) is chock full of its own particular syntax. A DAM solution should understand the SQL for each covered platform and be able to normalize events so the user doesn’t necessarily need to know the ins and outs of each DBMS. For example, if you want to review all privilege escalations on all covered systems, the DAM solution will recognize those events regardless of platform and present you with a complete report without you having to understand the SQL.

A more advanced feature is to then correlate activity across different transactions and platforms, rather than just looking at single events. For instance, smart DAM tools can recognize a higher than normal transaction volume by a particular user, or (as we’ll discuss in policies) tie in a privilege escalation event with a large SELECT query on sensitive data, which could indicate an attack.

It also goes without saying (but I’ll say it anyway) that all activity is centrally collected in a secure repository to prevent tampering or a security incidents involving the repository itself.

Since you’ll be collecting a massive volume of data, your DAM tool needs to support automatic archiving. Archiving should support separate backups of system activity, configuration, policies, alerts, and case management.

Policy Creation

One of the distinguishing characteristics of Database Activity Monitoring tools is that they don’t just collect and log activity, they analyze it in real time for policy violations. While still technically a detective control (we’ll talk about preventative deployments later), the ability to alert and respond in practically real time offers security capabilities far beyond simple log analysis. Successful, loss-bearing database attacks are rarely the result of a single malicious query- they involve a sequence of events leading to the eventual damage. Ideally, policies will be established to detect the activity early enough to prevent the final loss-bearing act. Even when an alert is triggered after the fact, it supports immediate incident response and investigation far sooner than analysis days or weeks later.

Policies fall into two basic categories, and I’m sure some of the engineers working on these products will drop additional options down in the comments:

  1. Rules-based: Specific rules are set up and monitored for violations. They can include specific queries, result counts, administrative functions (new user creation, rights changes), signature-based SQL injection detection, UPDATE or other transactions by users of a certain level on certain tables/fields, or any other activity that can be specifically described. Advanced rules can correlate across different parts of a database or even different databases, adjusting for data sensitivity based on DBMS labels or through registration in the DAM tool.
  2. Heuristic: The DAM solution monitors database activity and builds a profile of “normal” activity. Deviations then generate policy alerts. Heuristics are complicated and take proper tuning to work effectively. They are a good way to build a base policy set, especially with complex systems where manually creating deterministic rules by hand isn’t realistic. Policies are then tuned over time to reduce false positives. For well-defined systems where activity is pretty standard, such as an application talking to a database using a limited set of queries, they are very useful. Heuristics, of course, fail if you profile malicious activity as known good activity.

The more mature a solution, the more likely it is to come with sets of pre-packaged policies. For example, some tools come with pre-defined policies for standard deployments of databases behind major applications, like Oracle Financials or SAP. Yes, you’ll have to tune the policies, but it’s far better than starting from scratch. Pre-built policies for PCI, SOX, and other generic compliance requirements may need even more tuning, but will help you kick start the process and save many hours of custom policy building.

Policies should include user/group, source/destination, and other important contextual options. Policies should also support advanced definitions, like complex, multi-level nesting and combinations. Ideally, the DAM solution will include policy creation tools that limit the need to write everything out in SQL or some other definition language. Yes, you can’t avoid having to do some things by hand, but basic policies should be as point-and-click easy as possible.

For common kinds of policies, like detecting privileged user activity or count thresholds on sensitive data, policy wizards are extremely useful.

Content-Based Policies

An emerging feature in some tools is support for content-based policies. Similar to DLP, the tools are able to analyze queries and results for specific content.

Identifying all known locations of sensitive data within multiple heterogenous database management systems is a complex process, even with the support of content discovery (which we’ll talk about later). Credit card and Social Security Numbers can easily be placed where they shouldn’t be, either on purpose or by accident. Content-based policies, typically using regular expressions, analyze database activity for unapproved use of sensitive data. For example, a policy could look for credit card numbers in any result set except those previously approved.

It’s very early days, but I expect we’ll see more and more content and context awareness in DAM tools over time. Let’s be honest- the most critical data we’re usually trying to protect (at least these days) falls into structured formats we can define and look for when it breaks outside its normal boundaries (including data labeling or other registration techniques). Long term we’ll be able to do some really interesting things as we improve our ability to monitor and understand business context with the content, moving us ever closer to the elusive goal of using legitimate rights to commit forbidden actions.

That’s the basics of what to look for in aggregation, correlation, and policy creation. Tomorrow we’ll spend time on alerting, workflow, and reporting, before moving on to more advanced features like user identification in connection pooling, change management, and content discovery.


p style=”text-align:right;font-size:10px;”>Technorati Tags: , , , , , ,