Security Experts:

SCADA Mischief Episode 2: Context and Correlation

Defending Against Insider Threats in SCADA Environments Using Context and Correlation

[Read Previous Column: "SCADA Mischief Episode 1: A Picture is Worth a Thousand Worms" Before Reading This Column]

But what about the “smart Bob” scenario? Bob tailgates into the control room, intent on causing harm. He want’s to cause some mischief and get away with it, so he’s been paying attention to his boss whenever he logs into the SCADA console.

SCADA Internal ThreatsHis boss is from Boston, and is a rabid Red Sox fan. It’s clear from his ‘casual peripheral vision’ spying that his boss is typing his password almost exclusively with his left hand except for the one “o” that he types with his right hand. Bob thinks his password must be ‘redsox’ (never mind the side argument for strong password usage). One day, when Bob’s boss in the bathroom, he tries logging in using ‘redsox’, ‘RedSox’, ‘Redsox’, and ‘r3dsox’ before finally succeeding with ‘r3ds0x’. He logs back out so his boss will return to his properly locked workstation, and prepares for Phase 2. Logging in as someone else gives him an alibi and also additional privileges, but Bob wants to do more than make subtle changes that could easily be detected and fixed.

He’s heard about Stuxnet, he’s studied up for his certs, has attended Defcon and watches ’24’ religiously—Bob is going to plant some malware that will mess up the process good by adjusting the timing, volume and temperature of certain catalyst injections so that the entire volume of that plastics tank turns solid like granite. It’s custom malware, so the Anti Virus system won’t detect it.

His plan, so he believes, is bullet proof. So, the following day he sits at his console and logs in as his boss. He’s decided to try the personal Mi-Fi trick to download a file from an anonymous file sharing website, because there are no unprotected USB ports on his console. He enables Wi-Fi on his PC, connects and downloads.

Instead of relying on multiple zero-day exploits to deliver his PLC plundering payload, as Stuxnet did, he’s skipped right past every cyber defense and hand-delivered that payload in his boss’ name. So why was he nabbed by security again, just moments later? Monitoring and anomaly detection again played an important role. The first alert hit a security analyst’s desk the previous day when a fairly benign ‘potential brute force’ event triggered due to the password guessing attempts. The second came when Bob’s boss logged in from a different IP address than he normally logs in from. The third came from change monitoring.

Let’s assume for a moment that Fictional Plastics Company Incorporated refused to spring for a commercial change management package. The IT department therefore turned to a slightly more cumbersome technique and setup Windows to monitor the registry and key directories for changes. The SIEM takes center stage again at this point by pulling WMI event data and analyzing it. The clues obtained from WMI include the activation of a new network interface, and also changes to key files related to the SCADA system that were made by Bob’s home-grown malware.

The SIEM, if properly configured, will also detect a new IP address within the control system (the Mi-Fi device), as well as web traffic on a control system asset (because HTML is not authorized). The SIEM has a broad-case correlation rule enabled which caught this clever exploitation red-handed. It looks like this:

POSSIBLE CYBER INCIDENT: (ONE OR MORE ACCESS ANOMALY followed by (SUSPICIOUS ACTIVITY or MALWARE ACTIVITY or PROCESS ANOMALY))

This covers a lot of use cases, so lets break it down into its component parts, which in this case include another two correlation rules called ‘ACCESS ANOMALY’ and ‘PROCESS ANOMALY’ as well as some normalized threat categories, ‘SUSPICIOUS ACTIVITY’ and ‘MALWARE ACTIVITY’. The normalized conditions are simple: any good correlation engine uses a normalization taxonomy so that large groups of events can be used for more specific detection purposes—in this case it’s anything categorized as ‘suspicious’ (which would probably include port scans and similar events) and ‘malware’ (which might include events from an AV system). The other two correlation rules look like this:

ACCESS ANOMALY: (AUTHENTICATION EVENT or AUTHENTICATION ANOMALY or NETWORK ANOMALY)

PROCESS ANOMALY: (DEVIATION OF BASELINE of ANY EVENT from a SCADA SYSTEM)

