![IT to OT Image](https://media.isc2.org/-/media/Project/ISC2/Main/Media/insights/Features/old/IT-to-OT.jpeg?h=213&w=320&rev=e23a35e049a0480da01bf33b93c6dda6&hash=E4D899FEC5B108C2B4636AD7CD0D7F1A)
Cybersecurity professionals are used to defending IT systems against malware and other cyber attacks. In recent years, though, attackers have increasingly targeted Operational Technology (OT) systems.
What is OT? According to the UK’s National Cyber Security Centre (NCSC) it is “technology that interfaces with the physical world and includes Industrial Control Systems (ICS), Supervisory Control and Data Acquisition (SCADA) and Distributed Control Systems (DCS)”. And why is OT a target? Simple: because it is connected to the organization’s network but is generally not managed by the IT team.
Why Is This a Challenge for Members?
While the IT and cyber teams (hopefully) have procedures and schedules in place to check for vulnerabilities, to deploy regular vendor software and firmware updates and to review configurations, the regime is usually less rigorous in the team that operate the OT equipment.
And there are various reasons for this. For instance, the network connectivity and operating software of the equipment is often a very small part of the engineering of the OT kit. If you’re, say, the boiler specialist in a huge engineering plant, your training may well have included days of instructions on how to diagnose gas flow issues or change oil pumps, not to understand the risks of the boiler being connected to the company LAN. Do the daily and weekly boiler reviews include a check on the vendor’s web site to see if there’s a software update with security fixes? We would hope so, but the answer is often no. This is frequently the case with many non-IT devices, not to mention that many such devices are still found to not receive the same degree of software and vulnerability support from their manufacturer as an application or operating system would.
OT systems have a habit of relying on legacy versions of operating systems – for instance, a report from Palo Alto Networks noted that 83% of medical imaging devices run on unsupported operating systems, which is particularly problematic given that around three quarters (72%) of healthcare organizations have IT and non-IT devices on the same network segments. It's not simply a case of upgrading the operating system – it’s commonly the case that the application software simply won’t run on a more recent version because it uses (for instance) calls to software libraries or hardware drivers that have been deprecated in later version of the OS.
Where complex industrial systems are supported by their vendors, one often finds out-of-band connectivity that enables the vendor to manage and diagnose the system remotely. It’s depressingly common to see attacks on company systems made from afar using a remote access feature that’s designed to permit access to, say, the vendor of the company’s air-conditioning system. And if the vendor can connect, so – potentially – can a bad actor.
What Can We Do About These Growing Risks To OT?
There are three key things we must do as cybersecurity professionals dealing with OT systems. First, there must be no distinction between IT and OT with regard to connectivity and security. The IT- and security-related elements of the design and planning around introducing or modifying a piece of OT kit must go through exactly the same level of scrutiny, design approval and change control as, say, a new server would. There must be an approval process for any out-of-band vendor connectivity, though the best approach is for this to be completely forbidden – it would be far more sensible to use connectivity provided by the IT department through firewalls they control, and for connections to be enabled on request and disabled by default.
Second, we must treat all OT equipment as untrusted. We have firewalls between the company network and the internet because we don’t trust the internet. We have the management interfaces of our servers’ out-of-band management adaptors in a separate network segment so that a compromised user’s login cannot be used to attack the servers via a high-privilege way in. We need to make sure that we defend the IT network from the OT systems on it, and to have a strong regime of applying updates, installing patches and conducting regular configuration and log reviews just as we would in the IT world. And we should give serious consideration to having no external connectivity at all – it could well be that the inconvenience of having to wait for an engineer to attend site is outweighed by the risk reduction that approach brings.
Finally, we need to wake up to the risk presented by our OT devices. We mentioned boilers earlier, but there are plenty of other types of devices that are, quite simply, big and/or dangerous, such as industrial plant, the medical systems we touched on previously and even chemical pipelines. Even inadvertent software bugs have been seen to harm people, and so an orchestrated, deliberate attack on OT systems must surely present an even greater hazard.
Yes, OT’s level of connectivity and exposure might be perceived as lower than that of IT. But with a lesser level of security scrutiny and a growing level of attacks specifically aimed at OT, we need to act to keep the risk within tolerance.