Project Quant: Database Security - Configuration Management

By Adrian Lane

First some project housekeeping:

We have now completed the Protect phase of Project Quant for Database Security:

• Protect
  
  1. Monitoring
  2. Encryption
  3. WAF
  4. Masking

For reference, here are the rest of the series links:

• Introduction
• Process Framework
• Planning Part 1
• Planning Part 2
• Discovery (all four subphases)
• Secure
  1. Patch
  2. Configure
  3. Restrict Access
  4. Shield

Next we move into the management phase, where we first cover configuration management.

In the Database Security Planning phase we performed the initial discovery work required to establish basic standards. In the Configuration post we focused on the specific implementation actions needed to configure a database and set baselines. In this specific task we will wrap configuration steps into repeatable management processes to gather information and maintain configuration settings across the entire organization. The steps for assessment and configuration were designed for re-use here. Some of the collection steps are redundant if the number of databases within your organization remains static, but will need to be repeated as new installations are added.

Note that if you are part of a small IT organization, this is a pretty straight forward process. If your work as part of a larger enterprise team, you'll have stakeholders in database administration, audit, IT operations, and security, which makes information collection, distribution and record keeping far more complicated.

Plan

• Identify databases: Identify databases under management. Group as necessary and assign responsibilities for configuration settings and audit verification.
• Time to gather configuration baselines: Based upon previous assessment scans, gather baseline settings for future comparisons.
• Time to specify configuration, policy and rule updates: Changes to internal configuration policies or vendor patch revisions should be accounted for in the policies. Add policies and update remediation information.

Assess

• Time to run scan and gather results (see assessment process). If you are adding databases, account for the entire assessment phase. If assessment scans are on previously scanned databases, the Scan and Distribute Results tasks should be sufficient.

Control

• Time to run configuration process.

Verify

• Time to produce and distribute audit reports: Independent verification of settings, completion of work orders, and production of compliance control reports.
• Time to create/submit work orders and trouble tickets. Remediation of configuration errors to be scheduled. Fix verification can be scheduled as part of normal assessment scans, ad-hoc reporting or inspection.
• Optional: Time to conduct independent audit of configuration settings.

Document

• Time to document changes for policies.
• Time to update recorded baselines.

–Adrian Lane

Project Quant: Database Security - Masking

By Adrian Lane

In our last task in the Protect phase of Quant for Database Security, we'll cover the discrete tasks for implementing data masking. In a nutshell, masking is applying a function to data in order to obfuscate sensitive information, while retaining its usefulness for reporting or testing. Common forms of masking include randomly re-assigning first and last names, and creating fake credit card and Social Security numbers. The new values retain the format expected by applications, but are not sensitive in case the database is compromised.

Masking has evolved into two different models: the traditional Extraction, Transformation, Load (ETL) model, which alters copies of the data; and the dynamic model, which masks data in place. The conventional ETL functions are used to extract real data and provide an obfuscated derivative to be loaded into test and analytics systems. Dynamic masking is newer, and available in two variants. The first overwrites the sensitive values in place, and the second variant provides a new database 'View'. With views, authorized users may access either the original or obfuscated data, while regular users always see the masked version. Which masking model to use is generally determined by security and compliance requirements.

Plan

• Time to confirm data security & compliance requirements. What data do you need to protect and how?
• Time to identify preservation requirements. Define precisely what reports and analytics are dependent upon the data, and what values must be preserved.
• Time to specify masking model (ETL, Dynamic).
• Time to generate baseline test data. Create sample test cases and capture results with expected return values and data ranges.

Acquire

• Variable: Time to evaluate masking tools/products.
• Optional: Cost to acquire masking tool. This function may be in-house or provided by free tools.
• Time to acquire access & permissions. Access to data and databases required to extract and transform.

Setup

• Optional: Time to install masking tool.
• Variable: Time to select appropriate obfuscation function for each field, to both preserve necessary values and address security goals.
• Time to configure. Map rules to fields.

Deploy & Test

• Time to perform transformations. Time to extract or replace, and generate new data.
• Time to verify value preservation and test application functions against baseline. Run functional test and analytics reports to verify functions.
• Time to collect sign-offs and approval.

Document

• Time to document specific techniques used to obfuscate.

–Adrian Lane

Project Quant: DatabaseSecurity - WAF

By Adrian Lane