Starting with ACCESS ANOMALY, we see another normalization category ‘AUTHENTICATION EVENT’’ as well as two additional correlation rules, ‘ACCESS ANOMALY’ and ‘NETWORK ANOMALY’, which looks like this:

ACCESS ANOMALY: (DEVIATION OF BASELINE of (SOURCE or USER or APPLICATION) for ANY AUTHENTICATION EVENT)

NETWORK ANOMALY: ((ANY EVENT where DESTINATION is a SCADA SYSTEM and SOURCE is not in the SCADA SUBNET) or (DEVIATION OF BASELINE of TOTAL # OF SOURCE IP ADDRESSES within the SCADA SUBNET))

Hacker FootprintsThe ACCESS ANOMALY rule detects changes in authentication behavior, while the NETWORK ANOMALY rule detects changes in network behavior—specifically looking for any network communication inbound to a SCADA System that is not sourced from within the SCADA network, or any change in the number of active IP addresses communicating within the SCADA subnet. These rules also introduces the condition of a statistical deviation, which is also used in the ‘PROCESS ANOMALY’ rule, which simply states that an alert should be generated if there’s any change in any metric monitored from a SCADA system (such as a set point). The deviation is a SIEM-derived calculation of observed activity against expected behavior, which as stated previously requires an understanding of what ‘executed behavior’ means. Not all SIEMs are up to this challenge, so a third-party anomaly detection system may be required. However the anomaly is observed, however, this function is critical to the detection of threats in control systems. Perhaps more importantly is ensuring that the right activities are being monitored so that the correlation rules can function properly. In this example that requires: monitoring activity from the SCADA system, either directly from the SCADA servers or possibly from a compatible Historian; monitoring network flow activity to and from the SCADA network; and monitoring all devices within the SCADA network for local events (including changes, authentications, etc.).

Back to our fictional act of sabotage, several things have happened. First there was a ‘BRUTE FORCE’ alert, which also triggered an ‘ACCESS ANOMALY’ because it is an authentication event. The next day there were several alerts: a ‘NETWORK ANOMALY’ triggered by the Mi-Fi’s rogue IP address; an ‘AUTHENTICATION ANOMALY’ alert which also triggers another ‘ACCESS ANOMALY’, a ‘PROCESS ANOMALY’ alert triggered by the process changes made by the malware. Each of these alerts were significant enough to earn the attention of the security opps team, but the combination of the latter events triggered the ‘POSSIBLE CYBER INCIDENT’ alert, which immediately raised the stakes and set the security operations team into ‘rapid-response’ mode.

A skilled security team might have been able to act on some of the smaller correlation events, but even if they waited until the ‘POSSIBLE CYBER INCIDENT’ alert triggered the total time between the malicious activities and the alert is almost immediate. In this case, the security team only has to run a single quick query against the SIEM to show them everything else associated with Bob’s source IP address, and they’d see the file changes, the Wi-Fi port activity, the authentication—everything. Even if Bob had hit ‘enter’ and run like hell he would never have outrun the results of that single query. In other words, Bob never knew what hit him. Strong Cyber Security Practices: 1. Disgruntled employee: 0.

Related Reading:  Are Industrial Control Systems Secure?

Related Reading: How to Make the Smart Grid Smarter than Cyber Attackers

Related Reading:  The Increasing Importance of Securing The Smart Grid

Related Reading: Stuck on Stuxnet - Are Grid Providers Prepared for Future Assaults?

view counter
Eric D. Knapp (@ericdknapp) is a recognized expert in industrial control systems cyber security, and continues to drive the adoption of new security technology in order to promote safer and more reliable automation infrastructures. Eric is currently the Director of Cyber Security Solutions and Technology for Honeywell, and is the Chief Technical Advisor, North America for the Industrial Cybersecurity Center. He is also the author of “Industrial Network Security: Securing Critical Infrastructure Networks for Smart Grid, SCADA and Other Industrial Control Systems.” His new book, “Applied Cyber Security for Smart Grids” was co-authored with Raj Samani, McAfee CTO EMEA. The opinions expressed here represent Eric's own and are not those of his employer.