Whether it’s for real-time, historical, or some other purpose, there are databases of all shapes and sizes in control systems. Two questions regarding these databases:

1.) How do we verify that they are in a secure state?

2.) Can we learn or measure anything about the application security from the data inside them?

Tenable added database audit capability to Nessus earlier this year and I recently had the opportunity to further explore the new feature. The Database Compliance Checks plugin is in the same family as the the Windows and Unix compliance plugins. The difference is that instead of authenticating to the OS, it authenticates to the database. From there it can call built-in database functions and run SQL.

So to answer question 1, Tenable provides audit files based on the CIS Benchmarks for Oracle, SQL Server, and MySQL. I tested on Oracle and MySQL and found that – no surprise here – there are many settings that can be improved upon from the default install. The Oracle audit file checks around 50 different configuration items. They range from simple password policy to more database-centric security settings such as the default tablespace for user accounts and restricting critical table access to the DBA and SYS accounts. These benchmarks are a good starting point for checking database security.

For question 2, let’s look at a simple example of a control system application setting in a database that we can audit. Say we want to verify that an operator audit trail is enabled for our HMIs. We know there is a setting in the GUI that dictates audit logging and that the value is stored in a database. The setting allows for different levels of audit logging but we want to just verify that is it not disabled.

The first step will be to identify the table and test an SQL query to pull back the information we want to evaluate. We find the value in the t_hmi_cfg table and use this query:

select cfgvalue from T_HMI_CFG where cfgname like ‘audit-trail’;

The query brings back the value ‘1′. Through a series of changing the value in the GUI and running this query, we learn that the value is ‘0′ when audit logging is disabled. We can then write a Nessus database audit check to verify that the value is set to something other than ‘0′. Here is the audit check:

<custom_item>
type : SQL_POLICY
description : “Verify that the audit trail is enabled for operators.”
sql_request : “select cfgvalue from T_HMI_CFG where cfgname like ‘audit-trail’;”
sql_types : POLICY_VARCHAR
sql_expect : regex: “[^0]”
</custom_item>

This a simplistic example but hopefully illustrates the power of being able to audit values in a database. For systems with the right architecture, this opens up a whole new world of configuration auditing which gives the asset owner even more assurance and insight into the security of their SCADA or DCS applications. The Nessus report looks exactly like any other Bandolier/Policy Compliance report:

Since database auditing wasn’t available when we started the project, you will not find it in the current Bandolier audit files. I suspect this will change as we develop audit files for new applications and update the files for the existing set. Database auditing won’t apply to every application but for those where it is applicable, the security auditing capability will be greatly enhanced.