Deploying a WAF does not fall on the shoulders of database administrators. And it's not really something one normally thinks of when itemizing database security tasks, but that is beginning to change. With database support for web and mobile applications, and PCI requirements overshadowing most commerce sites, WAF is an important consideration for guarding the symbiotic combination of web and database applications.

For this step in the series we are not fully fleshing out a process for WAF deployment, but picking those tasks where database administrative experience is relevant. For some of you this step will be entirely optional. Others will be working with security and application developers to refine rule sets based on query and parameter profiles, and verifying transactional consistency in cases where blocking is employed.

Identify

• Time to identify which databases support web applications.

Investigate

• Time to gather application query & parameter profiles. Collect queries and activity. Analyze query and parameter distribution. Provide profiles to WAF team.

Test

• Time to analyze pre-deployment tests for query/transaction failures.
• Optional: time to re-test new rules or code.

Review

• Variable: Log file review. Find individual requests that are part of more complex transactions, so blocking activity produces side effects. Every time new web application code is released, r a WAF rule changed, it has the potential to cause issues with the database queries as well as the application function. Periodically review log files for anomalies.

Document

• Time to document findings.

As you can see in the diagram, there is a sub-cycle to adjust the database (or provide information back to the WAF team) if the WAF breaks anything at the database level.

–Adrian Lane

Project Quant: Database Security - Encryption

By Adrian Lane

There are several forms of encryption that can encrypt the contents of the database. Each is unique in its level of security, ease of deployment, cost, and performance impact on transaction processing -- making the selection process difficult. Further, security and compliance requirements pertaining to encryption are often murky. They key to this process is understanding the requirements and mapping them to the available technologies. The Evaluate phase is commonly the most time consuming if you are working with compliance requirements.

Pay close attention to operations and integration efforts to ensure no hidden are obstacles discovered after deployment. For example, such as finding that tape archiving no longer works, or that user account recovery fails to recover encrypted data. This type of thing is common, so we've included it in the process.

Evaluate

• Time to confirm data security & compliance requirements. Gather requirements and have a complete understanding of why you are encrypting the database, and the objectives to be met.
• Time to identify encryption method/tools. Select encryption method (database internal, file/OS, disk, etc.) that fully addresses requirements. Identify the tools or products required.
• Time to identify integration requirements. Understand key management, archiving, and password and disaster recovery requirements; determine what integration work is needed.

Acquire

• Variable: time to evaluate encryption tools/products. Select vendors, bring in products, and evaluate in terms of requirements.
• Optional: cost to acquire encryption. If the selected encryption solution is not already available, factor in its additional cost.
• Optional: cost to acquire key management. If key management is external to the database and not already purchased, factor in the additional cost of the product.
• Variable: costs for maintenance, licensing, or support services.

Test & Approve

• Time to establish test environment. Verify product in pre-deployment environment.
• Optional: time to archive database and verify. Create system backups and verify.
• Time to install and configure the encryption tool, including (if needed) any key management integration and user accounts for testing.
• Time to test. Time to complete functional testing and operations assurance.
• Optional: time to establish disaster recovery procedures. Encryption based on external key services, or external to the database, requires additional disaster recovery preparation. Verify your disaster recovery process is updated and required resources are allocated.
• Time to collect sign-offs and approval.

Deploy & Integrate

• Time to install encryption engine in production.
• Time to install key management server (if used) and generate keys. Generate master key pairs and database encryption keys, and distribute.
• Time to deploy, encrypt data, and set up user authorization.
• Time to integrate with applications, backups, and authentication. Verify that operational processes are still viable. Perform required application functional tests.

Document

• Time to document. Record requirements and changes to operational policies.

–Adrian Lane

Project Quant -  Project Comments

By Adrian Lane

We have three Project Quant for Database Security topics to discuss. The answers to Open Question to the Database Security Community (should we include query analysis as part of the project?), are in. I had exactly three 'Yes' responses and three 'No' responses. The 'Yes' group was consistent, saying this would be helpful. The 'No' group was equally consistent, saying "That's application security and does not belong here." Which is exactly the internal struggle we had. As the tie breakers, Rich and I are voting to put code review in. It will be brief and we will focus on those tasks in the database realm.

Throughout the series I have differentiated between policies and rules, but it is worth clarifying the distinction, as it may not be obvious.

