A few friends have pointed out we need to come up with a project name or acronym for our DoE research contract project. Suggestions would be welcome. There are three parts to this project, and all are described in more detail in the Project Narrative.

Part 1 - Compliance Auditing with Nessus

The Nessus Vulnerability Scanner has two compliance auditing plugins, one for Windows and one for Unix. These plugins, which require a Nessus Direct Feed, are very unlikely to impact a control system because they simply remotely login to the operating system and grab system information rather than send unexpected packets to the device. As described on the Nessus site:

The types of configuration audits performed by Nessus 3 include Windows user policies, file permissions, registry permissions, service permissions and specific security policies such as Kerberos and event auditing policies. For UNIX systems, user policies, file permissions, running processes and file content checks can be audited. Combinations of each of these types of audits can be combined to perform tests against 1000s of files, registry settings, users and so on.

So what does this mean for a Windows or UNIX computer in a control system? A three step process:

1. The asset owner, control system vendor and Digital Bond develop a hardened configuration for the server or workstation.
2. Digital Bond creates a Nessus .audit file that will test if the system has this hardened configuration.
3. The asset owner can then periodically audit these systems using Nessus to determine if the hardened configuration has been altered. The Nessus audit will report non-compliant settings as “Holes”, compliant settings as “Notes” and inconclusive results as “Warnings”.

These .audit files are most beneficial for systems such as HMI’s that are likely to have many instances with a single configuration. Similarly an asset owner might have a standard hardened configuration for their Unix server used as a realtime server, historian and communication gateway. Or a vendor could have a recommended secure configuration that could be audited to.

We have three large bulk electric entities who were part of our project proposal. Each of these entities will select up to 5 systems, and Digital Bond will create .audit files for these systems. Since we committed to at least 20 .audit files, we have opportunities to create a file for other asset owners, or even vendors. So let me know asap if you are interested. We will likely select the systems that have the biggest footprint in the energy sector.

To generalize the solution for non-Nessus scanners and audit tools, Digital Bond will convert the .audit file to the OVAL/XCCDF format that could be imported into other scanners.

Finally, we will look at the classes of systems that have .audit files and develop a template for future use. For example, we will look at all the HMI types we have generated .audit files for and develop a consensus template. This template could be used as a starting point for a vendor or asset owner to create a .audit file for another HMI.