Our Dept. of Energy funded research project will result in a number of different tools for Digital Bond site subscribers. We have blogged on Bandolier, the development of control system security audit templates for Nessus and other vulnerability scanners. Now let me introduce you to the part of the project we are calling Portaledge.

Portaledge Overview

A major goal of the overall project is to detect cyber attacks on control systems. This can be done with some success by looking at individual data sources such as IDS alerts, failed login events or rejected packets in a firewall log. However it can be done much more effectively if we can take security events from a large and diverse set of resources and analyze the security events as a whole. In the IT world there is a product category for this called Security Event Managers (SEM) or Security Information Managers (SIM).

Most control systems do not have a SEM or SIM, but they have a similar type server that collects data from control system applications called a historian. The purpose of Portaledge is to add a control system SEM capability to a historian. The control system SEM will be able to correlate data from diverse sources to detect attacks while reducing false positives that plague single sources or missing low and slow attacks that may not trigger a single source detection.

Our development platform is the OSIsoft’s PI server for a variety of reasons, not the least of which is its dominant market share in electric and oil gas. We felt it was important to have an add-on security capability to a product already owned rather than requiring a purchase and deployment of an additional SEM. That said, we will be generalizing the results for use in other historians. Based on our early work, the team is likely to gush a bit about PI because it sets up perfectly for this project, but we will also tell you where it misses the mark.

Identifying the Data

The first step in Portaledge is to identify the security events in the sea of data from the myriad of potential data sources. This data can come from field devices, realtime and historian servers, OPC servers, decision support servers, HMI, protocol gateways, operating systems, databases, web servers, infrastructure such as switches and routers, security equipment such as firewalls and IDS, … There are a lot of data sources in a control system network.

What is a security event? Some of the data sources actually classify a set of events as security events. An easy examples is the Windows Event Viewer that has a security category. Certainly events labeled security are of interest, but we are interested in a lot more. Some events could have security implications, but not be security events. For example when an attacker does a DNP3 function code scan an error is going to occur indicating function code not supported. This is not a “security event”, but we definitely want to see that in Portaledge.

Our first approach to identifying events is multi-pronged:

• We analyze the documentation of the events logged in the device or application and try to identify all events that could be triggered by an attack.
• We have our offensive team launch a variety of attacks on the lab network and see what events those attacks trigger. Some of the attacks are a single tool, but more importantly are likely attack progressions from reconnaissance to exploit. The offensive team is working with classic IT attacks and control system specific attacks.
• We are analyzing Vulnerability Databases to determine what events would generated for the different types of attacks related to these vulnerabilities.

Next: Getting Diverse Security Events Into PI