• Policy: What you want to accomplish, and the outline of a plan for how to go about it. A policy may be comprised of one of more rules.
• Rule: In this context I am talking about the technical component that gets the work done. This is the code, script, or query that performs the task.

As an example, let's say you want to block SQL injection. That policy might state that you will block queries with specific patterns. If you are aware of a half dozen specific patterns, you might have six specific rules to check against to inbound queries. Or you might have a policy to check databases for buffer overflow attacks. You could have a single rule that checks to see if the database is patched to fix the exploit, or you could use two or three scripts that attempt to exploit the buffer overflow. Tools and platforms such as DAM, VA, or auditing provide a layer of abstraction for you; so you create a policy and the tool builds the rule for you.

Finally, we are looking for input, comments, and suggestions on both the process and metrics we are creating. There is no "industry standard" for database security, and what companies spend varies radically. We could ask "What do you spend today on database security?" but frankly we doubt you know. That's not intended to be insulting, it's just that from the enterprise to small single-DBA IT organizations, this spending is rarely tracked. Or the responsibility is shared across multiple people with other duties. If we asked how much time you spend on database security in any given month, would you have an answer? Would it be a guess?

–Adrian Lane

Project Quant: Database Security - Protect through Monitoring

By Adrian Lane

We have already covered the Monitoring phase, for examining activity and database transactions. In monitoring mode, database activity monitoring (DAM) platforms are deployed "out of band", collecting activity and generating alerts as a third party observer. DAM can also be used to block dubious queries and enforce proper database use. The typical database activity monitoring customer does not employ blocking and can skip this step. For those who do employ DAM to protect databases, understand that we are differentiating between monitoring and protection for several reasons.

1. Blocking is a more advanced DAM feature that can have serious side effects, and is typically employed only after monitoring policies are successfully in place.
2. Policies are based on information discovered through monitoring.
3. Blocking rules are commonly predicated on comparison to a known behavioral profile, with the profile built over time from monitoring output.
4. Blocking warrants more carefully crafted rules to enforce business policies, and on a more practical level additional routine maintenance -- as application queries, database structures, and use cases evolve.

Logically it makes sense to include blocking under the protection phase, but we do it this way because it's much easier to account for the time and resources by splitting blocking into a separate task from normal activity monitoring. The sequence of events is pretty straight forward: you will have something specific you want to address, such as ad-hoc database connections or SQL injection. Identify the databases, create the policy that describes the goal, and then specify the DAM rule or rules that perform the work. DAM tools often provide a level of abstraction, so you set the pre-defined policy, and the rules that form that policy are implemented on your behalf.

Identify

• Time to identify what activity to block. This could be specific queries, connection types, users, or simply undefined actions.
• Time to identify databases to protect.

Define

• Time to create rules and polices. Based on the activity you want to block, fully describe what activity you want to guard against, and define the rules to implement the policy.
• Time to specify blocking method. Depending upon the platform, there are options on how to block activity: within the database, dropping connections, interception of query, etc. Account for the time it takes to compare and select the option you want.
• Time to specify incident handling & review.

Deploy

• Time to deploy blocking rules.
• Optional: time to deploy additional functions. Add installation and configuration costs for features required to block activity. This may include reconfiguration of the network or redeployment of the DAM product.
• Optional: time to build behavioral profiles. If your blocking methodology relies upon user behavior baselines you need to collect activity for comparison.
• Optional: time to integrate with existing systems. If event handling for blocked activity if different than for monitored events, add incremental costs of additional processes or integration work that needs to be performed and was not included in the Monitoring task of the Secure phase.
• Variable: Time to evaluate effectiveness. Evaluate false positive and false negatives and adjustment policies.

Document

• Time to document policies and event handling.

–Adrian Lane

Project Quant: Database Security - Audit

By Adrian Lane

Database auditing is the examination of audit or transaction logs to track changes to data or database structure. Databases auditing is not specifically listed as a requirement in most compliance initiatives, but in practice it fills an essential role by providing an accurate and concise history of business processes, data usage, and administrative tasks -- all necessary elements for policy enforcement. As such, most audit requirements center on tracking a specific set of users, objects, or data elements within the database. Auditing capabilities are built into all relational database platforms, and most of the major platforms offer more than one way to collect transactional information. You may choose to supplement native database auditing with external data sources, but for the scope of this project, we will stick with the more common built-in auditing.

