Project Quant: Database Security Planning

This is the third post in our series on Project Quant for Database Security (see Part 1 & Part 2). The first step in our metrics process framework is to gather requirements and plan out your security program. Just as with any development project, your motivation and goals should be documented up front, and later used to gauge the success of your effort. Like most IT projects, gathering requirements is a large part of the work.

I want to clarify a couple points based on comments we have received to date, before I delve into planning. As Rich pointed out at the beginning of the previous post, database security is an incredibly broad subject, comprised of several specific elements. The original Project Quant for Patch Management focused on the nuances of a single IT task, whereas this database security project includes a minimum of four separate efforts. We originally planned to create a separate process for each effort: configuration management, auditing & monitoring, access control, and data protection. Heck, we even considered breaking down configuration management into smaller subtasks. When we dug in one afternoon to start identifying specific actions, we realized there was both a lot of overlap between our initial processes, and a number of important functions they missed. Instead, we came up with the generalized process framework we introduced in Part 2, with a series of sub-processes.

We know this won't exactly match everything you do, but as with Project Quant for Patch Management, we are proposing a generic framework that encompasses most possible activities, from which you can pick and choose to meet your own needs.

In Quant for Patch Management, we also found that a handful of the metrics accounted for the bulk of the costs. Some 30% did not have material impact on overall cost. Based on our initial research the same is true with database security, so we want to provide a lot more breadth in this series and focus on principal metrics, foregoing the level of detail we used in PQPM. We will mention these extra tasks in each phase, but leave it up to readers to include any additional cost metrics which are useful in their own analysis.

For the planning stage, we include Configuration, AAA, Monitoring, and Classification. Starting with Configuration Standards:

1. Identify Requirements: Requirements include everything from adopting database security best practices to PCI compliance. They may originate from external or internal sources. Requirements, especially for industry and regulatory compliance, are generic and require some interpretation. Directives such as "implement separation of duties" or "secure the database from SQL injection" are common. In other cases specific security advisories from CERT or patches from vendors are less ambiguous, but still require analysis to determine suitability. Identify sources of information and identify requirements appropriate to your situation, including vendor-provided security configuration guides, NIST, and the Center for Internet Security.
2. Develop Standards: Starting from security or compliance requirements, which portions are relevant to you? This is where you specify standards needed to satisfy requirements. Select settings, controls, and standards as necessary, pulling from the sources and matching your requirements.
3. Choose Implementation: Most database security functions can be accomplished in more than one way. For example, "capture failed logins" can be satisfied through external monitoring or internal auditing. Satisfying a requirement on Oracle may be accomplished differently than on SQL Server. Don't get bogged down into specifics, but select a strategy that meets you standard and fits your operational model.
4. Document: Record your findings and your decisions. If you are going through this process, odds are there are other people involved who will need to understand and adhere to the standard.

For many of you, you are probably saying to yourself "Holy @&!^@, just planning is a huge effort! Where do I begin?" Identifying requirements for database security or PCI or whatever is lengthy and complex, and it's not clear where to find this information. And I am being a hypocrite here, doing exactly what I have said you should not do and criticized others for: dropping a big, hairy task in your lap without pragmatic advice. While our focus in this project is identifying and quantifying costs to secure databases, we can't totally ignore what it takes to do the work, and we need to provide a some specific advice along the way. I will provide much more detail later in this series with use cases, but for now I can provide a couple pointers to steer you in the right direction.

Database configuration affects security as well as database function. For planning purposes you will be considering installation or removal of functions, network communications, platform versions, structures, use of underlying hardware or OS resources, physical location, and reliance on external programs/functions. All of these database functions are impacted by access control because appropriate use is determined by ownership and access, but we want to start with the basic capabilities and refine from there.

Start your effort by locating sources of information and standards bodies. What are others doing to meet security requirements? The database vendors are a good place to start, as they provide recommend setup and configuration, and list recent security notifications. Leverage security and operations personnel within your company to highlight security issues. Look to local DBA groups for advice on how they set up databases securely. As far as compliance, you can wade through the law doing your best to understand it, but if you have co-workers who specialize in audit and compliance, ask for assistance. If you company has security guidelines in place you are lucky, so use them to help scope the set of tasks. These are the steps many companies must perform, but research and discovery is a very large part of the process and typically an overlooked when costing.

I am going to keep this post short to encourage feedback on the general approach first. Rather than inundate you with details, I will cover the remaining three preparation steps in the next post.

—Adrian Lane