When we think of critical national infrastructure (CNI), we tend to think of power, water, and transport industries. Although CNI also includes communications and finance, it is the heavier, safety-critical industries that we think of first.
Typically, these involve sizeable 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 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 designs are not physically secured in a friendly, air-conditioned room. Still, they are often spread out over several square kilometers, or even many kilometers along a pipeline, making them highly vulnerable to tampering.
Also, they cannot be shut down quickly for maintenance and have very high availability requirements. Therefore, the risks and their mitigations must be specific to each system and underpinning this, there should be an excellent understanding of the system and the processes it supports.
Therefore, the first steps to securing an ICS system must 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 to identify, analyze, and evaluate the risks before determining measures to mitigate them.
Suppose the IT and operational technology (OT) systems of an organization are connected. In that case, 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 genuinely air-gapped system 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, transfer across the gap – or bridge to another system – must be known and adequately 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.
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 are paramount, an access control policy that might lock out a user during an emergency and prevent an out-of-control process from being shut down is unacceptable. Because of the needs of ICS, you can’t simply take an IT security checklist and apply it to an ICS system. Instead, you need to rely on controlling access into the system, using 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 monitor detecting potentially malicious activity as an attacker tries to move through the system. That will also allow blocking of control signaling 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 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 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 arranged time, with live monitoring by a system operator of precisely what is being done.
We continue to see cyber attacks on critical infrastructure targets. Still, over the past five years, there have also been new regulations published for CNI, particularly the EU’s Network and Information Security (NIS) Directive. The security of CNI systems has been improved.
This has been partly by regulation leading to more detailed risk assessments and partly by introducing new technology, with many CNI systems being updated to remove old vulnerable technology.
Also, the need for remote access and 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.