The metrics gathering for database auditing covers scoping the project to understand which databases need which controls, determining how to configure auditing capabilities to meet your requirements, and then periodically collecting the audit trails generated. Day to day management of the audit trails is often an issue, depending upon how many transaction types you want to track. On high-volume transaction severs the data files grow quickly, requiring archival of the audit files so data is not lost, and instructing the database to truncate logs if necessary to avoid filling disk drives to capacity.

Scope

• Time to identify databases.
• Time to identify security goals and compliance requirements. Understand the motivation to audit database events and the needs of external stakeholders.

Define

• Time to select data collection methods. Select audit methods that provide necessary data and meet operational requirements.
• Time to identify users, objects, and transactions of interest. Audits seldom require all activity or transactions to be collected, so specify subset needed.
• Time to specify filtering. To reduce processing and storage requirements, specify audit configuration settings to filter out unneeded events.

Deploy

• Time to set up and configure auditing.
• Time to integrate with existing systems. If sending data to third party SIEM, log management, or reporting tools, set up data collection.
• Time to implement log file management & clean up.

Document & Report

• Time to document.
• Time to generate reports.

–Adrian Lane

Project Quant: Database Security - Monitoring

By Adrian Lane

First some project housekeeping: We have now completed the Secure phase of Project Quant for Database Security: Patch, Configure, Restrict Access, and Shield. Here are the links for the Introduction, Process Framework, Planning Part 1, Planning Part 2, and all four phases of Discovery. Next we move into the monitoring phase, where we first cover database activity monitoring.

Database monitoring is distinctly different from auditing: it provides near-real-time detection, heterogeneous database support, aggregation and correlation, and secure event storage; it also offers more forms of event collection than audit and transaction log files. Securosis has our own definition of database activity monitoring. Databases do not have monitoring built in, rather this function is provided through other products, typically from third parties.

The two primary use cases are security and compliance. The policies to support each will be different, and each option will favor different methods of data collection and warrant integration with different applications used by different stakeholders in the security process. The first step is to identify your goals and outline how the product is to be used. Later you will move on to the selection of a product, development of policies to be enforced, and finall deployment and integration. In this phase we are only covering the monitoring of systems and alert generation, but we will cover blocking and protection in a future post.

Define

• Time to identify databases to protect.
• Time to identify security goals and compliance requirements.
• Time to identify stakeholders. These are the people or departments who receive the reports and decide how to act on them.
• Time to outline process and workflow. Specify how you want the product to work, how it is to be managed, and which systems you wish to integrate with.

Develop Policies

• Variable: Cost to identify and acquire monitoring solution. Assuming a monitoring solution is not in place, the time it takes to evaluate one or more products and the cost of purchasing.
• Time to identify data collection requirements. Depending upon goals, select an appropriate data collection method.
• Time to create rules and polices.
• Time to specify response and incident handling. Each policy will generate information or an alert if a policy violation is detected.
• Time to create report templates. Templates will be used to present summary and detailed findings to stakeholders.

Deploy

• Time to deploy tool.
• Time to deploy policies.
• Time to test controls.
• Time to integrate with existing systems.

Document

• Time to document.
• Variable: Review suitability of controls.

–Adrian Lane

Quant for Databases: Open Question to Database Security Community

By Adrian Lane

Should we cover code and query analysis?

We have an open question about how much coverage, if any, we should provide to embedded application code or query analysis for the purpose of database security. We are on the fence about including SQL Injection prevention (application code changes or use of stored procedures). Obviously code injection remains a major issue for most applications, especially web facing applications as new threats are discovered on a regular basis. SQL Injection attacks are directed at the database, but typically addressed at the application layer or supporting services. It is, however, a capability within the database to thwart SQL Injection through parameter screening and data type matching capabilities provided with stored procedures. For most firms this is handled in the realm of application security.

As such, we would like to defer the question to the community at large: Should we cover query analysis and code injection prevention and develop a process for code verification ad part of this Quant project? Where does this responsibility lay within your organization today? Is it purely part of the application security teams job, or does it fall upon DBA's and database security team?

Please send in your thoughts.

–Adrian Lane

Project Quant: Database Security - Shield

By Adrian Lane

