Maksim Kabakou - Fotolia

Security Think Tank: Take a realistic perspective on CNI cyber attacks

In light of increasing cyber attacks on critical national infrastructure, what are the immediate risks to industrial control systems and other operational technology, and what steps can be taken to address them?

The recent cyber security attack on the water treatment plant in the Florida city of Oldsmar was caused by the failure of the facility to update its core IT systems.

Running Windows 7, which Microsoft no longer supports, meant security had not been upgraded since the beginning of 2020. From there, it was straightforward for a malicious user to gain access to the supervisory control and data acquisition (Scada) systems, and temporarily change the programme settings to increase the amount of cleaning chemicals added to the water.

In reality, only a handful of dedicated attacks against industrial control systems (ICS) have been documented over the years. But because of the severity of the disruption that can be caused, advanced persistent threat (APT) groups are increasing their focus on targeting them.

The key risks that this raises can normally be divided into three categories:

  1. Alteration of the actions that an ICS device is performing to cause harm. The release of chemicals into the water supply in Florida and the Stuxnet attacks against an Iranian nuclear power plant are good examples of these risks occurring.
  2. Disruption of critical infrastructure by attacking ICS devices or flooding networks with traffic via denial of service (DDoS) attacks. This can take significant time to resolve and be costly to correct.
  3. Use of ICS networks as a gateway into other parts of an organisation’s systems.


The first step to addressing these risks is to understand the ICS devices that are managed – for example, how many there are and where they are located? National infrastructure is spread out over a wide geographical area – and increasingly in consumers’ homes – so not everything will be immediately visible.

Physical protection of these devices is less of a concern; the industry has successfully deployed deterrents such as fences, gates, security guards, and underground burial for decades. 

But as more of them are used within households, safeguards are required to ensure these cannot be tampered with directly, causing them to send back false data, or programmed to modify other devices in the chain by sending erroneous data.


Historically there has been a divide in organisations between the engineers who build and maintain ICS networks, and the corporate team that often determines cyber security policies.

As ICS networks continue to integrate more industrial internet of things (IIoT) devices, the physical barriers are broken down. This needs to be mirrored by ideologies – education on both sides helps to close the gap so that corporate IT understands the nuances of ICS technology, and ICS engineers can fully comply with standards and understand the risks that are being addressed.


At the same time, neither the technologies nor their applications are ‘like-for-like’; it’s important to accept the differences and know what is possible. 

Anything that risks compromising the availability or stability of the ICS network will receive heavy pushback, for example. This makes undertaking changes and maintenance a difficult task as, unlike the corporate world, most devices have zero downtime planned.

And although the ICS industry has made great strides in the past few years to incorporate security-by-design features (such as complex admin passwords, and encrypted traffic), not all of these principles can be applied to the programmable logic controllers (PLCs) in charge of critical infrastructure and other devices at the end of the chain.

In a similar vein, installing new devices might be the most secure route, but many designed for ICS purposes are built to last decades, making it impractical to replace them. It may be necessary to work with older software, managing insecurities by restricting access, rather than defaulting to the replacements favoured in the corporate environment.

The reality

The reality of a totally isolated ICS network is an unrealistic fantasy for many organisations, especially with IIoT being connected for ease of administration and monitoring.

Standards such as the Purdue model (which defines the different levels of critical infrastructure that are used in production lines and the way to secure them) should be adopted where possible to control the flow of data and ensure that vulnerable devices are not accessible to anything that does not immediately need to communicate with them.

Vulnerability scanning is possible but difficult. Many older devices don’t use TCP/IP so regular tools are ineffective and cause unwanted disruption if the device at the other end of the scan doesn’t recognise the requests being sent. There are examples of ICS networks being taken out as a result of a vulnerability scan causing PLC devices to crash on receiving the network traffic.


Even if vulnerabilities are identified, patching is a whole other issue. In the first instance, some organisations are reluctant to take services offline, even temporarily, as it is financially costly. And for those that do, many ICS suppliers issue patches to improve performance rather than security, especially for older devices.

In addition, the often prohibitive costs of keeping development and test networks running, combined with the scarcity of older devices, means it is not always possible to test patches before deploying to productive devices – i.e. everything is done ‘live’ and there is no guarantee that it won’t break. Roll outs therefore need to be undertaken very carefully. If, as is likely, there are no patches to address the security vulnerability, additional controls such as segmenting the network need to be considered.


Along with educating stakeholders, educating the engineers on cyber risk is also critical. Most will already understand the concepts of restricting access and authorised changes as the networks have a high demand for availability and stability, but the reasons behind this often need reinforcing.

For example, it might be routine, or even part of the contract, for engineers to grant remote read-only access to a manufacturer to obtain analytics. But helping them understand why it is important that the connection should be monitored, or reviewed regularly to ensure it is still required and prevent it being misused or abused, is key to maintaining a secure network.


The Florida water plant event was a useful reminder that breaches to do not have to be particularly sophisticated to succeed in disrupting critical national infrastructure (CNI). And with attackers sharing a common administrator username, it highlighted that as much as securing systems can be complex, it is also possible for the most basic measures to drastically increase defence.

People, processes and technology must all be aligned to take a zero-trust approach to securing the estates. Administration credentials should be changed from the default and restricted. And key systems need to be firewalled from other estates, have unnecessary services disabled and be patched where possible to address vulnerabilities.

Finally, it is important to consider the overall picture. Although the risks to ICS infrastructure are increasing, historically, more damage has been done by workers accidentally digging up equipment, weather causing outages, or animals flying into machinery, than by malicious cyber criminals.

Using threat intelligence to determine the actual threat faced by the organisation, combined with an understanding of the way potential infiltrators attack is key to applying appropriate and cost-effective controls that don’t alienate the very people who help to make things secure.

Read more from Computer Weekly’s Security Think Tank about CNI

Read more on IT risk management

Data Center
Data Management