Data Security, Top Down

Continuing the database security trends with database activity monitoring (DAM), the next model I want to talk about is policy-driven data security. Conceptually this means you define the security or compliance task to be accomplished, and that task gets divided by a number of technologies that get the work done. Policies are mapped -- from the top down -- into one or more security tools, each performing part of the workload to accomplish a task.

In an ideal world, the tool best-suited to do the work gets assigned the task. To make this type of approach work, you must have a broad set of security capabilities and a management interface tightly coupled with underlying features.

For database security, this is the classic coupling of discovery, assessment, monitoring, and auditing -- each function overlapping with the next. The key to this model is policy orchestration: Policies are abstracted from the infrastructure, with the underlying database -- and even non-database -- tools working in unison to fulfill the security and compliance requirements. A policy for failed logins, as an example, will have assessment, monitoring, and auditing components that capture data and perform analysis. A central management interface includes lots of pre-generated rules that coordinate resources that allow customers to cover the basics quickly and easily. In practice, it's rare to see top-down security limited to database security, and it usually covers general network services and endpoints as well.

This model is great for reducing the pain of creating and managing security across multiple systems. It also lowers the bar on technical and compliance expertise required for users to manage the system -- that knowledge is built in.

Workers don't have to know "how" to do it, just what they need to do. And that is a big deal for mid-market firms that cannot afford to have lots of security and compliance experts on staff. Finally, since it's designed to leverage lots of tools, integrating with other platforms is much easier.

However, there are several significant detractors to the model because the lack of flexibility and deployment complexity overwhelms the midmarket buyer it conceptually best serves. Since the technologies are prebundled, you have more tools to accomplish tasks you can solve with a single product from a different vendor, resulting in a much larger footprint on your organization. While basic setup of policies is as simple as selecting a prewritten rule, custom policies have a greater degree of complexity as compared to more traditional database security systems.

In this model, DAM is just one of many tools to collect and analyze events, and not necessarily central to the platform. As such, policy-driven security is not an evolution or change to DAM (as it is with business activity monitoring and ADMP); it's more a vision of how DAM fits within the security ecosystem.

The intention of the model is to mask the underlying complexities of technology from the users who simply want to get a compliance or security task done. Many in IT don't have the time or desire to be a security expert, and want more of a "point-and-click" solution. This model has been around for a long time -- since at least 2006 with DAM. I know because this was the model I architected and was attempting to build out as a "next generation" DAM solution. Conceptually, it's very elegant, but every firm I have ever seen try to attempt this fails because the underlying technologies have not been best-of-breed, nor did the interfaces deliver on promised simplicity. It requires a great deal of commitment from the vendor to carry this off, and the jury is still out as to whether it will deliver on the intended value proposition.

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