Login  |  Register  |  Contact

Project Quant: Database Security Process Framework

Here's our first pass at a high-level process framework for Quant for Databases. Patch management is mostly a contiguous process cycle, but database security encompasses a bunch of different processes. This is a framework I originally used in my Pragmatic Database Security presentation (which I really need to go post now).

I realize this is a lot, but database security is a pretty broad topic -- from patch management, to auditing, to configuration, to encryption, to masking, to... you get the idea. We believe that the high level process framework presented here is intended to cover all these tasks. We could really use some feedback on how well this encompasses all the database security processes. We based this process on our own experience and research contacts, but want to know how you approach these job functions.

Our next step will be to roll through all the sub-processes within each of these major steps. We don't plan to get as detailed as we did with patch management. Many of the metrics provided in the original Quant project for patch management were extremely granular since we were dealing with only one process. We still need sufficient granularity to develop meaningful metrics that support process optimization, but at a level that's a little easier to collect, since we are covering a wider range of functions.

Please keep in mind that our philosophy is to build out a large framework with many options, which individual organizations can then pick and choose from. I know not everyone performs all these steps, but this is the best way to build something that works for organizations of different sizes and verticals.

Plan

In this phase we establish our standards and policies to guide the rest of the program. This isn't a one-time event, since technology and business needs change over time. Standards and policies should be considered for multiple audiences and external requirements.

  1. Configuration Standards: Develop security and configuration standards for all supported database platforms.
  2. Classification Policies: Set policies for how data will be classified. Note that we aren't saying you need complex data classification, but you do need to establish general policies about the importance of different kinds of data (e.g., PCI related, PII, health information) to properly define security and monitoring requirements.
  3. Authentication, Authorization, and Access Control Policies: Policies around user management and use of accounts -- including connection mechanisms, DBA account policies, DB vs. domain vs. local system accounts, and so on.
  4. Monitoring Policies: Develop security auditing and monitoring policies, which are often closely tied to compliance requirements.

Discover and Assess

In this phase we enumerate (find) our databases, determine what applications use them, what data they contain, and who owns the system and data; then assess the databases for vulnerabilities and secure configurations. One of the more difficult problems in database security is finding and assessing all the databases in the first place.

  1. Enumerate databases: Find all the databases in your environment. Determine which are relevant to your task.
  2. Identify applications, owners, and data: Determine who is responsible for the databases, which applications rely on them, and what data they store. One of your primary goals here is to use the application and data to classify the database by importance and sensitivity of information.
  3. Assess vulnerabilities and configurations: Perform a configuration and vulnerability assessment on the databases.

Secure

Based on the results of our configuration and vulnerability assessments, we update and secure the databases. We also lock down access channels and look for any entitlement (user access) issues. All of these requirements may vary based on the policies and standards defined in the Plan phase.

  1. Patch: Update the database and host platform to the latest security patch level.
  2. Configure: Securely configure the database in accordance with your configuration standards. This also includes ensuring the host platform meets security configuration requirements.
  3. Restrict access: Lock down access channels (e.g., review ODBC connections, ensure communications are encrypted), and check user entitlements for any problems, such as default administrative accounts, orphan accounts, or users with excessive privileges.
  4. Shield: Many databases have their own network security requirements, such as firewalls or VPNs. Although directly managing firewalls is outside the domain of a database security program, you should still engage with network security to make sure systems are properly protected.

Monitor

This phase consists of database activity monitoring and database auditing. We'll detail the differences later (you can up on them in the Research Library), but monitoring tends to be focused on granular user activity, while auditing is more concerned with traditional audit logs. Both of these tie into our policies from the Plan phase and vary greatly based on the database involved.

  1. Database Activity Monitoring: Granular monitoring of database user activity.
  2. Auditing: Collection, management, and evaluation of database, system, and network audit logs (as relevant to the database).

Protect

