Auditing MS SQL Servers for DISA STIG Compliance with Nessus

Recently, Tenable added the ability for Nessus ProfessionalFeed users to establish a session with database servers and audit their configurations. Our first major audit policy that utilizes this technology performs a database audit against settings specified in the DISA STIG guide for Microsoft SQL servers. This blog entry discusses the new SQL auditing functionality and how to perform the DISA STIG audit with Nessus.

Why Audit SQL Database Configurations?

SQL databases are widely used to drive web applications, track credit card information, host Personal Identification Information (PII) and store many other types of sensitive data. Previously, Nessus enabled vulnerability, patch and configuration auditing of the operating system that the SQL database was deployed on, but not the actual configuration of the database itself.

With the new SQL auditing functions, Nessus can look “inside” a database to see what sort of internal configuration settings have been put in place. This can help ensure that your database is operating with least privileges and has disabled functionality that is not needed and could be exploited by a hacker.

When analyzing the security of a database server, being able to combine the vulnerability and patch information along with the operating system and database configurations makes it easy to understand where any potential exploit or abuse could come from.

Supported Databases and Audits

The new technology supports SQL audits of these database types:

• DB2
• Informix
• Oracle
• Microsoft SQL
• MySQL
• PostgreSQL

Additionally, Tenable has produced two audit policies to be used against Microsoft SQL servers.
The first implements many of the requirements specified by the Center for Internet Security’s benchmark guide for SQL Server 2005. This guide actually recommends specific Windows 2003 operating system settings as well as SQL Server audits. Tenable has produced two audit policies for Nessus – one to audit the Windows 2003 server settings and another to connect via SQL and audit the actual database settings. The SQL audit policy tests more than 40 different SQL settings. For example, here is a fragment of the CIS audit policy which tests for CIS section 3.12.19 which recommends that the stored procedure “xp_subdirs” should be disabled:

<custom_item>
type        : SQL_POLICY
description : "3.12.19 Check if the stored procedure
               xp_subdirs is disabled"
info        : "Checking that extended stored procedure:
               'xp_subdirs' either does not exist or is
               disabled."
sql_request : "select name, value_in_use from
               sys.configurations where name =
               'xp_subdirs' and value_in_use = 1"
sql_types   : POLICY_VARCHAR
sql_expect  : NULL
</custom_item>

The second audit policy comes from the Defense Information Systems Agency (DISA). DISA maintains a set of hardening and configuration guides known as checklists for a wide variety of technologies. We were very impressed with the depth of recommended SQL settings and content concerning specific regulations. There are more than 100 specific SQL items recommended and required by this guide. Below is an example audit that tests to ensure that a certain account is disabled when not needed:

<custom_item>
type           : SQL_POLICY
description    : "3.154    DM0630: Application object owner
                  account disabling"
info           : "Object ownership provides all database object
                  permissions to the owned object. Access to the
                  application object owner accounts requires
                  special protection to prevent unauthorized access and
                  use of the object ownership privileges. In addition to
                  the high privileges to application objects assigned
                  to this account, it is also an account that, by
                  definition, is not accessed interactively except for
                  application installation and maintenance.  This reduced
                  access to the account means that unauthorized access to
                  the account could go undetected.  To help protect the
                  account, it should be disabled only when access is
                  required."
info           : "ref. DB SRRChklst SQLServer2005 V8r1-1.doc, 3-175."
info           : "Database STIG 3.3.11.3"
info           : "STIG Requirement:(DG0004: CAT II) The DBA will ensure
                  custom application owner accounts are disabled or locked
                  when not in use."
info           : "Checking whether any custom application owner accounts
                  are enabled for master database."
sql_request    : "use master;select suser_sname(p.sid) from
                  sys.database_principals p, sys.server_principals s where
                  p.principal_id in (select distinct schema_id from
                  sys.objects where is_ms_shipped=0) and p.sid = s.sid and
                  s.is_disabled=0 and p.type not in ('A','R')"
sql_types      : POLICY_VARCHAR
sql_expect     : NULL
</custom_item>

Performing a Database Audit

In order to make use of the SQL audits with Nessus, you need the following items:

1. A Nessus scanner subscribed to the ProfessionalFeed
2. An audit file, specifically written to make use of the SQL checks
3. Network connectivity to your database (it can’t be blocked by a firewall)
4. An account to log into the database with

With this information, you can follow the steps below to perform an audit:

1. In NessusClient, create a new scan policy and edit it.
2. Under the “Plugin Selection” tab, make sure to enable the “Database Compliance Checks” plugin.
3. Under the “Advanced” tab, select the “Database Compliance Checks” form and then use one or more “Select…” buttons to specify a SQL .audit file from your local system.
4. Lastly, also under the “Advanced” tab, select the “Database settings” form and specify your database technology and credentials.

The DISA and CIS audit guides also recommended many specific Windows 2003 server settings. Tenable has also written audit polices to reflect those settings as well. When you are configuring your scan, be sure to add the Windows compliance audit polices under the "Windows Compliance Checks" tab and the database policy under the "Database Compliance Checks" tab. Both audit policies can be applied against a server at the same time.

Below are some screen shots of these new features shown within NessusClient, as well as some example results:

 
Selecting the Database Compliance Checks Plugin

 
Example Scan Results for a DISA MS SQL Audit

More extensive documentation of how to perform this type of scan discussed in the Nessus documentation. ProfessionalFeed subscribers can also learn more about writing your own SQL audits in the “Nessus Compliance Checks” document found on the Tenable Support Portal.