Properly protecting CNI demands specificity

by Joseph K. Clark

When we think of critical national infrastructure (CNI), we think of power, water, and transport industries. Although CNI also includes communications and finance, we think of the heavier, safety-critical industries first. Typically, these involve sizeable industrial control systems (ICSs) that operate 24/7, 365 days a year, which we depend on daily. 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 differ.

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. Industrial designs are not physically secured in a friendly, air-conditioned room. Still, they are often spread 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 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.

protecting CNI

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 an organization’s IT and operational technology (OT) systems 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 works. Things will change over time, so the system and risk assessment must be reviewed and updated regularly.

It is nearly ten years since Eric Byres first presented his paper Unicorns and air gaps: do they exist? The mythical air gap exists today, but only in highly critical control systems such as nuclear reactors. 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, 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 a 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 considered.

Patching problems

Patches must be tested so that they work without any unintended consequences. For example, patching can be problematic when the system may only be shut down for one day a year for maintenance. Also, some plans will have been in place for many years, and there will likely 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, it would help if you relied 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 the blocking of control signaling 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 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 upon 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, new regulations have been 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 login 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.

Related Posts