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
Part I covered identifying security events in a very diverse set of data sources. The next step is to get those security events into OSIsoft’s PI or other historian so we can aggregate and correlate to detect attacks. Fortunately this is an area where PI really shines through a wide variety of interfaces.
The most popular PI interface is the OPC interface. Think of this as the universal translator. If a control system device can send data to an OPC server or a gateway device that converts an obscure protocol to an OPC server, then PI’s OPC interface can get the security events into PI.
However this universal translator is often not necessary since there are hundreds of PI interface nodes. There are interfaces for SCADA and DCS systems – – Bailey, Emerson, Foxboro, GE, Honeywall, … There are interfaces for field devices, Modicon, Allen Bradley, Siemens, … There are interfaces for protocols Modbus, DNP3, ICCP, … There are a lot of classic control system interfaces to get data from almost any control system device to the PI server. The only thing we haven’t found that we wanted so far is an easy way to get IEC 61850 events into PI, but even that seems to be possibly by mapping them to DNP3 and using that interface.
There are also a set of more ‘IT’ interfaces that we can use to get firewall, router, server or other IT component security events into PI. There are SNMP, Syslog, Netflow [and another interface that creates Netflow-like data from a span port], a variety of database interfaces, PERFMON, …
So the good news for Portaledge is that if we can identify the security events anywhere in the control system, we should be able to get them into PI via an interface node.
Next: Tags and Tag Creation Templates
This is a challenge. In Part I we identified the security events we wanted to look at. In Part II we talked about the PI interfaces that can pass events from a wide variety of data sources to PI. In Part III we delve into the challenge of creating tags in PI for the various security events.
Now this might seem straightforward. Asset owners are creating new tags in PI all the time. The challenge is the consistent naming of these tags so they can be used in the ACE security event correlation modules we will be developing to detect what we are calling security ‘meta events’. If each implementation uses different tag names, then they will need to modify the ACE modules. This would likely affect adoption. Who has the time to do this, and what about the inevitable errors?
We could have rigid names saying a security log event from this data source or a point from a field device is given a specific tag name, but that has a number of problems. An asset owner likely has multiple data sources of the same type and each will need its individual tag name. Also, asset owners are going to want to customize the tag name so it has context and is recognizable.
Our current plan is a middle road solution requiring a string in the tag name, but not a specific tag name. This will allow us to use another feature in PI called the Module Database to automatically convert a specific implementations tag names and related information to what is specified in the ACE detection module. For example, the module database normalization process can look for all tags with the string “firewall” as part of the tag name. It then can take these identified tags and store the data in the tag in tag names used in the ACE module.
This is our first approach. We know it will work from a technical standpoint. The question is, is this the simplest effective way of doing this for the asset owners? Is there some other technique that will be less restrictive – – less than requiring a string – – on the asset owner? We will have a sample up in the next couple of months for your consideration