Detect Scanning On Control Systems: Another Portaledge Release
The Portaledge team is pleased to announce the beta release of the Enumeration Event Class. Portaledge is Digital Bond’s Dept. of Energy program that leverages OSISoft’s PI ACE engine to provide Security Event Management, detecting, alerting and logging of security events on SCADA and DCS.
The Enumeration Event class currently has modules for detecting common port scans and other enumeration scans; TCP, FIN, SYN, UDP, ICMP and for detecting account enumeration via Finger. These scans are often the first part of an attack scenario, and therefore by detecting and alerting on these attacks an asset owner is better able to stop the attack before it is successful or at least limit the impact of the attack.
Most of these events will identify scanning two ways. The first is a single system being scanned on multiple ports, the default is 3, and these alerts are labelled by Portaledge as a “scan” such as TCP scan, FIN scan, SYN scan, … The second way is multiple systems being scanned on the same port. For example, a scanner looking for web servers or ICCP servers. If three systems, the default but this can be changed, being monitored are scanned on the same port a “port sweep” alert is issued.
In addition to detecting common enumeration scans, the Enumeration Event Class provides a Traffic Monitor that monitors for anomalous communications. The Traffic Monitor allows the user to profile normal communications on the system and add the “allowed” communications on a per system basis. Portaledge will then monitor and alert on communications outside of those allowed. As communications patterns on control systems under normal conditions are very repetitive, the detection of abnormal communications is a strong indicator of enumeration and other malicious activities.
The Enumeration Release include the Enumeration Event Class event (see last weeks discussion of Event Class Events and Event Chains) that correlates events on four types of commonalities, and links events into chains to provide a better understanding of what is occurring on the system.
The Enumeration and previously released Availability events are available for download to Digital Bond content subscribers. Any feedback on Portaledge is appreciated.
Other Links:
Author: Kevin Lackey
Posted: June 30th, 2009 under Portaledge.
Comments: 3
Comments
Comment from Ralph Langner
Time: July 1, 2009, 6:06 am
Philosophical question:
Is a network scan a security event?
(If the answer is yes, under which conditions?)
Comment from Dale Peterson
Time: July 1, 2009, 8:20 am
Ahhh, Ralph, excellent question because it goes to the core of what Portaledge is designed to do.
A scan could be the initial phase of an attack. Or a scan could be a normal operation of a device on the network checking status. Or a periodic test for NERC CIP. Or many other things. And this is true of many “security events” that will be in each event class. For example is running low on system resources a security event? More often than not probably not, but it could be an artifact of an attack as your S4 2007 paper with OPC servers clearly indicated.
So our approach in Portaledge is to look for multiple possible “security events” and correlate them together over a commonality. For a simple example, scan and exploit from a single source IP followed by an availability issue or new admin user on the destination IP.
Portaledge will know a scan takes place. And the asset owner will then look at the length and diversity of the event chains to determine if there is action required.
A key area we are working on now is visualization of this data and ways to provide crude statistical thresholds to determine what to display.
Comment from Michael Toecker
Time: July 2, 2009, 5:02 pm
Dale,
This sounds a lot like analyzing alarm correlations, which is being done at generation plants (and others) to try to glean some intelligence from the massive flood of alarms operators tend to get.
Alarm correlations uses statistics to create associations between alarms. So, when a pump trips offline, the engine knows that it is likely that you are going to have a low pressure alarm soon after, and likely to have a high boiler temperature alarm after that. But because it’s a statistical engine, there’s often no logical relationship between the alarms, which lends itself to finding vulnerabilities in the process as well.
Of course, process alarms come in all the time and are a huge source for data mining. Since security alarms for process control are rare (both due to actual lack of occurrence and lack of monitoring), I’m not sure there would be enough data to build proper associations.
Is DigitalBond pursuing a statistical model like I referenced above, or a model that requires upfront analysis of the links between security events? Could the SCADA Honeynet would provide some of this data?
Mike
Write a comment