In this phase we apply preventative controls to protect the data as users and systems interact with it. It includes using Database Activity Monitoring for active alerting, encryption, data masking for data moved to development, and Web Application Firewalls to limit database attacks via web applications.

  1. Database Activity Monitoring: In the Monitor phase we use DAM to track activity, in this phase we create active policies to generate alerts on violations or even block activity.
  2. Encryption: Activities to support and maintain encryption/decryption of database data.
  3. Data masking: Conversion of production data into less sensitive test data for use in development environments.
  4. Web Application Firewalls: Since many database breaches result from web application attacks, typically SQL injection, we've included WAFs to block those attacks. WAFs are one of the only post-application-deployment tools available to directly address database attacks at the application level. (We considered adding additional application security options, but aside from secure development practices, which are well beyond the scope of this project, WAFs are pretty much the only tool designed to actively protect the database.)

Manage

The triumvirate of ongoing systems and application management -- configuration management, patch management, and change management.

  1. Configuration management: Keeping systems up to date with configuration standards... including standards that change over time due to new requirements.
  2. Patch management: Keeping systems up to date with the latest patches.
  3. Change management: Databases updates on a regular basis; including structural/schema changes, data cleansing, and so on.

Yes -- that's a whole heck of a lot of territory to cover, which is why I stayed fairly terse in this post. In talking with Adrian (who is co-leading this project) we think most organizations lump this activity into 3 buckets/sub-processes:

  1. Normal database management activities: primarily configuration and patch management -- typically managed by database administrators.
  2. Database assessment.
  3. Monitoring and auditing.

No, that doesn't capture everything in the main process, but that's how most organizations which have database security programs break things out. We have simplified the tasks at the high level, but requirements and policies may come from groups external to database operations -- such such as security, privacy, audit, and compliance. If you are a DBA reading this overview process, you could go through this exercise to build out your cost model for simple operations very quickly. The model will hopefully scale just as well for organizations with more complex systems, but will take longer to account for all of your requirements.

This brings up two big questions we could use some help with:

  1. Does the structure work? You'll notice I didn't list this out as one straight process, but as a series of ongoing, overlapping, and related processes.
  2. Are we missing anything? Should we move anything? Insert, update or delete?

Thanks... in our next posts we're going to start walking through the model and detailing all the sub-processes so we can come back to them and build out the metrics.

Index to other posts in Project Quant for Database Security.

  1. An Open Metrics Model for Database Security: Project Quant for Databases.
  2. Database Security: Process Framework.
  3. Database Security: Planning.
  4. Database Security: Planning, Part 2.
  5. Database Security: Discover and Assess Databases, Apps, Data.
  6. Database Security: Patch.
  7. Database Security: Configure.
  8. Database Security: Restrict Access.
  9. Database Security: Shield.
  10. Database Security: Database Activity Monitoring.
  11. Database Security: Audit.
  12. Database Security: Database Activity Blocking.
  13. Database Security: Encryption.
  14. Database Security: Data Masking.
  15. Database Security: Web App Firewalls.
  16. Database Security: Configuration Management.
  17. Database Security: Patch Management.
  18. Database Security: Change Management.
  19. DB Quant: Planning Metrics, Part 1
  20. DB Quant: Planning Metrics, Part 2

—Rich

Posted at Wednesday 18th November 2009 10:03 am Filed under:

Previous entry: Microsoft Encryption and the Cloud | | Next entry: Three acquisitions, two visions

Comments:

If you like to leave comments, and aren't a spammer, register for the site and email us at info@securosis.com and we'll turn off moderation for your account.

By Russell Thomas  on  11/18  at  01:06 PM

A question and a few suggestions:

Q: Is your framework intended to be normative (what people *should* do) or positive (what people *are* doing or *could* do, without value judgments)?  It would be very helpful to be clear about this from the start, otherwise it will be very hard to manage scope, detail, and communication.

Suggestions:

1. Database security exists within a larger context of enterprise architecture (IT and business), IT application design and deployment, and also stakeholder culture and incentives.  Your framework above doesn’t include any of that context, or the security actions/practices that influence the context. 

