One of the biggest difficulties organizations face in the pursuit of secure databases is figuring out how to optimize practices and get the job done with as few resources as possible. Unlike many workday security responsibilities, such as endpoint patch management, database security comprises a symphony of discrete tasks that have to be carried out by a dispersed team of security and database professionals, many of whom communicate poorly within the enterprise.
What some of the most disorganized of these enterprises and small to midsize businesses need to streamline is twofold: a framework defining all of these tasks, and a way to measure how much time, how many tools, and how much organizational energy is being spent on each one of them in order to make adjustments that improve the overall security of the database, according to Adrian Lane and Rich Mogull of the boutique analyst firm Securosis.
No such framework or metrics exist today, says Lane, who is shepherding Securosis' Project Quant, an ambitious effort designed to build the framework and infrastructure needed to help the IT community better quantify their database security efforts.
"We're trying to find some degree of optimization and quantify the costs so that we can gauge a sort of degree of effectiveness over time," Lane says. "So the goal really is ultimately to look at the costs we're spending on maintaining, say, an assessment program versus a monitoring program, and then starting to try to talk about some risk reduction for that that gives us a lot better of a rationale on how we're spending our time and resources on one individual security effort versus another."
The database security world could definitely use this type of guidance, says Andrew Jaquith, senior analyst for Forrester Research and a big proponent for security metrics, in general. Though he's not yet intimately familiar with Lane and Mogull's early groundwork for Project Quant, he believes it will likely fill a need.
"I'd say that one of the reasons Rich and Adrian are doing this project is because databases aren't as well-developed as other areas of security. Metrics are reasonably well-defined for desktop security, vulnerability management, patch management, etc.," Jaquith says. "I've written extensively about these topics, and the Center for Internet Security is doing some fine work developing an industry consensus on how to measure these areas. Database security metrics, though, are less developed."
This is increasingly becoming a problem. As Jaquith points out, databases form the backbone of systems on which companies run their most mission-critical systems. With so much pressure put on database administrators to maintain uptime, that's where their resources, energies, and metrics have gravitated over the years.
"Yesterday's slightly sleepy, back-office databases are suddenly a lot more interesting from a security standpoint. They are increasingly a gold mine for determined thieves," Jaquith says. "Getting a grip on the risks, knowing how to measure your posture, and understanding your key performance indicators is increasingly important for databases."
Lane and Mogull have been working on Project Quant for database security for several months now. The analysts have already developed a loose framework for all of the major subcategories of database security, including configuration and patch management, encryption of databases, development of policies, monitoring and enforcement against those policies, and recording practices for continuous auditing. Under the major categories, they're now working on setting out very granular and discrete processes organizations undertake to manage database risks. As they set these down and try to figure out how much they're costing organizations, the Securosis team is bumping up against a big challenge: getting sufficient community involvement from a very dispersed database security community to validate their findings.
As Lane puts it, he's having a hard time garnering the same type of community involvement that Securosis found for its first Project Quant for patch management because the database security community is made up of a wider variety of stakeholders, many of whom are fractured into discrete communities based on the type of database vendor with which they associate. Oracle DBAs and security pros hang out in one online blogging group, while DB2 DBAs and security pros in another. And often the DBAs and the security pros don't even communicate well with one another.
Lane and Mogull are imploring anyone with a stake in securing databases to step forward and help them make sure they're on the right track with Project Quant's findings. The results, after all, will be freely available to the community.
"We need them to call bupkis on us if what we are writing is incorrect," Mogull says. "What we're writing about has to both reflect reality and give them a path toward something to strive for in terms of best practices. Adrian and I both actually have a background in databases and security, so it's not like we're writing this from nothing. But we really need to make sure that this is the kind of thing that resonates and is useful for the community and reflects their needs."
Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.