Database activity monitoring (DAM) has been the biggest advancement in database security in the past decade. Identity management controls access, and encryption protects data on media, but monitoring verifies usage.

But because of the complexities involved, this is not something you want to try to write yourself. Unlike assessment and auditing, the database does not provide built-in mechanisms for data collection, analysis, and policy enforcement.

DAM captures and records database events, which at a minimum is all Structured Query Language (SQL) activity, in real-time or near real-time, including database administrator activity, across multiple database platforms, and generating alerts on policy violations.

DAM products follow a consistent process: collection of the events from the database, analysis of the activity in relation to established policies, and alerting when a policy violation is detected. DAM systems can be deployed as software or an appliance, and will use local agents installed on the database server to collect activity.

Some work in combination with network analysis, but agents are required to collect administrative activity, a necessity for regulatory compliance. What we want to focus on is the analysis because that is what separates DAM from auditing. Monitoring systems are designed to find violations instantly, utilize more advanced inspection techniques, alert, and even block activity. Let's look at how this happens:

Attribute Analysis is the most common technique used in monitoring. Statement attributes like operation type (Select, Update, Insert), the user who issued the statement, the time of day, the columns references, number of records returned or dozens of other items. A common policy is to alert when any users selects more than one customer record at a time, or anyone selecting social security numbers from outside the company after 6:00 pm. When a statement matches the attributes specified, an alert is generated and, with some platforms, the action is blocked.

Statement Analysis/Lexical Detection is the examination of the SQL structure. Examining components such as the where clause, the type and number of parameters, or even the size and type of input data, abnormal activity is detected because the statement just doesn't look right. This is commonly used to detect SQL Injection and buffer overflow attacks.

Behavioral Analysis combines one or both of the above analysis techniques, but augments the comparison with a behavioral profile. The profile is created by monitoring all database activity to establish a common reference for how the database is used. Once created, the behavioral profile is compared to incoming SQL statements, generating an alert if the users session activity is abnormal.

Content Analysis is looking at the data within the statements. This may be used in conjunction with attribute analysis, but the core of the policy is understanding the content that is moving in or out of the database. Credit card numbers or personally identifiable information are two such examples that are restricted for privacy and compliance initiatives.

In my next post, I'll discuss how to apply database activity monitoring to solve problems, and why it's an important advancement for compliance and security.

Adrian Lane is an analyst/CTO with Securosis LLC, an independent security consulting practice. Special to Dark Reading.