For example, should the organization even be storing certain types of data, given the risks?  How can the data govenance processes be designed so that data owners (i.e. business folks) will make better risk/reward decisions?  How can security be designed into IT applications that use databases, rather than added on afterward?  How much should an organization plan to spend on security and protection relative to other database spending?  What hiring, training, and certification standards should be used for critical data management jobs?  What about insourcing vs. outsourcing decisions?

Maybe you could add a process step under “Plan” called “Collaborate in Data Policy Decision Making” to cover all this.  Any security function that is *not* doing this is not doing their job, IMHO.

2. In a related note, all of your process activities seem to focus on “what security/DBA people do”.  What about all the security activities performed by non-security people?  Examples include data policies, data classification, training, forensics, financial/risk analysis, legal (contracts, IP, etc.), and business continuity?  Even if you don’t include these explicitly, I think you should have hooks or stubs for these essential related processes.

3. Many of your process steps require an understanding of the underlying business processes, business requirements, and business policies (e.g. “Audit”, “restrict access”, etc.).  Therefore, I suggest that you add “Understand the Business” under the “Discover and Assess” process.  As the 7 Habits guy says: “Seek first to understand”. (Also See Gunnar Peterson’s blog post about collaboration: http://1raindrop.typepad.com/1_raindrop/2009/11/want-security-get-in-the-same-boat.html . His point is that security people operate in isolation too often.)  Same goes for IT development processes, both internal and also by major vendors and outsource partners.  BUILD IN SECURITY!

4. Under “Manage”, I suggest that you include an item for “security performance management” or “security risk management”.  This would include activities involving metrics, experiments, forensics, costing, and risk analysis specifically related to databases.  This subprocess would also involve collaboration with people in the organization who are responsible for data quality, generally.  Including this item is a judgment call, since you could separate it out as a overarching security management process covering all aspects of security, privacy, IP protection, etc.

——-

If we include these suggested activites, I wouldn’t be surprised if they amounted to 10% to 30% of total database security costs, outside of the core DBA or DB security tasks/projects.

Hope this helps,

Russ

By Russell Thomas  on  11/18  at  02:07 PM

I have a meta-suggestion regarding terminology.

Maybe instead of “Processes” and “Subprocesses”, you could frame these as “Capabilities”, “Sub-capabilities” and “Recipes”.

At the risk of sounding pedantic, I’ll describe the definitions and differences.

“Processes” are typically work flows, information flows, decision-making or calendar-oriented projects.  In the language of Business Process Management, they typically have a clear entry (or input) point, flowing through to a clear exit (or output or completion) point.  Processes transform something or control something, adding value along the way.  Processes are managed to optimize throughput, productivity, cycle time, response time, quality (defect rate), and so on.  Nearly all of these management goals have an input/output relationship or a time dimension, or both.  Processes, for the most part, are fairly easy to capture in a formal diagram.

By contrast, “capability” is a less specific and less constrained concept, and emphasizes other characteristics.  By definition, a “capability” is a dimension of performance or the ability to perform in response to certain conditions, demands, or requirements.  Simplistic example: if I’m camping with a simple pocket knife, I have the capability to cut small food items, butcher prey, stir food as it’s cooking, open a can (with great difficulty!), but no capability to eat hot soup (unless I fabricate a wooden spoon).

Capabilities are created from combinations of people, processes, technology, and institutional knowledge, which may be explicit or tacit.  Focusing on capabilities is most helpful when you are managing for agility and flexibility in the context of a fast-changing or an unknown environment or when you are primarily responding to external triggers or unforeseen opportunities/risks.  Capabilities are often viewed as a portfolio rather than as a fixed configuration.  Capabilities are not easily mapped in a formal flow diagram, but they can be formally defined and assessed.

Within or between capabilities you can define “recipes” which are ways of achieving specific performance goals using available capabilities.  These may be well-defined processes or procedures, or may be ad hoc methods.  They might be an “overlay” on other processes or activities.  The outputs or results may be clearly defined or might be open-ended.

The word “recipe” is chosen to emphasize flexibility, invention, context-sensitivity but also internal coherence.  Many good recipes are possible with the same ingredients (a.k.a. capabilities), depending on how the cook treats them and combines them.  Following a recipe doesn’t guarantee success or quality—execution skill matters!

Using terminology of “capability” and “recipes” for Data Base Security Framework will help promote the idea that organizations will “mix and match” these according to their needs, priorities, and stage of maturity.  Hopefully, this shift in terminology will help avoid confusion and aid in adoption.

Russ

(P.S. There is a major theory in the economics called “Resource-based Theory of the Firm” that is centered on the idea that competitive advantage and long-run profitability depend on having unique, hard-to-replicate resources/capabilities.  Unfortunately, the academics haven’t done a good job defining “capabilities” in a way that business people can implement and manage.)

By ds  on  11/19  at  06:49 AM

Secure and Manage feel redundant in the main process.  Seems you’ve felt this too and collapsed them in your more streamlined 3 step.

By Adrian Lane  on  11/22  at  07:59 PM

Thanks for the comments. I’ll try to answer/clarify/comment as best I can but I am certain to miss something. 

This is not a guide for what you should be doing with your database(s). This is not a list of recommended practices, nor are we trying capture the entire universe of possibilities. This is a guide to create a process oriented cost model for database security efforts. 

I hope it will be used to understand where you spend time and effort, to compare one operational model to another (is it worth investing in automation or stick with manual processes), and to even compare different tools to solves problems (is auditing appropriate or do I need to invest in monitoring). 

There are several points I want to emphasize that I think cover your questions, and line up with some of the recommendations you have made. 
1. As Rich proposed at the beginning of the post, this is an incredibly broad range of topics. We originally planned to produce four separate database security processes; patching, auditing, assessment & configuration management,  and monitoring. But if you were following along with the original Quant for Patch Management, going through that process 4 separate times was not particularly helpful given overlap (which you will see in the next couple of posts). Besides, the level of granularity that was provided with the original series proved to have diminishing returns, meaning there are a handful of very relevant metrics if you are trying to get a handle on the overall costs that will get you 90% of the way there. The rest allow you to fine tune, but their usage is not particularly pragmatic.
2. When going over these four processes it was abundantly clear that they were more alike than they were different. The steps were so similar that we felt it made sense to create a single process framework that encompassed these four efforts. While the terms we used are not as precise as they would be if we had split this to four separate processes, we think it is practical and beneficial to have a single process for people to work through.
3. Compliance and security, for database systems, are very similar efforts. Regardless of industry or government regulation, and regardless of the nature of the controls (preventative, detective), the check list of requirements will be very similar, and this process will work for security and compliance equally. This was one of my sticking points and I spend last weekend going through some compliance 200 policies, mapping them into the frameworks to see if there were issues we had not accounted for.  I did not find anything, but I certainly may have missed something. While I am not always totally comfortable about which bucket some of these tasks should go in, as the order of events may vary depending upon your preference, I believe the framework accommodates the effort.
4. Database security is influenced by DBA’s, application development, corporate privacy policy, IT operations, internal audit and data security practitioners. I may have missed one or two, but the point is that there are many stake holders involved here who have a say into policy but not implementation. I have not run across a case where the framework will not accommodate cost estimation of the task.  If you have a specific use case you don’t think works, let’s discuss on the forum page. I want to revisit these comments once we have jumped into the details of the first planning phase to see if we have accounted for the different audiences.

Finally. Thanks for the suggestions on terminology. I want to think about the suggestions a little longer and discuss with Rich to get his impressions as well.

-Adrian

Page 1 of 1 pages

Name:

Email:

Remember my personal information

Notify me of follow-up comments?

Submit the word you see below: