This post is going to introduce SENAMI, a new, hybrid approach to Intrusion Detection for Industrial Control Systems. The post aims to provide a condensed overview of the full paper – SENAMI: Selective Non-Invasive Active Monitoring for ICS Intrusion Detection. This will be presented at CPS-SPC, part of the CCS conference, in Vienna at the end of October.
Below there is a brief overview of ICS as a whole, current IDS technology in the area, some technical details about what SENAMI does, and some general Siemens ICS observations and tools which may be of use to a consultant working within the ICS area.
This blog is based on work previously conducted by the author whilst at Lancaster University. The full paper is available for download at: http://eprints.lancs.ac.uk/81642/1/senami.pdf
Industrial Control Systems (ICS) are highly specialised embedded devices used to control processes like water treatment and distribution, power management, steel production, etc. Therefore it is considered part of the critical national infrastructure.
At the heart of an ICS network is a Programmable Logic Controller (PLC). These are embedded devices which control the logic of a system. They are highly specialised to the job they perform and aim to provide high levels of reliability and control. Their basic functionality is driven by their logic code; the PLC will then read inputs from sensors and write outputs to actuators (e.g. valves, pumps, motors) depending on how the logic code maps to these input values.
For ease of use, these PLC variables are converted from their raw, analogue value, representing a sensor voltage or count (e.g. in the range 0-20mA) and converted into a digital value (e.g. 95 in a range of 0-100); these digital values are stored internally in various PLC memory locations and data blocks. These values have meaning within the wider ICS, including water level, on/off state of a pump (likely a binary 1/0), etc.
Siemens S7 devices are widely known/remembered as being the PLCs used in the Iranian nuclear facility targeted by the Stuxnet worm. They’re also still used widely, though, particularly in the water industry across the UK and Europe. A Shodan search for Siemens S7 devices (https://www.shodan.io/explore/category/industrial-control-systems) finds 23 Internet-connected S7 PLCs alone in the UK, with over 700 in mainland Europe. As PLC devices are not generally directly connected to the internet it is likely there are far higher numbers deployed than just those found in Shodan.
PLCs, as compared to standard desktop computers, are intended to be long-lifespan devices. They’ve often been deployed for years and run protocols designed in the 70s, which predate concerns about authentication, confidentiality and robustness. But it just isn’t possible to turn them off for a few days to install Windows 10 or replace the devices with newer, more secure versions, because that means a loss of availability in the system, which can potentially cost millions and millions of pounds. So PLCs are often affected by security issues which have long-since been resolved in the desktop domain. These updates are non-trivial for the PLC domain, however.
SENAMI was specifically developed using Lancaster University’s Industrial Control System testbed. This is a diverse system, but it is was the water treatment and distribution capability and their controller S7 PLCs which were used.
A large amount of existing work in Intrusion Detection Systems for ICS involve just repurposing existing open source solutions. This includes ICS/SCADA plugins for systems like Snort and Bro. While this is cheap, it’s also not massively effective. If you use a general-purpose solution, you can’t really expect to get specialised results. Really, the detection needs to be tailored to the specific type of ICS (e.g. Siemens, Allen-Bradley, Modbus/Schneider Electric, etc.) and to the specifics of the process it’s monitoring.
A problem with an IDS like Snort is also that they’re signature-based, as opposed to anomaly-based. Attackers of critical national infrastructure are likely to be advanced attackers – often APTs or nation state actors, as in Stuxnet – who are going to be executing complicated, stealthy, bespoke attacks. The chances of these matching a signature are quite slim.
Then there are more bespoke Network Intrusion Detection Systems (NIDS), also known as “passive” IDS. Passive, that is, in relation to their interaction with PLCs on the network. These passive IDS rely solely on network traffic, and the amount of data you can glean from that, to provide detection. There are several IDS and research papers which do really interesting stuff with this – the ones I found most interesting were:
While all of these custom passive solutions introduce greater detection as opposed to traditional passive IDS, they all suffer from the same underlying problem: they’re solely passive. Meaning, as powerful as their detection might be, it is detection based purely on observed network traffic – so that detection is only as reliable as the network traffic itself.
There are several scenarios through which an attacker could evade detection by a NIDS. For instance, an attacker who knows details of the process they’re attacking and the times in which it’s doing things – this could be an insider threat, or even just an attacker who’s had persistence in the system for a couple of weeks and listened to a lot of network traffic. For example, huge amounts of traffic may be sent to and from a PLC controlling a water tank at 7pm every evening, when people are running their baths. However, if we saw that same spike at 3am, something would seem suspicious. An attacker that could observe these peaks and troughs could hide their attack in high quantities of legitimate traffic.
Likewise, if detection is being done based on the IP addresses requests are coming from, a conspicuous attacker would be trivially detected. However, if they’d manage to pivot through the general system and compromise a device – whether it be an engineer laptop or an embedded ICS device – that IP would be whitelisted.
And even more complex passive detection, like that of Security Matters’s SilentDefense, is still beholden to network traffic. What if, for instance, an attacker was executing a Man-in-the-Middle between the PLC and the network? They could effectively mask traffic that an IDS plugged into a mirrored network port would see. Or what if they had managed to overwrite the PLC logic code to always set the value used for monitoring to a set level to disrupt monitoring? Most NIDS aren’t really equipped to detect this sort of attack.
This is where active comes in. This involves directly polling the PLC for values. On the most basic level, this could be used in a manner similar to “Through the Eye of the PLC”’s work, wherein it plots the levels and variance of every one of a PLC’s variables and flags alerts based on this.
This is basically the work of “Safety and Security Monitoring in ICS/SCADA Systems” (http://ewic.bcs.org/upload/pdf/ewic_icscsr14_paper8.pdf) from ICS-CSR 2014. This helps detect more complex attacks, such as a device-level MitM, which aims to disrupt monitoring of what’s actually going on.
However, as we’ve established, PLCs are old, legacy devices. They also already execute huge quantities of commands and have a lot of devices connected to them. So, PLCs are not really equipped to be processing requests for hundreds more variables every second. The authors of that work actually had to change the cycle times of the PLCs manually to stop this from inadvertently DoSing the PLC. This isn’t really feasible to do in the real world.
In short: active monitoring means a greater area to provide detection on, if combined with passive IDS. However, it also has the potential to adversely impact PLC performance: a situation SENAMI techniques are intended to gracefully remedy and tune to a given context.
SENAMI is short for Selective Non-Invasive Active Monitoring (something of a mouthful – hence SENAMI). This performs active monitoring, but on a smaller, more context-based scale.
Rather than reading in hundreds of values every cycle, SENAMI reads in only 3. These 3 values represent a vastly reduced subset of all PLC values, pre-determined to be critical to the operation of S7 ICS. These values are read in every 5 seconds, not every single cycle. This is frequent enough to provide a 93% detection rate of these active threats, but infrequent enough to avoid maxing out the PLC. If anything, there is actually room to increase the frequency of the checks, but it’s always better to err on the side of caution with PLCs.
Specifically, SENAMI monitors 3 values that are integral to the way a Siemens S7 PLC’s memory is generally configured. This specific configuration can allow for an attacker to disrupt the monitoring – i.e. overflow a water tank, while showing to a user remotely monitoring the level that everything is normal. This sort of attack was what was used in Stuxnet (except with nuclear centrifuges instead of water management). It’s important to note, however, that the choice of these 3 variables is highly context-dependent and only applicable if a given S7 PLC has its memory configured in this standard way:
The above diagram shows the internal memory configuration of a Siemens S7 PLC. The analogue value is read in on the left (and stored in PIW) and has a digital range applied to it (say 0-100) to produce the value in MD104. MD104 is what should happen. This value is then copied into 2 different data blocks: DB1 and DB2, and this is where things become insecure. DB1 is used to affect the physical process – so this is what is happening – while DB2 is used for monitoring – so this is what we’re told is happening.
These 2 values are established for a separation of duties; if we have hundreds of devices reading the current value, only one needs to be misconfigured and write to the value to accidentally damage the process and break something. However, if these devices are reading from a separate but equal value, and accidentally write to that, all that happens is a temporary monitoring disruption. So DB1 is intended to be a more protected value, which is the absolute value of what’s actually happening (although obviously it’s not actually anymore protected than DB2).
So, it’s a sound idea. However it introduces – by its very conception – the possibility of a discrepancy between values. So if an attacker could, for instance, write to DB1 telling it to fill the water tank, and write to DB2 saying the level is in the middle of the tank, an operator would see things as normal even while the tank was overflowing. This is shown in the RTU (Remote Terminal Unit) screenshot below:
What makes this even more dangerous is that it is possible to directly write to these data blocks and for the PLC to actually affect those changes. So, while in Allen-Bradley PLC systems, for example, an attacker would need to rewrite logic code to perpetrate this attack as well, with S7 an attacker can use a simple Python script with no changes to the logic code.
These Python scripts can be trivially small and invoke legitimate Write packets (a specific packet type within the proprietary S7 protocol), specifying a certain PLC variable (e.g. DB1) and a certain value. These messages will then be acted on by the PLC; this forcing of values means any attacker with access to the ICS network or direct access to the PLC can perform the “value tampering” attack to disrupt monitoring described above.
And if an attacker has a compromised IP and is masking traffic in expected-busy periods (as discussed earlier in this article) they could easily evade detection by a passive IDS. SENAMI, however, monitors the values of MD104, DB1 and DB2 for certain discrepancies, and detects these value tampering attacks with 93% effectiveness (with a combined passive and active detection rate of 81-93%). This includes a few False Positives, but crucially very few False Negatives – i.e. it very rarely misses it.
SENAMI also includes passive detection. It’s worth noting that an active IDS detects very targeted attacks, but that on its own is not enough – so SENAMI’s active component is combined with a passive IDS, which detects most types of common attack that could be run against the ICS.
The general state-of-the-art in Intrusion Detection Systems for Industrial Control Systems have been outlined in this article (and in more depth in the full SENAMI paper). Specifically, we’ve identified that while passive IDS have their strengths – including a broad range of attacks detected – they are limited by their dependence on network traffic.
An alternative to this was identified, in the form of active monitoring. However, this has been historically recorded to introduce performance and availability concerns, due to the legacy nature of PLC devices.
SENAMI therefore introduces a hybrid approach to ICS Intrusion Detection, combining a large passive IDS with elements of “Selective Non-Invasive Active Monitoring” of a small number of highly contextualised values. In a testbed environment, this has been demonstrated to have high effectiveness and present no adverse effects on the performance of Control Systems.
SENAMI does have its limitations; it is by no means impossible to bypass, falling prey to some of the same Man-in-the-Middle scenarios as traditional IDS, if an attacker can position themselves between the PLC and the IDS. However, in the absence of additional PLC security features for authentication, this is always to some extent a threat. SENAMI, though, makes it harder for an attacker to target Siemens S7 ICS and helps eliminate the trivial “value tampering” attacks currently possible over a network. A benefit of SENAMI is also that it requires no changes to the existing features, logic or firmware of the PLC.
It is important to note, however, that SENAMI is a proof-of-concept tool and it should not be deployed on live production environments. It is also only applicable to Siemens S7 PLCs (specifically tested on ET200s and 300-series PLCs) which run the standard, legacy 0x32 version of the S7 protocol.
Furthermore, SENAMI’s choice of values to actively monitor is specific to this environment and the standard memory configuration described here – these variable offsets and the thresholds used in the IDS may need refining for other testbed systems. This really serves to highlight the key point though: ICS security should be as bespoke and specialised as possible!
Now, the interesting stuff. If you have an interest in ICS or per-chance are doing any ICS consultancy work, here’s some observations and useful tools from my experience doing this work which may be of use: