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.