I know what’s running through your head right now.

“WTF?!? Mogull’s totally lost it. Isn’t he that data/information-centric security dude?”

Yes I am (the info-centric guy, not the insane bit), and here’s the thing:

The concept that you can run around, analyze, and tag your data throughout the enterprise, then keep it current through changing business contexts and requirements, is totally ridiculous. Sure, we have tools today that can scan our environment and tag files based on policies, but that just applies a static classification in a dynamic environment. I have yet to talk with a customer that really does enterprise-wide data classification successfully except for a few, discrete bits of data (like credit card numbers). The truth is that’s data identification, not data classification.

Enterprise content is just too volatile for static tags to really represent its value.

Even those of you in defense/intelligence don’t *really* do granular data classification. You just hit things with a big sledgehammer. “Is it Top Secret? Then we keep it totally isolated. What, this bit isn’t Top Secret but it’s on a Top Secret server? Frack it, we’ll just make it all Top Secret and be done with it. Need to pull it out? Go fill out this form.”

This post was inspired by a conversation yesterday where another information-centric wonk criticized the idea that data can be self-describing in any meaningful way, part of my principles of information centric security. While he caught the first point, he missed my meaning in the second point (policies and controls must account for business context) which means that the data self describes in such a way that business context can then be applied to determine value in that situation. I know it sounds like science fiction, but we’re starting to see real-world scenarios, and I’ll be the first to admit this is going to be a big area of advance over the next few years.

Now there is one piece of data classification that isn’t dead (I like sensational headlines just like the next person). That’s the business process of prioritizing information. That’s where you sit down with business executives and determine what information is more valuable than other information for your organization. It will drive all the protective strategies and dynamic protections we talk about when applying information-centric security. That’s absolutely vital to successful information security.

Thus we prioritize and identify information, but this is different than data classification, which is the concept that after these two steps, we can apply static labels as a way of protecting information.

That, my friend, is not only dead, it was never really alive.

Thanks in large part to the Attrition.org data loss database, there’s recently been some great work on analyzing breaches. I’ve used it myself to produce some slick looking presentation graphs and call attention to the ever-growing data breach epidemic.

But there’s one problem. Not a little problem, but a big honking leviathan lurking in the deep with a malevolent gleam in its black eyes.

Breach notification statistics don’t tell us anything, at all, about fraud or the real state of data breaches.

The statistics we’re all using are culled from breach notifications- the public declarations made by organizations (or the press) after an incident occurs. All a notification says is that information was lost, stolen, or simply misplaced. Notifications are a tool to warn individuals that their information was exposed, and perhaps they should take some extra precautions to protect themselves. At least that’s what the regulations say, but the truth is they are mostly a tool to shame companies into following better security practices, while giving exposed customers an excuse to sue them.

But notifications don’t tell us a damn thing about how much fraud is out there, and which exposures result in losses.

(Okay- the one exception is that any notification results in losses for a business that goes through the process).

In other words, we don’t know which of the myriad of exposures we read about daily in the press result in damages to those whose records were lost. They are also self reported; and I know for a fact there are incidents where companies did not disclose because they didn’t think they’d get caught.

For example, based on the statistics nearly a third of all breach notifications are the result of lost laptops, computers, and portable media (around 85 million records, out of around 316 million total lost records). About 51 million of those records were the result of two incidents (the VA in the US, and HMRC in the UK). The resulting fraud?

Unknown. No idea. Zip. Nada. In all those cases, I don’t know of a single one where we can tie the fraud to the lost data.

In some cases we really can track back the fraud. TJX is a great example, and the losses may be in the many tens of millions of dollars. ChoicePoint is another example, with 800 cases of identity theft resulting from 163,000 violated records (a number that’s probably really around 500,000, but ChoicePoint limited the scope of their investigation).

What we need are fraud statistics, not self-reported breach notification statistics. We do the best with what we have, but according to the notification stats we should all be encrypting laptops before we secure our web applications, yet the few fraud statistics available support the contrary conclusion.

