Project Quant: Database Security Planning, Part 2

In our last post on Project Quant for Database Security Metrics, we started to examine Planning. To finish Planning, we need to address access controls, database monitoring, and data classification strategies. Once again, we are following the pattern of determining requirements, determining how the requirements apply to the business, figuring out how to accomplish the goals, and then documenting intentions. We will list the specific metrics later in this series, but at this stage research time will be the biggest cost.

AAA

Access controls and authorization are the most complex database security area we will cover, and given the fluidity of users and rules the one most likely to create security issues by varying from the specification. Databases have three classes of users: administrators, database programmers, and application users -- each with very different needs. It is important to plan for additional users and roles, as database use cases change. It is very important to have a plan for revoking permissions quickly without impairing general usage. I hate to say "expect the unexpected", but with database access control planning, it's particularly useful to provide some flexibility in advance. Access control planning impacts many other database security efforts, especially with data classification and privacy policy enforcement.

1. Define Requirements: What are the access control guidelines? Determine which business functions are being supported, which systems support those functions, who needs access to the system, and what facilities they are allowed to use. For administrative roles, determine what tasks are performed. Identify additional security and compliance requirements.
2. Define Groups, Roles, & Ownership: Based upon requirements, develop roles and groups to support business functions and enforce security constraints. Determine object and data ownership and formulate a permissions model for the database, schemas, and tables. Plan how users will obtain permissions, revocation, and use cases not accounted for in the model. Identify service account usage.
3. Define Implementation: Database permissions are established within the database, and externally from the database. Define which facilities are responsible for policy enforcement. Define method for verification of policy. Remember, this is a strategic planning exercise; don't get too bogged down in the details.
4. Document: Document requirements. Clarify database use models from administration. Train administrative staff on policy.

Remember that this is the planning stage, and is either focused on general requirements (policies for administrator accounts), or planning for a specific database. For existing systems, we'll document their current AAA configurations in later phases.

Monitoring

Database monitoring verifies database usage. It provides near-real-time analytics to detect usage violations, usage profiling, and anomaly detection. While secure configuration serves as a preventative control; monitoring is detective, and used to verify the database is being used as intended. Think of it as similar to having black and white lists for database transactions. But to build those lists, you need an idea of what you wish to accomplish, or what activities should never occur. As every database is used differently, you have to define what is appropriate and what isn't. Identify events you are interested in, then define acceptable behaviors and outcomes.

1. Define Activities: Investigate business processes. Define critical operations and functions. What activities does the system support, and what subset are you interested in monitoring. Identify security and compliance in relation to data privacy, fraud detection, and system misuse.
2. Define Violations: Determine which events indicate problems. Consider users, time of day, function, data volume, and other available attributes that can identify suspect transactions. Identify criticality of events and specify desired response. Consider periodic review of general database usage in order to refine policy.
3. Identify Event Collection: How will you capture events? Determine what event collections are available. Map policies to event collection for misuse detection.
4. Define Event Notifications: When a policy violation is discovered, how will you react? Specify how event notification will happen and who will be responsible.
5. Document: Ensure all concerned parties are aware of their responsibilities and coordination points with other groups.

Classification

Data classification for databases is a necessary step for many compliance and data privacy regulations. In a practical sense, it often devolves into a giant data labeling or classification project that wastes time and effort. You will need to investigate requirements and best practices, but we recommend that you avoid using an overly detailed model that nobody will actually use. Figure out what needs to be secure, but be general and pragmatic your data security approach.

1. Identify Requirements: What is your high level scheme? What is considered sensitive, and how will you define it?
2. Specify Data Security: What will you do with sensitive information? Formalize intent and security levels for the different data types, and different audiences for the information.
3. Select Access Method: What is your classification model? Siloed, hierarchical, and labeling are all options.
4. Map to AAA: How will your access control system implement the data security model. Based upon the security model, map access controls to systems capabilities. This step comes after access control review, but iterative adjustments to the plan are common. These models are implemented on top of access controls, but in some cases underlying data features such as labeling support more granular control.
5. Document: Data classification affects usage, requiring education of users, IT, and application developers.

Keep in mind that this is all strategic planning. At this stage of analysis you will not be examining specific statements or policies. During this planning, there is a tendency to begin delving into implementation specifics that are simply not helpful at this stage. Focus on the big picture: how data moves and is used within the organization. This series will delve into the specific later.

—Adrian Lane