Database Assessment

Understanding and Choosing a Database Assessment Solution, Part 6: Administration

By Adrian Lane

Reporting for compliance and security, job scheduling, and integration with other business systems are the topics this post will focus on. These are the features outside the core scanning function that make managing a database vulnerability assessment product easier. Most database assessment vendors have listed these features for years, but they were implemented in a marketing "check the box" way, not really to provide ease of use and not particularly intended to help customers. Actually, that comment applies to the products in general. In the 2003-2005 time frame, database assessment products pretty much sucked. There really is no other way to capture the essence of the situation. They had basic checks for vulnerabilities, but most lacked security best practices and operational policies, and were insecure in their own right. Reliability, separation of duites, customization, result set management, trend analysis, workflow, integration with reporting or trouble-ticketing -- for any of these, you typically had to look elsewhere. Application Security's product was the best of a bad lot, which included crappy offerings from IPLocks, NGS, ISS, nTier, and a couple others.

I was asked the other day "Why are you writing about database assessment? Why now? Don't most people know what assessment is?" There are a lot of reasons for this. Unlike DAM or DLP, we're not defining and demystifying a market. Database security and compliance requirements have been at issue for many years now, but only recently have platforms have matured sufficiently to realize their promise. These are not funky little homegrown tools any longer, but maturing into enterprise-ready products. There are new vendors in the space, and (given some of the vendor calls we get) several more will join the mix. They are bringing considerable resources to table beyond what the startups of 5 years ago were capable of, integrating the assessment feature into a broader security portfolio of preventative and detective controls. Even the database vendors are starting to take notice and invest in their products. If you reviewed database assessment products more than two years ago and were dissatisfied, it's time for another look.

On to some of the management features that warrant closer review:

Reporting

As with nearly any security tool, you'll want flexible reporting options, but pay particular attention to compliance and auditing reports, to support compliance needs. What is suitable for the security staffer or administrator may be entirely unsuitable for a different internal audience, both in content and level of detail. Further, some products generate one or more reports from scan results while others tie scan results to a single report.

Reports should fall into at least three broad categories: compliance and non-technical reports, security reports (incidents), and general technical reports. Built-in report templates can save valuable time by not only grouping together the related policies, providing the level of granularity you want. Some vendors have worked with auditors from the major firms to help design reports for specific regulations, like SOX & PCI, and automatically generate reports during an audit.

If your organization needs flexibility in report creation, you may exceed the capability of the assessment product and need to export the data to a third party tool. Plan on taking some time to analyze built-in reports, report templates, and report customization capabilities.

Alerts

Some vendors offer single policy alerts for issues deemed critical. These issues can be highlighted and escalated independent of other reporting tools, providing flexibility in how to handle high priority issues. Assessment products are considered a preventative security measure, and unlike monitoring, alerting is not a typical use case. Policies are grouped by job function, and rather than provide single policy scanning or escalation internally, critical policy failures are addressed through trouble-ticketing systems, as part of normal maintenance. If your organization is moving to a "patch and shield" model, prioritized policy alerts are a long-term feature to consider.

Scheduling

You will want to schedule policies to run on a periodic basis, and all of the platforms provide schedulers to launch scans. Job control may be provided internally, or handled via external software or even as "cron jobs". Most customers we speak with run security scans on a weekly basis, but compliance scans vary widely. Frequency depends upon type and category of the policy. For example, change management / work order reconciliation is a weekly cycle for some companies, and a quarterly job at others. Vendors should be able to schedule scans to match your cycles.

Remediation & Integration

Once policy violation are identified, you need to get the information into the right hands so that corrective action can be taken. Since incident handlers may come from either a database or a security background, look for a tool that appeals to both audiences and supplies each with the information they need to understand incidents and investigate appropriately. This can be done through reports or workflow systems, such as Remedy from BMC. As we discussed in the policy section, each policy should have a thorough description, remediation instructions, and references to additional information. Addressing all of the audiences may be a policy and report customization effort for your team. Some vendors provide hooks for escalation procedures and delivery to different audiences. Others use relational databases to store scan results and can be directly integrated into third-party systems.

Result Set Management

All the assessment products store scan results, but differ on where and how. Some store the raw data retrieved from the database, some store the result of a comparison of raw data against the policy, and still others store the result within a report structure. Both for trend analysis, and pursuant to certain regulatory requirements, you might need to store scan results for a period of a year or more. Depending upon how these results are stored, the results and the reports may change with time! Examine how the product stores and retrieves prior scan results and reports as they may keep raw result data, or the reports, or both. Regenerated reports might be different if the policies they were mapped to change. Trend analysis is an important aspect to understanding how security is affected by normal administration and patch management. Consider how historic data is presented to ensure it is suitable your requirements.