In other words, we do not have the metrics we need to make informed risk management decisions.

This also creates a self-fulfilling negative feedback loop. Notifications result in measurable losses to businesses, driving security spending to prevent incidents that cause notifications, which may not represent prioritized security/loss risks.

When you read these things, especially on the slides shoved down your throat by desperate vendors (it’s usually slide 2 or 3), ask yourself if each one is an exposure, or actual fraud.

I was fortunate enough to be invited by TechTarget to put together their, “Database Security School“. It’s a compilation of four online educational components: a webcast, podcast, article, and online quiz.

If you manage to put up with me for all four lessons you should walk away with some new ideas on how to approach database security.

Check it out and let me know what you think…

Technorati Tags: Data security, Database encryption, Database Security, Information-centric security, Webcast

Someone call the Guinness records people- I’m actually posting the next part of this series when I said I would!

Okay, maybe there’s a deadline or something, but still…

In part 1 we discussed the value of DLP content discovery, defined it a little bit, and listed a few use cases to demonstrate it’s value. Today we’re going to delve into the technology and a few major features you should look for.

First I want to follow up on something from the last post. I reached out to one of the DLP vendors I work with, and they said they are seeing around 60% of their clients purchase discovery in their initial DLP deployment. Anecdotal conversations from other vendors/clients supports this assertion. Now we don’t know exactly how soon they roll it out, but my experience supports the position that somewhere over 50% of clients roll out some form of discovery within the first 12-18 months of their DLP deployment.

Now on to the…

Technology

Let’s start with the definition of content discovery. It’s merely the definition of DLP/CMP, but excluding the in use and in motion components:

“Products that, based on central policies, identify, monitor, and protect data at rest through deep content analysis”.

As with the rest of DLP, the key distinguishing characteristic (as opposed to other data at rest tools like content classification and e-discovery) is deep content analysis based on central policies. While covering all content analysis techniques is beyond the scope of this post, examples include partial document matching, database fingerprinting (or exact data matching), rules-based, conceptual, statistical, pre-definited categories (like PCI compliance), and combinations of the above. They offer far deeper analysis than just simple keyword and regular expression matching. Ideally, DLP content discovery should also offer preventative controls, not just policy alerts on violations. How does this work?

Architecture

At the heart is the central policy server; the same system/device that manages the rest of your DLP deployment. The key three features of the central management server are policy creation, deployment management/administration, and incident handling/workflow. In large deployments you may have multiple central servers, but they all interconnect in a hierarchical deployment.

Data at rest is analyzed using one of four techniques/components:

1. Remote scanning: either the central policy server or a dedicated scanning server that connects with storage repositories/hosts via network shares or other administrative access. Files are then scanned for content violations. Connections are often made using administrative credentials, and any content transfered between the two should be encrypted, but this may require reconfiguration of the storage repository and isn’t always possible. Most tools allow bandwidth throttling to limit network impact, and placing scanning servers closer to the storage also increases speed and limits impact. It supports scanning nearly any storage repository, but even with optimization performance will be limited due to reliance on networking.
2. Server agent: a thin agent is installed on the server and scans content locally. Agents can be tuned to limit performance impact, and results are sent securely to the central management server. While scanning performance is higher than remote scanning, it requires platform support and local software installation.
3. Endpoint agent: while you can scan endpoints/workstations remotely using administrative file shares, this will rapidly eat up network bandwidth. DLP solutions increasingly include endpoint agents with local discovery capabilities. These agents normally include other DLP functions, such as USB monitoring/blocking.
4. Application integration: direct integration, often using an agent, with document management, content management, or other storage-oriented applications. This integration not only supports visibility into management content, but allows the discovery tool to understand local context and possibly enforce actions within the system.

A good content discovery tool will understand file context, not just content. For example, the tool can analyze access controls on the files and using its directory integration understand which users and groups have what access. Thus the accounting department can access corporate financials, but any files with that content allowing all-user access are identified for remediation. Engineering teams can see engineering plans, but the access controls are automatically updated to restrict access by the accounting team if engineering content shows up in the wrong repository.

