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.
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:
- The asset owner, control system vendor and Digital Bond develop a hardened configuration for the server or workstation.
- Digital Bond creates a Nessus .audit file that will test if the system has this hardened configuration.
- 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.
Turning PI into a SCADA SEM
OSIsoft’s PI may be the most widely deployed application in the energy sector. Depending how you segment the market, PI is in somewhere between 60% and 85% of all medium to large energy control systems. So the team at Digital Bond investigated how we could leverage this installed base to increase security, and fortunately OSIsoft was highly interested in adding security capabilities to PI.
Our solution – – add the ability to detect security events to PI. This will make PI a SCADA Security Event Manager (SEM).
PI is a natural for this role. It already collects data from a very large list of sources. The challenges are:
- identifying the security log entries in this large amount of data
- correlating multiple security log entries to identify a true security event
This ties into past proof of concept work we have done in the area of a data dictionaries to identify security related log entries and meta events, but leveraging the PI system is a great way to add this SCADA intelligence without asset owners needing to purchase or deploy an additional system.
PI has developed an ACE framework that makes it straightforward to code up and implement any meta events, or templates, into PI.
The deliverables from this project will be both documentation of the data dictionary and meta events and, more importantly, the ACE modules that asset owners will be able to implement into their existing PI system. Two of our asset owner participants have PI and will be testing the results.
Of course not everyone uses PI and one of the goals of the project is to generalize all solutions. As part of Part 2, we will write a conversion toolkit that will ease migrating the data dictionary and meta security event language from PI’s ACE language to a different format. One of our three bulk electric system participants has an internally developed application that provides historian and other PI-like services. We will test the success of this conversion toolkit by converting some of the meta events to the participant’s proprietary historian.
Integrate PI SCADA SEM Events with Enterprise SEM
Many of the large electric and oil/gas asset owners either have purchased a Security Event Manager (SEM) or use a managed security service provider (MSSP) for monitoring security on the enterprise network. Now that we have identified meta security events occurring in the control system network in a PI SCADA SEM in Part 2, Part 3 of the project sends these events from PI to the Enterprise SEM.
Why do this? At least a couple of reasons. First, the attacker may be coming from or through the Enterprise network so correlating events from the control system network and Enterprise network will help identify and respond to an attack. Second, oftentimes the top security expertise inside or outside an organization is assigned to the SEM. Having this talent aware of the security events can only help.
We will be developing and testing with Tenable’s Security Center SEM, and one of the asset owner participants has deployed both the PI on a SCADA DMZ and Security Center on the enterprise so we will have a real world test of the resulting toolkit.
The SEM marketplace is a lot more fragmented than the vulnerability scanner or historian markets, so generalizing this solution is critical for widespread use. Fortunately, most SEM’s have, by design and necessity, the ability to easily integrate and add context to security events sent to them. If they couldn’t do this it would be very difficult to support a new firewall, IDS, router or even a new log message in an existing device.
We will work with another of our asset owner partners who has a different enterprise SEM and test the toolkit integration.