Platform and Deployment

Assessment scanners are offered both as appliances and as software. Remote credentials assessments as SaaS are not available as of this writing. Your vendor should provide a web management interface over a secure connection. Proper account management is needed to enforce roles for policy creation, database credential management, and scan results, and many offer integration with external access control systems. The scanner will require maintenance like any other platform. If the vendor is using a relational database to store data within their application stack, this will impact security and operations (positively and negatively), and should be included as one of your regularly scanned databases.

As with any product, it's sometimes difficult to cut through the marketing materials and figure out if a product really meets your needs. This breakdown of the functional elements is intended to give you an idea of what is possible with state of the art products, and a basic checklist of functions to review for a proof of concept. While the cost of the assessment features is much less than monitoring or auditing solutions, don't skimp on the evaluation and make sure you test the products as thoroughly as possible. The results need to satisfy a large audience and be integrated with more systems than DAM or other auditing products.

–Adrian Lane

Database Assessment Solutions, Part 5: Operations and Compliance policies

By Adrian Lane, Rich

Technically speaking, the market segment we are talking about is "Database Vulnerability Assessment". You might have noticed that we titled this series "Database Assessment". No, it was not just because the titles of these posts are too long (they are). The primary motivation for this name was to stress that this is not just about vulnerabilities and security. While the genesis of this market is security, compliance with regulatory mandates and operations policies are what drives the buying decisions, as noted in part 2. (For easy reference, here are Part 1, Part 3, and Part 4). In many ways, compliance and operational consistency are harder problems to solve because they requires more work and tuning on your part, and that need for customization is our focus in this post.

In 4GL programming we talk about objects and instantiation. The concept of instantiation is to take a generic object and give it life; make it a real instance of the generic thing, with unique attributes and possibly behavior. You need to think about databases in the same way as, when started up, no two are alike. There may be two installations of DB2 that serve the same application, but they are run by different companies, store different data, are managed by different DBAs, have altered the base functions in various ways, run on different hardware, and have different configurations. This is why configuration tuning can be difficult: unlike vulnerability policies that detect specific buffer overflows or SQL injection attacks, operational policies are company specific and are derived from best practices.

We have already listed a number of the common vulnerability and security policies. The following is a list of policies that apply to IT operations on the database environment or system:

Operations Policies

Password requirements (lifespan, composition) Data files (number, location, permissions) Audit log files (presence, permissions, currency) Product version (version control, patches) Itemize (unneeded) functions Database consistency (i.e., DBCC-DB on SQL Server) checks Statistics (statspack, auto-statistics) Backup report (last, frequency, destination) Error log generation and access Segregation of admin role Simultaneous admin logins Ad hoc query usage Discovery (databases, data) Remediation instructions & approved patches Orphaned databases Stored procedures (list, last modified) Changes (files, patches, procedures, schema, supporting functions)

There are a lot more, but these should give you an idea of the basics a vendor should have in place, and allow you to contrast with the general security and vulnerability policies we listed in section 4.

Compliance Policies

Most regulatory requirements, from industry or government, are fulfilled by access control and system change policies we have already introduced. PCI adds a few extra requirements in the verification of security settings, access rights and patch levels, but compliance policies are generally a subset of security rules and operational policies. As the list varies by regulation, and the requirements change over time, we are not going to list them separately here. Since compliance is likely what is motivating your purchase of database assessment, you must to dig into vendor claims to verify they offer what you need. It gets tricky because some vendors tout compliance, for example "configuration compliance", which only means you will be compliant with their list of accepted settings. These policies may not be endorsed by anyone other than the vendor, and only have coincidental relevance to PCI or SOX. In their defense, most commercially available database assessment platforms are sufficiently evolved to offer packaged sets of relevant polices for regulatory compliance, industry best practices, and detection of security vulnerabilities across all database platforms. They offer sufficient breadth and depth for what you need to get up and running very quickly, but you will need to verify your needs are met, and if not, what the deviation is.

What most of the platforms do not do very well is allow for easy policy customization, multiple policy groupings, policy revisions, and creating copies of the "out of the box" policies provided by the vendor. You need all of these features for day-to-day management, so let's delve into each of these areas a little more. This leads into our next section on policy customization.

Policy Customization