From an architectural perspective you’ll want to look for solutions that support multiple options, with performance that meets your requirements.

That’s it for today. Tomorrow we’ll review enforcement options (which we’ve hinted at), management, workflow, and reporting. I’m not going to repeat everything from the big DLP whitepaper, but concentrate on aspects important to protecting data at rest.

Technorati Tags: CMP, Content Discovery, Content Monitoring and Protection, Data Loss Prevention, Data security, DLP, Information Security, Information-centric security, Security, Tools, Tutorial

We’re going to be talking a lot about DLP content discovery this week. One interesting development over the past few years is the overlap of DLP, E-Discovery, and content classification tools. All three categories offer the ability to find and classify content, but they sell to different audiences for different purposes.

DLP content discovery currently has the most advanced analysis techniques, in large part because it is very focused on finding specific policy matches. It is a security-driven tool, with audit, legal, and compliance implications.

Electronic discovery (E-Discovery) is designed to provide investigators required evidence to support legal discovery. The tools tend to have more basic analysis techniques (often keyword based). They differ from many DLP tools in the nature of provided reports and how they manage the chain of evidence. We are starting to see DLP provide some of this functionality, or be used in conjunction with e-discovery tools, thanks to its more advanced content analysis.

Content classification tools are designed to support Information Lifecycle Management initiatives and are sold to storage teams. They are often high performing, but offer only basic content analysis techniques. Content classification tools are tasked with assigning a classification level to everything they touch, as opposed to finding policy violations.

Of the three, DLP content discovery tends to have superior content analysis techniques. At this point I recommend DLP to security/compliance/risk, content classification to storage, and e-discovery as needed for legal. Over time we expect to see consolidation and overlap between these categories, eventually merging into a single code base, but we will continue to see different “management lenses” to meet the needs of these different buying centers.

Technorati Tags: Content Discovery, Data Loss Prevention, Information Security, Information-centric security, E-Discovery, Security

Today, in cooperation with SANS, Securosis is releasing Understanding and Selecting a Database Activity Monitoring Solution. This is a compilation of my multipart series on DAM, fully edited with expanded content.

The paper is sponsored by Guardium, Imperva, Secerno, Sentrigo, and Tizor, but all content was developed independently by me and reviewed by SANS. It is available here, and will soon be available in the SANS Reading Room or directly from the vendors.

It was a fair bit of work and I hope you like it. The content is copyrighted under a Creative Commons license, so feel free to share it and even cut out any helpful bits and pieces as long as you attribute the source.

As always, questions, comments, and complaints are welcome…

… and there isn’t a DAM joke in the entire thing; I save those for the blog.

Technorati Tags: Database Activity Monitoring, Database Security, Whitepaper, Tutorial

Boy, RSA was sure a blur this year. No, not because of the alcohol, and not because the event was any more hectic than usual. My schedule, on the other hand, was more packed than ever. I barely walked the show floor and was only able to wave in passing to people I fully intended on sitting down with over a beer or coffee and having deep philosophical conversations with.

Since pretty much everyone in the world knows I spend most of my time on information-centric security, for which DLP is a core tool, it’s no surprise I took a ton of questions on it over the week. Many of these questions were inspired by analysis, including my own, that leaks over email/web really aren’t a big source of losses. People use that to try to devalue DLP, forgetting that network monitoring/prevention is just one piece of the pie. A small piece, in the overall scheme of things.

Let’s review our definition of DLP:

“Products that, based on central policies, identify, monitor, and protect data at rest, in motion, and in use through deep content analysis”.

Content Discovery, the ability to scan and monitor data at rest, is one of the most important features of any DLP solution; one with significant ability to reduce enterprise risk. While network DLP tells you how users are communicating sensitive information, content discovery tells you where sensitive information is stored within the enterprise, and often how it’s used. Content discovery is likely more effective at reducing enterprise risks than network monitoring, and is one reason I tend to recommend full-suite DLP solutions over single channel options.

