Industrial control systems (ICS) and operational technology (OT) are increasingly being targeted in cybersecurity attacks. Cyber is becoming the new weapon of choice, with geopolitical tensions rising.
Ransomware is commonly picked from the attackers’ arsenal, with Cloudwards.net reporting that, in 2021, 37% of all businesses were impacted by ransomware and that the ransomware demands are increasing at approximately 300% year on year.
Recently, a European oil facility was the victim of a ransomware attack, with dozens of terminals impacted and forced to operate at limited capacity. Some companies declared “force majeure.” These attacks follow the well-publicized attack against Colonial Oil in the US, leading to multiple US States declaring a state of emergency. Unfortunately, these attacks are likely to continue and potentially with renewed vigor. Attackers are becoming increasingly aware of potentially soft targets within the European critical Infrastructure systems and how impactful relatively simple attacks can be. These events highlight the need for critical national infrastructure to be cyber secure.
We are frequently asked:
How to Retrospectively Provide Segregation in IT and OT Networks
Obviously, the best opportunity to incorporate network segregation is in the design stage. However, if procuring systems competitively, this approach must be a specification requirement as it is rarely the cheapest solution, and unless specified, it is unlikely to be proposed by price-conscious suppliers. Consequently, many poorly segregated systems exist.
Segregation can, however, be retrospectively implemented following robust design validation and testing. Although such works are usually only practical in OT/ICS systems during a period of outage or maintenance, it is important not to fall into the trap of considering these works only when an opportunity presents itself. Design and plan the works in advance, ready for an unplanned or forced outage opportunity. Should modifications or extensions to existing systems need to be made, always consider retrospective segregation of the existing system and appropriate segregation of the modified or expanded system.
As with patching, applying segregation best practice to in-service systems is often impossible. Yet, other mitigations can be made. These might include additional firewalls to protect only vulnerable devices or to control network traffic or data diodes to ensure unidirectional data flow. It is also worth considering the introduction of virtual segregation (VLANs), as this is often possible in live systems without introducing interruptions. Any deficiencies in segregation should be recorded in the risk register.
If You Can’t Patch, What Then?
There are often reasons why it’s impossible to patch. These may include a lack of patch availability in which the manufacturer no longer supports the equipment or the manufacturer has a slow patch release cycle. In cases like this, it’s vital to remember that you are not the only person aware of the vulnerability now. It is very likely it appears in several vulnerability databases, and the bad guys will be aware of this. There may even be published exploits available for download for them to use.
Another reason patching may not be possible is that there is no access to the impacted system to apply a patch, either because the system cannot be physically accessed or the patch may require a reboot, and operations cannot accommodate this downtime. Where patching is not possible, often other mitigations can be put in place, such as:
- Temporarily or operationally revised firewall rules. This can prevent malware ingestion, attacker access and prevent malware and attacker tools from reaching back to the attacker.
- A locally installed additional firewall could be deployed (even into live systems) to provide ‘close protection’ for the now-vulnerable devices.
- Devices, where appropriate, can be temporarily isolated from systems with which communications are not essential; these systems could include additional (occasional use) HMIs, Historians, etc.
In all cases and even where remediations are made and temporary protective measures deployed, entries should be made in the risk register, remembering that there may be dependent devices. Dependant devices could include data consumers, SCADA, HMIs, historians, backup devices, other systems, machine tools, etc. It is also important to remember that not all impacted devices may be permanent consumers of data, so occasional data consumers must also be considered. It could also include devices or systems that may be influenced by the vulnerable system, as might be the case where the vulnerable /device system is being used to control power distribution, feedstock management and bunkering.
There is no excuse for failing to understand and manage risks in critical systems. Don’t dismiss managed temporary mitigations as that temporary mitigation may well save cost, downtime, reputation and even lives. Attackers will seek out easy targets first, don’t let that easy target be you.
The one thing you can’t afford to do? Ignore the risks.