Remember how I said in Part 3 that "you are going to be most interested in evaluating assessment tools on how well they cover the policies you need"? That is true, but probably not for the reasons that you thought. What I deliberately omitted is that the policies you are interested in prior to product evaluation will not be the same policy set you are interested in afterwards. This is especially true for regulatory policies, which grow in number and change over time. Most DBAs will tell you that the steps a database vendor advises to remediate a problem may break your applications, so you will need a customized set of steps appropriate to your environment. Further, most enterprises have evolved database usage polices far beyond "best practices", and greatly augment what the assessment vendor provides. This means both the set of policies, and the contents of the policies themselves, will need to change. And I am not just talking about criticality, but description, remediation, the underlying query, and the result set demanded to demonstrate adherence. As you learn more about what is possible, as you refine your internal requirements, or as auditor expectations evolve, you will experience continual drift in your policy set. Sure, you will have static vulnerability and security policies, but as the platform, process, and requirements change, your operations and compliance policy sets will be fluid. How easy it is to customize policies and manage policy sets is extremely important, as it directly affects the time and complexity required to manage the platform. Is it a minute to change a policy, or an hour? Can the auditor do it, or does it require a DBA? Don't learn this after you have made your investment. On a day-to-day basis, this will be the single biggest management challenge you face, on par with remediation costs.

Policy Groupings & Separation of Duties

For any given rule, you have several different potential audiences who may be interested in the results. IT, internal audit, external audit, security, or the DBAs may need the results from the rule in their reports. Conversely, each of these audiences might not be interested, or might be affected by and thus disallowed from seeing the results from certain rules. For example, your SQL Server database group does not need Oracle results, internal audit reports need not contain all security settings, your European database staff may not be interested in US database reports, and separation of duties may require some information be blocked from some users. Managing and grouping policies into logical sets is very important, as the reports derived from the policy set must be specific to certain audiences. You need the ability to group according to function, location, regulatory requirements, security clearance, and so on. The ability to import, update, save different versions, and schedule one or more policy sets is mandatory for modern database assessment tools.

If you take one thing away from this post it should be that you need to compare what policies are available from the vendor, what will you need to create, and how difficult that will be to accomplish. In the next post we will cover what you actually do with all the data you collect from the vulnerability, security, and operational policies. We will discuss reporting, scheduling, and integration with workflow and trouble ticket systems. We will also cover some of the more advanced topics having to do with platform management, scheduling, data storage, separation of assessment roles, and security of the assessment system itself.

–Adrian Lane, Rich

Understanding and Choosing a Database Assessment Solution, Part 3: Data Collection

By Adrian Lane, Rich

In the first part of this series we introduced database assessment as a fully differentiated form of assessment scan, and in part two we discussed some of the use cases and business benefits database assessment provides. In this post we will begin dissecting the technology, and take a close look at the deployment options available. What and how your requirements are addressed is more a function of the way the product is implemented than the policies it contains. Architecturally, there is little variation in database assessment platforms. Most are two-tiered systems, either appliances or pure software, with the data storage and analysis engine located away from the target database server. Many vendors offer remote credentialed scans, with some providing an optional agent to assist with data collection issues we will discuss later. Things get interesting around how the data is collected, and that is the focus of this post.

As a customer, the most important criteria for evaluating assessment tools are how well they cover the policies you need, and how easily they integrate within your organization's systems and processes. The single biggest technology factor to consider for both is how data is collected from the database system. Data collection methods dictate what information will be available to you -- and as a direct result, what policies you will be able to implement. Further, how the scanner interacts with the database plays a deciding role in how you will deploy and manage the product. Obtaining and installing credentials, mapping permissions, agent installation and maintenance, secure remote sessions, separation of duties, and creation of custom policies are all affected by the data collection architecture.

Database assessment begins with the collection of database configuration information, and each vendor offers a slightly different combination of data collection capabilities. In this context, I am using the word 'configuration' in a very broad sense to cover everything from resource allocation (disk, memory, links, tablespaces), operational allocation (user access rights, roles, schemas, stored procedures), database patch levels, network, and features/functions that have been installed into the database system. Pretty much anything you could want to know about a database.

There are three ways to collect configuration and vulnerability information from a database system:

• Credentialed Scanning: A credentialed database scan leverages a user account to gain access to the database system internals. Once logged into the system, the scanner collects configuration data by querying system tables and sending the results back to the scanner for analysis. The scan can be run over the network or through a local agent proxy -- each provides advantages and disadvantages which we will discuss later. In both cases the scanner connects to the database communication port with the user credentials provided in the same way as any other application. A credentialed database scan potentially has access to everything a database administrator would, and returns information that is not available outside database. This method of collection is critical as it determines such settings as password expiration, administrative roles, active and locked user accounts, internal and external stored procedures, batch jobs, and database/domain user account mismatches. It is recommended that a dedicated account with (mostly) read only permissions be issued for the vulnerability scanning team in case of a system/account compromise.