Why?

Consider the value of knowing nearly every location where you store sensitive information, based on deep content analysis, and who has access to that data. Of being able to continuously monitor your environment and receive notification when sensitive content is moved to unapproved locations, or even if the access rights are changed on it. Of, in some cases, being able to proactively protect the content by quarantining, encrypting, or moving it when policy violations occur.

Content discovery, by providing deep insight as to the storage and use of your sensitive information, is a powerful risk reduction tool. One that often also reduces audit costs.

Before we jump into a technology description let’s highlight a few simple use cases that demonstrate this risk reduction:

1. Company A creates a policy to scan their storage infrastructure for unencrypted credit card numbers. They provide this report to their PCI auditor to reduce audit costs and prove they are not storing cardholder information against policy.
2. Company B is developing a new product. They create a policy to generate an alert if engineering plans appear anywhere except on protected servers.
3. Company C, a software development company, uses their discovery tool to ensure that source code only resides in their versioning/management repository. They scan developer systems to keep source code from being stored outside the approved development environment.
4. Company D, an insurance company, scans employee laptops to ensure employees don’t store medical records to work at home, and only access them through the company’s secure web portal.

In each case we’re not talking about preventing a malicious attack, although we are making it a bit harder for an attacker to find anything of value; we’re focused on reducing risk by reducing our exposure and gaining information on the use of content. Sometimes it’s for compliance, sometimes it’s to protect corporate intellectual property, and at other times it’s simply to monitor internal compliance with corporate policies.

In discussions with clients, content discovery is moving from a secondary priority to the main driver in many DLP deals (I hope to get a number out there in the next post).

As with most of our security tools, content discovery isn’t perfect. Monitoring isn’t always in real time, and it’s possible we could miss some storage locations, but even without perfection we can materially reduce enterprise risks.

Over the next few days we’ll talk a little more about the technology, then focus on best practices for deployment and ongoing management.

Technorati Tags: Content Discovery, Data Loss Prevention, Information Security, Information-centric security, Risk Management, Security

On Tuesday morning I’ll be giving a breakfast session at RSA sponsored by Vericept entitled Understanding and Preventing Data Breaches. This is the latest update to my keynote presentation where I dig into all things data breaches to make a best effort at determining what’s really going on out there. Since the system itself is essentially designed to hide the truth and shift risk like a token ring network, digging to the heart of the matter is no easy task.

On Friday Dark Reading published my latest column which is a companion piece to the presentation. It’s a summary of some of the conclusions I’ve come to based on this research. Like much of what I write I consider much of this to be obvious, but not the kinds of things we typically discuss. It’s far easier to count breaches and buy point solutions than to really discuss and solve the root cause. Here are a couple of excerpts, but you should really read the full article:

…

When I began my career in information security, I never imagined we would end up in a world where we have as much need for historians and investigative journalists as we do technical professionals. It’s a world where the good guys refuse to share either their successes or failures unless compelled by law. It’s a world where we have plenty of information on tools and technologies, but no context in which to make informed risk decisions on how to use them.

Call me idealistic, but there is clearly something wrong with a world where CISOs are regularly prevented by their legal departments from presenting their successful security programs at conferences.

…

1. Blame the system, not the victims, for identity fraud.
…
2. Blame the credit card companies, not the retailers, for credit card fraud.
…
3. Consumers suffer from identity fraud, retailers from credit card fraud.
…
4. We need fraud disclosure, not breach disclosure.
…
5. We need public root cause analysis.
…
6. Breach disclosures teach us the wrong lessons.

…

Based on the ongoing research I’ve seen, it’s clear that the system is broken in multiple ways. It’s not our failure as security professionals — it’s the failure of the systems we are dedicated to protecting.

While my presentation focuses on using what little information we have to make specific tactical recommendations, the truth is we’ll just be spinning our wheels until we start sharing the right information — our successes and failures — and work on fixing the system, not just patching the holes at the fringes.