Threats against databases and the information stored therein are not always conventional -- SQL injection and buffer overflow attacks are two of the more common examples. There will be instances where patches for specific threats are unavailable, or security risks are simply inherent to the database features in use. Other exploits leverage weaknesses in database trust relationships, such as Oracle database links, DB2 remote command service, Sybase remote server access, or SQL Server trusted servers. Still others exploit flaws in the underlying network security, such as insecure communication or improperly implemented SSL connections. This task within the Secure phase of the Quant for Database Security project is intended to account for cases where the database is incapable of protecting itself without functional modification or "work arounds".

We are advocating a "Patch and Shield" model to protect the database when patching comes up short. The approach might entail disabling database features, or further refinement to the database configuration. Virtual patching can also be accomplished through firewall, application firewall, or activity monitoring capabilities that block malicious requests. This process is not typically discussed in database vendor recommendations or "best practices", as it directly addresses platform deficiencies and remediation through third party vendors, but is an important step for 0-day protection.

Identify Threats

• Time to identify at-risk databases.
• Time to review ingress/egress points and network protocols.
• Time to identify threats and exploitable trust relationships.

Specify Countermeasures

• Time to identify workarounds. For any given threat, there are normally multiple possible responses.
• Time to specify communication protocol changes. Specify how you want to alter communications with the database, what filtering rules you wish to employ, etc.
• Time to specify connectivity changes. Tune or remove services with implicit trust relationships, and verify existing listeners and network configurations are secure.
• Time to develop regression test case.

Configure

• Time to adjust database configuration.
• Time to adjust firewall/IPS rules.
• Time to install new security controls (e.g., new firewall, VPN, etc.).
• Time to verify changes.

Document

• Time to document.

–Adrian Lane

Project Quant: Database Security - Restrict Access

By Adrian Lane

The next phase in our walk through database security is Restricting Access, through access control systems and permissions. Setting -- or resetting as the case may be -- database access control and account authorization is a major task. Most of the steps within this phase are self explanatory, but for databases with hundreds to thousands of users the amount of time spent on review will be significant. We need to check to see what is in place, compare that with documented polices, and return users and groups to their intended settings. Many users will have elevated permissions granted 'temporarily' to get a specific task done with data or database functions outside of their normal scope, or due to job function changes, but such permissions are often left in their 'temporary' state rather than being reset when no longer needed or appropriate. This form of "permissions creep" is a common problem. For permissions put in place to avoid breaking application functionality or required for certain users to perform temporary tasks, document the variance.

Review Access/Authentication

• Time to collect existing users and access controls (unless collected in Review phase).
• Time to identify authentication methods. Databases can use database, operating system, third party access control, and mixed modes of authentication. Check what is in place.
• Time to determine approved authentication methods. Review prescribed authentication methods.

Determine Changes

• Time to identify user permission discrepancies. Review user and administrative account permissions settings and note variances.
• Time to identify group & role membership adjustments. Inspect roles and groups for members who should not be included. Review roles for unnecessary permissions or capabilities.
• Time to identify password policies and settings. Check that password policies (strength, rotation, failed login attempts, lockout), and not variance to be addressed.
• Time to identify dormant and obsolete accounts.

Implement

• Time to alter authentication methods. Modify settings to meet with established guidelines.
• Time to reconfigure and remove user accounts. Adjust permissions and remove capabilities.
• Time to implement new roles and groups and adjust membership.
• Time to reconfigure service accounts. Review application service accounts for authorization and group membership.

Document

• Time to document changes.
• Time to document accepted variances from configuration.

In our next post we will move on to shielding the database.

–Adrian Lane

Project Quant: Database Security - Configure

By Adrian Lane

The next task in the Secure phase is to configure the databases. In the Planning phase we gathered industry standards and best practices, developed internal policies, and defined settings to standardize on. We also established the respective importance of policy violations, so we can filter critical alerts which require from from purely informational notifications. Then, in the Discovery phase, we gathered a list of databases, gained access to those systems, and implemented the rules we want to run (generally in the form of SQL queries), which are the instantiations of policies from the Planning phase. Now we take the results of our scans and figure out how to configure the databases.

Assess

• Variables: Time to review assessment reports per database. You will have multiple databases and perhaps different types, so add up the time for each.
• Time to analyze failures, policy violations, and incorrect settings. Review the scans and identify policy/rule violations. Identify rules that failed to execute vs. actual misconfigured entries.

Prescribe

