When we think of critical national infrastructure (CNI), we tend to think of industries such as power, water and transport, and although CNI also includes communications and finance, it is the heavier, safety-critical industries that we think of first.
Typically, these involve large industrial control systems (ICSs) that operate 24/7, 365 days a year, which we all depend on in our daily lives.
Successful attacks on these systems could cause serious injury or death, as illustrated by the recent attack on a water purification plant in Florida. The threats to these systems may come from actors with similar motivations as for IT systems, but the risks and how to address them can be very different.
The first thing to understand is that while IT systems are all much the same, using similar components and architectures, ICS solutions are all very different from each other. Industrial systems are not physically secured in a nice, air-conditioned room, but are often spread out over several square kilometres, or even many kilometres along a pipeline, making them extremely vulnerable to tampering.
Also, they very often cannot be shut down quickly for maintenance and have very high availability requirements. The risks and their mitigations must therefore be specific to each system and underpinning this, there should be a very good understanding of the system and the processes it supports.
The first steps to securing an ICS system must therefore be to create an accurate plan of the system and its interconnections (as it exists, not how it was designed) and document the processes it supports. This will allow a risk assessment to be carried out, in order to identify, analyse and evaluate the risks before identifying measures to mitigate them.
If the IT and operational technology (OT) systems of an organisation are connected, then this exercise must be applied to both IT and OT as a single overall system and, critically, this must involve the people on the shop floor who run the system and understand how it actually works. As things will change over time, the system and risk assessment must be reviewed and updated regularly.
It is nearly 10 years since Eric Byres first presented his paper Unicorns and air gaps: do they really exist?. The mythical air gap does exist today, but only in highly critical control systems such as those for a nuclear reactor. A system that is truly air-gapped can only accept data from outside through a physical device (such as a keyboard) and output data through another (a printer, for example).
As soon as you start moving data on physical media such as USB sticks, a logical connection is created that can be exploited, as was seen with Stuxnet.
That is not to say an air gap is not a valid security measure, but the risk is believing there is an air gap when there is not. If one is to be used, any transfer across the gap – or bridge to another system – must be known and properly controlled and documented.
All too often, air gaps are bridged using ad-hoc undocumented solutions with an extra cable bridging the air gap, or even using 4G internet connection to provide external access to suppliers for maintenance, illustrating the need to know the system as it is, not how it was built.
The risks to ICS tend to be much more about availability and integrity than confidentiality – and nearly always include safety. Operational aspects must also be taken into account.
Patching problems
For example, patching can be a problem when the system may only be shut down for one day a year for maintenance. Patches must be tested so that they work without any unintended consequences. Also, some systems will have been in place for many years and there are likely to be vulnerabilities that cannot be patched, or where no patch is available. Here, mitigations are required to reduce the chances of an attacker exploiting the vulnerabilities.
Also, where safety and availability is paramount, an access control policy that might lock out a user during an emergency and prevent an out-of-control process being shut down is not acceptable. Because of the needs of ICS, you can’t simply take an IT security check list and apply it to an ICS system. Instead, you need to rely on controlling access into the system, applying zoning to create monitoring and control points that an attacker must pass through, and locking down remote access.
Using an ICS firewall/gateway between the IT and OT systems and ICS firewalls between zones will provide monitoring to detect potentially malicious activity as an attacker tries to move through the system. That will also allow blocking of control signalling that would be needed to exploit known vulnerabilities that cannot be patched.
Supply chain attacks initiated by an attacker compromising a subcontractor or supplier and then using their access rights to breach their customers’ systems are becoming more common. Therefore, such remote access must be tightly controlled using multifactor access control, managed by the system owner.
Remote users should have limited access to only the machines that they need access to and their actions should be monitored and logged in detail. It may also be necessary for maintained times to be agreed and access granted only at the agreed time, with live monitoring by a system operator of exactly what is being done.
We continue to see cyber attacks on critical infrastructure targets, but over the past five years there have also been new regulations published for CNI, in particular the EU’s Network and Information Security (NIS) Directive, and the security of CNI systems has been improved.
This has been partly by regulation leading to more detailed risk assessments and partly by the introduction of new technology, with many CNI systems being updated to remove old vulnerable technology.
Also, the need for remote access and the use of cloud solutions has underlined the myth of the air gap as a defensive measure in most cases.
The attack on the water treatment plant in Florida, which appears to have been mounted through a remote logon and thwarted when an on-site engineer noticed that things were not as they should be, does however underline the need to control remote access, as well as the fact that the operators who understand the systems must be part of the risk assessment and management of their systems.