Technorati Tags: Dark Reading, Data Breach, Governance, Information Security, Information-centric security, Security, Security Industry

At long last, thousands of words and 5 months later, it’s time to close out our series on Database Activity Monitoring. Today we’ll cover the selection process.

For review, you can look up our previous entries here:

Part 1
Part 2
Part 3
Part 4
Part 5

Define Needs

Before you start looking at any tools; you need to understand why you might need DAM; how you plan on using it; and the business processes around management, policy creation, and incident handling.

Create a selection committee: Database Activity Monitoring initiatives tend to involve four major technical stakeholders , and one or two non-technical business units. On the technical side it’s important to engage the database and application administrators with systems that may be within the scope of the project over time, not just the one database and/or application you plan on starting with. Although many DAM projects start with a limited scope, they can quickly grow into enterprise-wide programs. Security and the database team are typically the main project drivers, and the office of the CIO is often involved due to compliance needs or to mediate cross-team issues. On the non-technical side, you should have representatives from audit, as well as compliance and risk (if they exist in your organization). Once you identify the major stakeholders, you’ll want to bring representatives together into a selection committee.

Define the systems and platforms to protect: DAM projects are typically driven by a clear audit or security goal tied to particular systems, applications, or databases. In this stage, detail the scope of what will be protected and the technical specifics of the platforms involved. You’ll use this list to determine technical requirements and prioritize features and platform support later in the selection process. Remember that your needs will grow over time, so break the list into a group of high priority systems with immediate needs, and a second group summarizing all major platforms you may need to protect later.

Determine protection and compliance requirements: For some systems you might want strict preventative security controls, while for others you may just need comprehensive activity monitoring for a compliance requirement. In this step you map your protection and compliance needs to the platforms and systems from the previous step. This will help you determine everything from technical requirements to process workflow.

Outline process workflow and reporting requirements: Database Activity Monitoring workflow tends to vary based on the use case. When used as an internal control for separation of duties, security will monitor and manage events and have an escalation process should database administrators violate policy. When used as an active security control, the workflow may more actively engage security and database administration as partners in managing incidents. In most cases, audit, legal, or compliance will have at least some sort of reporting role. Since different DAM tools have different strengths and weaknesses in terms of management interfaces, reporting, and internal workflow, knowing your process before defining technical requirements can prevent headaches down the road.

By the completion of this phase you should have defined key stakeholders, convened a selection team, prioritized the systems to protect, determined protection requirements, and roughed out workflow needs.

Formalize Requirements

This phase can be performed by a smaller team working under the mandate of the selection committee. Here, the generic needs determined in phase 1 are translated into specific technical features, while any additional requirements are considered. This is the time to come up with any criteria for directory integration, additional infrastructure integration, data storage, hierarchical deployments, change management integration, and so on. You can always refine these requirements after you proceed to the selection process and get a better feel for how the products work.

At the conclusion of this stage you develop a formal RFI (Request For Information) to release to vendors, and a rough RFP (Request For Proposals) that you’ll clean up and formally issue in the evaluation phase.

Evaluate Products

As with any products, it’s sometimes difficult to cut through the marketing materials and figure out if a product really meets your needs. The following steps should minimize your risk and help you feel confident in your final decision:

Issue the RFI: Larger organizations should issue an RFI though established channels and contact a few leading DAM vendors directly. If you’re a smaller organization, start by sending your RFI to a trusted VAR and email a few of the DAM vendors which seem appropriate for your organization.

Perform a paper evaluation: Before bringing anyone in, match any materials from the vendor or other sources to your RFI and draft RFP. Your goal is to build a short list of 3 products which match your needs. You should also use outside research sources and product comparisons.

Bring in 3 vendors for an on-site presentation and demonstration: Instead of generic demonstrations, ask the vendors to walk you through specific use cases that match your expected needs. Don’t expect a full response to your draft RFP; these meetings are to help you better understand the different options out there and eventually finalize your requirements.

