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:
- A Nessus scanner subscribed to the ProfessionalFeed
- An audit file, specifically written to make use of the SQL checks
- Network connectivity to your database (it can’t be blocked by a firewall)
- An account to log into the database with
With this information, you can follow the steps below to perform an audit:
- In NessusClient, create a new scan policy and edit it.
- Under the “Plugin Selection” tab, make sure to enable the “Database Compliance Checks” plugin.
- 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.
- 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.
