Skip to main content
Blog

A discussion around risk and vulnerabilities of operational technology

What are the risks and vulnerabilities around operational technology and how can organisations address these?

Security

Robotic machinery
Phil Hargreaves

Phil Hargreaves

CISSP, NetSec Senior Team Leader

Operational technology (OT) resides at the very core of our day-to-day life. Often overlooked, it ultimately controls our drinking water, electricity grids, medical care and transport networks. Its technology predates IT, and many of the OT devices running today have been in place for decades - longer than the IT we see and interact with more directly. For some strange reason though businesses have often rushed to invest in cyber security tools and resources overlaying their data driven networks before looking in depth at the wants and needs of their older OT cousins.

We are now an incredible 15 years on from the initial deployment of what became known as the Stuxnet virus.  One of the most advanced pieces of malware ever developed (that we know about of course), Stuxnet is a fascinating story of cyber warfare being conducted at a nation state level. It was specifically designed to infiltrate and disrupt the Iranian nuclear programme by changing the rotational speed of centrifuges, unbeknown to the operators. It continued to travel beyond its initial intended target, infecting an estimated 200,000 devices worldwide in search of specific Siemens software giving control to PLCs. 

So, in the years that have passed, how have the challenges in the world of OT security changed? And maybe more importantly, are we any better prepared in our OT/Internet of Things (IoT)-driven world to protect against such attacks?

Understanding the risk

Despite the high profile and advanced nature of Stuxnet and other OT specific attacks in more recent years, it has taken quite some time for a mindset shift on operational technology. For a long time this was purely the domain of the engineers operating it, and traditional IT security teams were kept at arm's length. We have seen a mindset shift now where businesses have identified cyber specific threats to OT as needing an approach led by the Chief Information Security Officer (CISO) or equivalent Head of Cyber Security in the business.

For many businesses, the operational technology they utilise is the lifeblood of the organisation. Be it robotic machinery on an automotive manufacturing line, medical devices in hospitals or the energy and water devices in our critical national infrastructure. These devices, in whichever way they operate, are the revenue creation arm of the business. However, the classic CIA triad (confidentiality, integrity, availability) for information security is inappropriate to directly use when we are working with IOT/OT. The prioritisation of CIA also has to change to SAIC:

Source: Tech Target

Safety: if this device becomes compromised in any way is there a direct or in-direct threat to life?

Availability: if this device is taken offline is there a direct or in-direct threat to life?

Confidentiality: if this devices data is stolen could that represent a risk to life or trade-secrets?

Integrity: if this device’s state is changed without our knowledge, could that represent a threat to life?

Utilising the risk methodology above provides an elevated answer back to the business when we are looking to calculate the ROI from investments in OT Security. This coupled with the classic quantitative risk analysis, such as loss of earnings from an outage and recovery time, should be the basis when deciding the appropriate level of security required. However, if your organisation is regulated against a compliance framework such as the NIS Directive, your ability to demonstrate proficient cyber security will be more stringent.

Addressing the risk

Since the out-break of the WannaCry ransomware attack, we have seen enterprise IT system administrators adopt a much more rigorous approach to vulnerability management in the traditional corporate environment. This approach has become somewhat of a ‘patch everything immediately’ on a monthly rolling basis. There are, however, multiple issues in the OT world which stop this from being an available approach.

The first stumbling block we see is the age-old problem of assets. Accurate asset inventories are hard to collate and maintain in pure IT environments. With a wider stakeholder group in operational technology, as well as a lack of understanding of the asset type and protocol utilisations, IT security professionals are struggling to get a baseline they understand to make decisions moving forward. Our collaboration between IT and OT must increase on a relationship and understanding level to affectively tackle the issue together.

The second issue is how vulnerabilities are identified and dealt with inside OT environments. In research led by Dragos it was found that 77% of common vulnerabilities and exposures (CVEs) in OT released in 2022 had no vendor mitigation available, and 30% had no patch available upon release.  This is a considerably higher ratio than we see in IT environments and is more concerning when our risk tolerance is understandably lower due to the safety critical nature. We haven’t then even got into the myriad of issues surrounding the testing and deployment of patches in narrow service windows – that is if the organisation even has set service windows. The only approach available is to take a more detailed look at every CVE and create a more considered judgement call each time, which we maybe don’t do as often now in our IT world:

1. What could this vulnerability allow and what is the impact when we link it back to SAIC?

2. Is it realistically exploitable in the environment, and what other factors would have to align for it to be exploited? Is there anything I can put in place to monitor for exploitation attempts, particularly if no patch is available yet?

3. Are there any insecure by design issues which are exacerbating this vulnerability, and can we take action against them?

4. Is it possible to test the patch? Has it been discussed in depth with the OT asset owner/engineer? Do we have an available service window to perform this upgrade and what are the timescales for that?

5. Will this patch affect any of the other systems that this system interfaces with or do I need to deploy a wider set of upgrades at the same time?

Running an OT Security Vulnerability Management programme is therefore a complex task which takes a time and people investment over many years to reach maturity. There isn’t a silver bullet you can buy off the shelf to solve the multi-layered nature of this problem, as a colleague once told me, cybersecurity at times isn’t hard, but it is always hard work!

What resources are out there to help me?

It goes without saying that if you want a further discussion around OT security then please reach out to your aligned account team who will be more than happy to facilitate, or contact our Sales team via this form.

There are also some fantastic free resources available to help organisations establish best practice in OT security which I have listed out below:

- The most commonly utilised guide to doing security on operational technology An Overview of ISA/IEC 62443 Standards - detailed overview of the ISA/IEC 62443 series of standards and technical reports. The ISA/IEC 62443 series addresses the security of industrial automation and control systems (IACS) throughout their lifecycle. CISA Subscribe to Alerts – very useful site to subscribe to email alerts for vulnerability releases which includes a specific selection for OT CVE releases.

Here is a fantastic look into the Stuxnet malware mentioned at the start

Triton – Darknet Diaries – another great episode diving into a hack on an OT environment in Saudi Arabi.

Dragos 2022 Year in Review – expert analysis of the state of cyber security in the OT industry in 2022.