Finalize your RFP and issue it to your short list of vendors: At this point you should completely understand your specific requirements and issue a formal, final RFP.

Assess RFP responses and begin product testing: Review the RFP results and drop anyone who doesn’t meet any of your minimal requirements (such as platform support), as opposed to “nice to have” features. Then bring in any remaining products for in-house testing. You’ll want to replicate your highest volume system and the corresponding traffic, if at all possible. Build a few basic policies that match your use cases, then violate them, so you can get a feel for policy creation and workflow.

Select, negotiate, and buy: Finish testing, take the results to the full selection committee, and begin negotiating with your top choice.

Internal Testing

• Platform support and installation to determine compatibility with your database/application environment. This is the single most important factor to test, including monitoring coverage for the connection methods used in your organization, since different database platforms support a variety of connection types.
• Performance. Is network or agent performance acceptable for your environment? Don’t set arbitrary standards; monitor performance on your production systems to make sure testing represents operational requirements.
• Policy creation and management. Create policies to understand the process and complexity. Do you need to write everything as SQL? Will built-in policies meet your needs? Are there wizards and less-technical options for non-database experts to create policies? Then violate policies and try to evade or overwhelm the tool to learn where its limits are.
• Incident workflow. Review the working interface with those employees who will be responsible for enforcement.
• Behavioral profiling, if the product supports that as a way of developing policies.
• Directory integration.
• Change management integration.
• Enforcement/blocking/rollback and other advanced features.

Technorati Tags: ADMP, Database Activity Monitoring, Tools, Tutorial

We’re going to be finishing the series off this week, in large part so I can get it compiled together into a whitepaper with SANS, sponsored by Imperva, Guardium, and Sentrigo, before the big RSA show. I won’t be sleeping much this week as I compile and re-write the posts, add additional content that didn’t make it into the blog, create some images, and toss it back and forth with my editor. What? You didn’t think all I did was cut and paste this stuff, did you?

For review, you can look up our previous entries here:

Part 1
Part 2
Part 3
Part 4

What do I mean by advanced features? In our other posts we focused on the core solution set, but most of the products have quite a bit more to offer. There’s no way we can cover everything, and I don’t intend this to be an advertisement for any particular solution set, but there are a few major features we see appearing in more than one product. I’m going to highlight a few I think are particularly interesting and worthy of consideration in the selection process.

Content Discovery

As much as we like to think we know our databases, the reality is we really don’t always know what’s inside them. Many of our systems grew organically over the years, some are managed by external consultants or application vendors, and others find sensitive data stored in unusual locations. To counter these problems, some database activity monitoring solutions are adding content discovery features similar to DLP. These tools allow you to set content-based policies to identify the use of things like credit card numbers in the database, even if they aren’t located where you expect. Discovery tools crawl through registered databases, looking for sensitive content based on policies, and generate alerts for sensitive content in new locations. For example, you could create a policy to identify any credit card number in any database, and generate a report for PCI compliance. The tools can run on a scheduled basis so you can perform ongoing assessments, rather than combing through everything by hand every time an auditor comes knocking.

Some tools allow you to then build policies based on the discovery results. Instead of manually identifying every field with Social Security Numbers and building a different protection policy for each, you create a single policy that generates an alert every time an administrator runs a SELECT query on any field which matches the SSN rule. As the system grows and changes over time, the discovery component identifies the fields matching the protected content, and automatically applies the policy.

We’re also starting to see DAM tools that monitor live queries for sensitive data. Policies are then freed from being tied to specific fields, and can generate alerts or perform enforcement actions based on the result set. For example, a policy could generate an alert any time a query result contains a credit card number, no matter what columns were referenced in the query.

Connection Pooled User Identification

One of the more difficult problems we face in database security is the sometimes arbitrary distinction between databases and applications. Rather than looking at them as a single system, we break out database and application design and administration, and try to apply controls in each without understanding the state of the other. This is readily apparent in the connection pooling problem. Connection pooling is a technique where we connect large applications to large databases using a single shared connection running under a single database user account. Unless the application was carefully designed, all queries come from that single user account (e.g., APP_USR) and we have no way, at the database level, to identify the user performing the transaction. This creates a level of abstraction which makes it difficult, if not impossible, to monitor specific user activity and apply user policies at the database level.