• Time to gather itemized issues to address. Order according to criticality.
• Time to select remediation options. Issues may be patching or configuration changes, or workaround options may be available. Specify appropriate response to each policy violation.
• Time to allocate resources and create work orders. If workflow or trouble ticket systems are used, record necessary changes.

Fix

• Time to reconfigure database. Make changes to tables and configuration files as prescribed.
• Time to implement changes and reboot database server. Many configuration changes are not effective until the system restarts.

Rescan

• Number of retries. If assessment must be rerun to verify configuration changes, include subsequent scans.
• Variable: Total cost to rescan. This is the setup, scan, and distribution subset of the Assess phase. For failed policies, calculate cost of rescans.

Document

• Time to document changes. Itemize changes to configuration.
• Time to document accepted variances from prescribed configuration. If policies are not appropriate for a particular database or database type, note the exceptions.
• Time to specify configuration, policy, and rule changes. If rules or SQL queries break due to changes, or there is a need to reflect policy changes in rules used, document required changes.

–Adrian Lane

Project Quant: Database Security - Patch

By Adrian Lane

It's time to move onto the 'Secure' phase of the process (Other sections are DB Security Intro, Planning Part 1, Planning Part 2, & Discovery). The Secure phase is where we implement many of the preventative security measures and establish the secure baseline for database operations. First up is the database patching process.

As you may have read, Rich has already produced a detailed report on Quant for Patch Management metrics and processes. And that work is certainly applicable to what we are doing here. In essence I am going to use the same process, but reduce the level of detail in the metrics to focus in on areas where you will spend the majority of your resources and omit anything not relevant to database patching. If you feel you need that level of detail for database patch management, I won't discourage you from going back and usage that as a guide. For major revisions and releases, that version will provide necessary granularity. For database security patches this process is more than adequate.

There are two types of DBAs out there: those who are more paranoid than busy, and those who are too busy to be paranoid. The later group does what I like to call "patch and pray": install the patch and pray it works. If it crashes your database you scramble to roll it back out and recover. I know a lot of DBAs for small businesses who use this model, and for the most part, the patches work and they get away with it. The other group sets up a test environment, creates acceptance tests cases, tests and bundles their approved version, plans the rollout carefully, and finally executes. This is more typical for enterprises or firms where database downtime is simply not an option and the resources are available. Regardless of which model you follow, evaluation and testing will comprise the bulk of your effort in this phase.

Security patches are a little different than general products updates to fix bugs. If you are experiencing a functional problem with an application, you know for certain that you need a certain patch and already possess some understanding of how critical that issue is to your firm. Most DBAs may not be aware of what sort of exposure, or be able to assess risk based upon known exploits. If you don't have a security group helping with the analysis, the evaluation process is often based on matching critical weaknesses to database features used within the environment. If you find a critical vulnerability you patch right away; otherwise you wait for the next patch cycle.

Database vendors make it easy to locate and obtain patches. Security patches are well publicized and alert notices are commonly emailed to DBAs when they become available. Keep in mind that some of the database patches require updates to the underlying operating system kernel, libraries, or modules, and the evaluation process needs to cover those updates as well.

Evaluate

• Time to monitor sources for advisories -- per DB type/per release: Review database vendor alerts and industry advisories.
• Time to identify which patches are applicable per database: Not all security patches are necessary for your environment. Identify patches that correspond to database type/function in use, & OS platform; then evaluate based on vendor criticality.
• Time to identify workarounds: Identify if workaround are available, and whether they are appropriate.
• Time to determine priority: Determine your operational priority for patching.

Acquire

• Time to acquire: Time required to locate and acquire patch(es).
• Variables: Costs for maintenance, licensing or support services: Updates to vendor maintenance contracts. Cost for consultants or managed service providers.

Test & Approve

• Time to develop test cases and criteria: Cost to develop functional, security, or acceptance test cases.
• Time to establish test environment: Time required to locate and gain access to testing personnel, tools, and platforms needed to verify patches.
• Variables: time to test: Time to run tests. May require multiple tests sweeps depending on test cases, resources, and configuration.
• Time to analyze test results.
• Time to establish approved packages/versions: Time to package verified versions of database and platform patches.

Deploy & Confirm