• External Scanning (File & OS Inspection): This method of data collection deduces database configuration by examining settings outside database. This type of scan may also require credentials, but not database user credentials. External assessment has two components: file system and operating system. Some but not all configuration information resides in files stored as part of the database installation. A file system assessment examines both contents and metadata of initialization and configuration files, to determine database setup -- such as permissions on data files, network settings, and control file locations. In addition, OS utilities are used to discover vulnerabilities and security settings not determinable by examining files within the database installation. The user account the database systems runs as, registry settings, and simultaneous administrator sessions are all examples of information accessible this way. While there is overlap between the data collected between credentialed and external scans, most of the information is distinct and relevant to different policies. Most traditional OS scanners which claim to offer database scanning provide this type of external assessment.

• Network (Port) Inspection. In a port inspection, the scanner performs a mock connection to a database communication port; during the network 'conversation' either the database returns its type and revision are explicitly, or the scanner deduces them from other characteristics of its response. Once the scanner understand the patch revision of the database, a simple cross reference for known vulnerabilities is generated. Older databases leak enough information that scanners can make educated guesses at configuration settings and installed features. This form of assessment is typically a "quick and dirty" that provides basic patch inspection with minimal overhead and without requiring agents or credentials. As network assessment lacks the user and feature assessments required by many security and audit groups, and as database vendors have blocked most of the information leakage from simple connectinos, this type of scan is falling out of favor.

There are other ways to collect information, including eavesdropping and penetration testing, but they are not reliable; additionally, penetration testing and exploitation can have catastrophic side-effects on production databases. In this series we will ignore other options.

The bulk of configuration and vulnerability data is obtained from the credentialed scans, so they should be the bare minimum of data collection techniques in any assessment you consider. To capture the complete picture of database setup and vulnerabilities, you need both a credentialed database scan and an inspection of the underlying platform the database is installed on. You can accomplish this by leveraging a different (possibly pre-existing) OS assessment scanning tool, or obtaining this information as part of your database assessment. In either case, this is where things get a little tricky, and require careful attention on your part to make sure you get the functions you need without introducing additional security problems.

Traditionally, database assessment products used external stored procedures or locally installed agents to collect both database internals and external configuration information. The problem is that each of these methods poses a serious security risk. External stored procedures are a classic technique for attackers to access or subvert a database system. They might start by getting into the underlying platform and then using external stored procedure calls to exercise database functions, or by gaining access to the database and then launching code on the underlying platform. Enabling functions like SQL Server's xp-cmdshell or Oracle's extproc is considered a critical security vulnerability, so they are no longer available to assessment products. Historically, agents have been used to address connectivity, network bandwidth, local policy analysis, secure communication, and various other concerns that are no longer relevant. Now their principal value is that they can launch both credentialed and external scans. That also means they provide a way for IT administrators to gain access to database credentials, and DBAs to access the underlying operating system. Multi-purpose agents with mixed credentials violate common security practices, both because they give attackers an avenue for breaching systems, and also because they violate separation of duties between administrative roles.

We understand not all products offer credentialed and external scanning capabilities, so when in doubt, choose a credentialed scan. It will cover a greater number of security and compliance issues. If you have the choice, choose a platform that does both securely, meaning a vendor that offers both will need to provide one of the following options:

• Use separate tools for internal and external data collection, and merge data on the back end inside the policy analysis or reporting tools. As many firms already have OS assessment in place, this is a cost effective yet slightly clumsy option.
• Deploy external database inspection scripts in 'push' mode, where the local software agent has the ability to execute file and OS scripts, but the results must be pushed out to the database assessment scanner. In this way the scanning tool can perform remote credentialed scans, but does not need to store both OS and database credentials.
• Audit your database assessment vendor's platform to verify it offloads one or both sets of credentials to a third party access control service, and that there is proper separation of duties within the UI so access to internal and external scanning functions are not co-mingled.

There are other options, but none that we are aware of available in a commercially available product. As we said before, data collection has a significant impact on the policies you implement and how you manage the installation. Of all the technology aspects we will cover, this is the most important one, and data collection should be a focus in your product evaluation. Please make sure you understand this section and ask questions if something we have discussed is not clear, as it's important for finding the right product.

One final note: we omitted credentialed database assessment scans as SaaS -- they are not readily available at this time, but are expected soon.

–Adrian Lane, Rich