An advanced feature of some database activity monitoring solutions allows them to track and correlate individual query activity back to the application user. This typically involves integration or monitoring at the application level. You now know which database transactions were performed by which application users, which is extremely valuable for both audit and security reasons.

Blocking and Enforcement

Today, most users just deploy database activity monitoring to audit and alert on user activity, but many of the tools are perfectly capable of enforcing preventative policies. Enforcement happens at either the network layer or on the database server itself, depending on the product architecture.

Enforcement policies tend to fall into two categories. The first, similar to many of the monitoring policies we’ve described, are focused on user behaviors like viewing or changing sensitive records. Rather than just alerting after a DBA pulls every account number out of the system, you can block the query. The second is focused on database exploits; similar to an intrusion prevention solution, the system blocks queries matching signatures for known attacks like SQL injection.

The nature and level of blocking will vary based on the architecture of the DAM tool. Integrated agent solutions may offer features like transaction rollback, while network tools block the traffic from hitting the DBMS in the first place. Digging into the specific architectures and benefits is beyond the scope of this post.

Application Activity Monitoring

Databases rarely exist in a vacuum; more often than not they are an extension of applications, yet we tend to look at them as isolated components. Application Activity Monitoring adds the ability to watch application activity, not just the database queries that result. This information can be correlated between the application and the database to gain a clear picture of just how data is being used at both levels, and identify anomalies which may indicate a security or compliance failure.

Since application design and platforms vary even more than databases, products can’t cover every custom application in your environment. We see vendors focusing on major custom application platforms, like SAP and Oracle, and monitoring web-based application activity.

Pre-Configured Application Policies

With or without application monitoring, some DAM solutions come with pre-configured policies for common applications (e.g., PeopleSoft). Although you’ll need to tune them to account for any application customization, they can jump-start the policy building process and save you from manually building all your compliance and security policies.

Pre-Configured Compliance Policies

Although no tool will make you compliant out of the box, pre-configured compliance policies for common platforms give you a head start on the process, especially when you don’t know where to start. Most vendors hire or partner with auditors to help them build their compliance policy and reporting packages for common regulations like SOX and PCI-DSS that frequently impact databases.

Change Management

Although many organizations have rigorous change management policies for the database platform and underlying system, far fewer enforce change management at the query level (which is invisible to traditional change management tools). An advanced feature of certain DAM solutions integrates with change management tools for closed-looped tracking of query-level changes. The requested change is approved in the change management system and a ticket number issued. The DBA enters that ticket number as part of their session, and all database changes (even to individual field updates) are recorded and correlated back to the original change ticket.

Vulnerability Assessment

Vulnerability assessment in databases is a topic worthy of its own series of posts (wink wink), but is sometimes offered as a feature (usually at additional cost) of a DAM solution. Database vulnerability assessment tools look deeper than patch levels, down to specific configurations and even an analysis of user entitlements. Some tools integrate the results of VA to DAM policies to generate alerts or block activity that’s suspected of targeting an identified vulnerability. This is a huge area on its own, and is beyond the scope of this post.

This list is far from exhaustive; I’ve tried to highlight some of the more common advanced features you’ll see through the selection process. I’m sure I’ve missed a few and I encourage those of you on the vendor side to add them in the comments, just avoid too much marketing fluff or I’ll filter the comment. If they’re good (and clearly a big feature starting to appear in multiple products) they might even make it into the white paper.

This post concludes our coverage of DAM features. By now you should have a good idea of how the technology works and the different options available to you. In the final post (probably tomorrow, considering my deadlines) we’ll dig into how to run a successful product selection process.

Technorati Tags: Application and Database Monitoring and Protection, Database Activity Monitoring, Tools, Tutorial