• Time to schedule and notify: Schedule personnel and resources; communicate database maintenance schedule to application users.
• Time to install: Total time to take database offline, perform backups/snapshots, install patch, bring database back online, and reconnect applications.
• Time to verify installation: Basic functional testing of core services and security tests.
• Time to clean up: Remove temp files, database snapshots, or rollback files.

Document

• Time to document: Workflow software, trouble ticket response, compliance change reports, and a record of what you did are all important aspects of this task.

–Adrian Lane

Project Quant: Database Security Discovery

By Adrian Lane, Rich

We decided to slow this series down for the holidays, as we are at a point where participation from the user community is very important. With the new year we are kicking back into high gear, and encourage comments and critiques of the processes we are describing. Picking up where we left off, we are at the Discovery phase in the database security process, a critical part of scoping the overall work.

Personally, discovery and assessment is my favorite step in the database security process. This step was the one that always yielded surprises for my team. Enterprise databases were present we did not know about. Small personal databases, perhaps even embedded in applications, we did not know about. Production data sets on test servers, tables with sensitive data copied into unsecured table-spaces, or cases where replication was turned on without our knowledge. This is over and above databases that were completely misconfigured -- usually a new DBA who did not know any better, but sometimes intentionally disabled to make administration easier. I have had clean scans on a Monday, only to find Friday that there were dozens of critical issues. And that's really what we want to determine in the Discovery phase.

Before we can act on the plan we developed in the previous section (Planning, Part 1 and Part 2), we must determine the state of the database environment. After all, you have to know what's wrong before you can fix it. What databases are in your environment, what purposes do they serve, what data do they host, and how are they set up? The first step in this phase is to find the databases.

Enumerate Databases:

In this stage we determine the location of database servers in the organization.

1. Plan: How are you going about scanning the environment? What parts of the process are automated vs. manual? Make sure you have clear guidelines. Refine scope to portions of IT, database type of interest. Also note that the person who created the plan may not be the person who runs the scan. Make sure that the data needed (database name, port number, database type, etc.) for subsequent steps is communicated or this entire process will need to be run again.
2. Setup: Acquire and install tools to automate the process, or map out your manual process. Configure for your environment, specifying acceptable network address and port ranges. Network segmentation will alter deployment. Databases have multiple connection options so plan accordingly. If you are keeping scan results in a database, create structures and configure.
3. Enumerate: Run your scan, or schedule for repeat scanning. Capture the results and filter out unwanted information to keep the data in scope for the project. Record as you baseline for future trend reports. In practice you will run this step more than once. As you discover databases you did not know existed, determine credentials you were provided are insufficient, or find subsequent steps require more information than you collected. Schedule to repeat scanning at periodic intervals. If you are using a manual process, this consists of contacting business units to identify assets and manually assessing each system.
4. Document: Format data, generate reports, and distribute. Use results to seed data discovery and assessment tasks.

Database discovery can be performed manually or automated. Segmented networks, regional offices, virtual servers, multi-homed hosts, remapping of standard ports, and embedded databases are all examples of common impediments you need to consider. If you choose to automate, most likely you are going to use a tool to examines network addresses and interrogate network ports, which may not yield all database instances but should capture the database installations. If you are using network monitoring to discover databases you will miss some. Regardless of your choice, you may not find everything, at least in the first sweep, so consider scanning more than once. In a manual process you will need to work with business units to identify databases, and perform some manual testing to identify any unreported databases. Understand what data you need to produce in this part of the process as your results from database discovery will be used to feed data discovery and assessment.

Identify Applications, Owners, and Data:

Now we take the identified databases and identify application dependencies, database owners, and the kinds of data stored.

1. Plan: Develop a plan to identify the application dependencies, data owners, and data types/classifications for the databases enumerated in the previous stage. Determine manual vs. automated tasks. If you have particular requirements, specify and itemize required data and assign tasks to qualified personnel. Define data types that require protection. Determine data collection methods (monitoring, assessment, log files, content analysis, etc.) to locate sensitive information.
2. Setup: Databases, data objects, data, and applications have ownership permissions that govern their access and use. For data discovery create regular expression templates, locations, or naming conventions for discovery scans. Test tools on known data types to verify operation.
3. Identify Applications: For applications, catalog connection methods and service accounts where appropriate.
4. Identify Database Owner(s): List database owners. Database owners provide credentials and accounts for dedicated scans, so determine who owns database installations and obtain credentials.
5. Discover Data: For data discovery return location, schema, data type, and other meta-data information. Rule adjustment requires re-scanning.
6. Document: Generate reports for operations and data security.

In essence this series of tasks is multiple discovery processes. Discovering the applications that attach to a database and how it is used, and what is stored within the database, are two separate efforts. Both can be performed by a credentialed investigation of the platform and system, or by observing network traffic. The former provides complete results at the expense of requiring credentials to access the database system, while passive network scanning is easier but provides incomplete results.

If you have existing security policies or compliance requirements data discovery is a little easier, as you know what you are looking for. If this is the first time you are scanning databases for applications and data, you may not have precise goals, but the results still aid in other activities. Manual discovery policies requires you to define the data types you are interested in detecting, so planning and rule development requires significant time in this phase.

Identification of applications and data provides information necessary to determine security and regulatory requirements. This task defines not only the scope of the scanning in the next task, but also subsequent monitoring and reporting efforts in different phases of this project.

Assess Vulnerabilities & Configurations:

Database Assessment is the analysis of database configuration, patch status, and security settings. It is performed by examining the database system both internally and externally -- in relation to known threats, industry best practices, and IT operations guidelines. It is important to note that with assessment, there is a large divide between having requirements and the tools or queries that gather the information. The setup portion of this task, particularly in script development, takes far more time than the scans themselves.

1. Define Scans: In a nutshell, this is where you define what you wish to accomplish. Compile a list of databases that need to be scanned, and determine requirements for different database types. Investigate best practices, security and compliance review for both internal and external requirements. Assign scans for proper separation of duties.
2. Setup: Determine how you want to accomplish your goals. Which functions are to be automated and which are manual? Are these credentialed scans or passive? Download updated policies from tools and database vendors, and create custom policies where needed. Create scripts to collect the information, determine priority, and suggest remediation steps for policy violations.
3. Scan: Scans are an ongoing effort, and most scanning tools provide scheduling capabilities. Collect results and store.
4. Distribute Results: Scan results will spotlight critical issues, variations from policy, and general recommendations. Filter unwanted data according to audience, then generate reports. Reporting includes feeding automated trouble ticket and workflow systems.

Database discovery, data discovery, and database security analysis are conceptually simple. Find the databases, determine what they are used for, and figure out if they are secure. In practice they are much harder than they sound. If you run a small IT organization you probably know where your one or two database machines are located, and should have the resources to find sensitive data.

When it comes to security policies, databases are so complex and the threats evolve so rapidly that definition and setup tasks will comprise the bulk of work for this entire phase. Good documentation, and a method for tracking threats in relation to policies and remediation information, are critical for managing assessments.

Authorization and Access:

In this stage we determine how access control systems are configured, then collect permissions and password settings.

1. Define Access Requirements: Man hours to obtain the list of databases you need to assess access controls for. Man hours to discover how access controls are performed; which functions are at the host or domain level, and how these services are linked to database permissions. Determine what password checks are to be employed.
2. Setup: For automated scans: cost to acquire, install and configure the tools. Time to obtain host/database permissions needed to perform manual and automated scans. Man hours needed to collect documented roles, groups, or service requirements for user of the database in later analysis. Cost of tools and time to generate report templates for stakeholders who will act upon scan results. If password penetration testing or dictionary attacks for weak passwords are being used, select a dictionary.
3. Scan: Variable: Man hours to run scan for database users showing group and role memberships, and then to scan groups, roles, and service account membership for each database. Man hours to collect domain and host user account information and settings.
4. Analyze & Report: Administrative roles need to be reviewed for separation of duties, both between administrative functions and between DBAs and IT administrators. Service accounts used by applications must be reviewed. User accounts need to be reviewed for group memberships and roles. Groups and roles must be reviewed to verify permissions are appropriate for business functions.

Database authorization and access control is the front line of defense for data privacy and integrity, as well as providing control over database functions. It's also the most time intensive of these tasks to check, as the process is multifaceted -- needing to account not only for the settings inside the database, but how those functions are supported by external host and domain level identity management services. This exercise is typically split between users of the database and administrators, as each has very different security considerations. Password testing can be time-consuming depending and, depending upon the method employed, may require additional database resources to avoid impact on production servers.

–Adrian Lane, Rich

Project Quant: Database Security Planning, Part 2

By Adrian Lane, Rich

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, Rich