Controlling security within IIoT

Controlling security within IIoT
(Image credit: Shutterstock)
About the author

Satish Gannu is Chief Security Officer & Senior Vice President Architecture and Analytics, ABB Digital at ABB.

The Industrial Internet of Things (IIoT) is a merging of both information technology (IT) and operation technology (OT), combining business-critical technology with nation-critical infrastructure.  

Customers looking to move into IIoT all require and expect the strongest possible security, but the line is blurred when we discuss who is implementing this. This is where we require IT and OT professionals to work together to ensure a seamless transition and avoid delay to essential security deployment. 

A recent Forrester survey of IT and OT/Line of Business leaders showed IT and OT managers evenly divided on which party is responsible for security. As a result of this uncertainty, reports Forrester, an unacceptably large number of companies — 59 per cent — are willing to "tolerate medium-to-high risk in relation to IoT security." This has the potential to be dangerous for all parties involved.

The differences between enterprise IT and OT:

  • Availability: IT considers 99% uptime acceptable, while OT requires 99.999% uptime. The difference translates to between 8.76 hours and 5.25 minutes of annual downtime;
  • System life: IT systems are refreshed, on average, every three to five years. OT systems, by contrast, last 10 to 15 years;
  • Patching: IT patching or updates can be done whenever updates are available, but OT patching or updates risk interrupting strategic, revenue-generating industrial operations.

There are many other differences between IT and OT, with varying approaches to the cloud being one, but all differences are underlined by a need for the strongest IIoT security available.

Something to consider is a solution that allows industrial companies to utilise IT to develop their security architecture, and create a solution that meets the differing requirements of OT. This serves to utilise the decades of IT experience that have helped to build IoT and IIoT, as well as taking into account the increasingly specific needs of OT. 

The patching conundrum

When it comes to patching software, a direct link between IT and OT is not always feasible. For that reason, it is essential that those within the IIoT industry combine their intelligence and work together to develop robust cybersecurity techniques that are more agile and effective than reflexive patching.

Anyone within the industry will know that patches have the capacity to create problems and possibly make an issue worse, and opinions on patching from both IT and OT differ. With IT, if something is infected, the initial instinct is to quickly shut down the source and then patch or replace it. 

However in OT, the tendency is to keep the software up and running, due to the legacy systems used by OT. Some crucial OT systems have been in operation for 15 to 25 years and therefore are not designed to be taken down and patched quickly and efficiently, even if an appropriate patch is available, as these systems may not have enough memory or bandwidth to accept patches.

Alongside this, IT systems can be taken down, patched, and started up again to deliver identical service, with backup servers lined up to take over. However, OT systems are often highly complex software and hardware, each with a unique makeup. Regardless of whether a company can patch a machine, once patched results are often unpredictable as the systems ultimately differ thanks to the introduction of the patch.

A problem solved?

In terms of a solution to the IT/OT faceoff, the introduction of threat analysis would identify which systems have potential to continue operation without patches, and those which need to be stopped for patching. Threat analysis would also validate a vulnerability, but it is important to ask another question: If this vulnerability can be exploited by certain threats, is there a way to protect from those threats without patching? 

For example, security experts could create a set of predetermined scripts within the network that would help identify the appropriate response to several different threats. These scripts could serve as an "if/then" template to formalise, automate, and accelerate responses to threats. The point is to think with more sophistication than a standard “to patch or not to patch” decision.

Software companies must support the development of threat analysis by sharing more information about the patches they release. Key pieces of information we should be seeing more of are how vulnerabilities can be exploited and possible ways to protect against them. This extra transparency would give customers the information needed to make decisions on the right security actions for affected systems. Security experts need to be confident that a patch has the capabilities to maintain the same risk level that existed before a vulnerability was discovered.

In order to achieve faultless security in IIoT, IT and OT leaders must ensure they are working collaboratively in order to get the best of both technologies and bring them together. If those operating within IIoT can combine their system processes to build a security option that works for both IT and OT, leaders will soon see the benefits of the seamless defence they have developed.

 

Satish Gannu is Chief Security Officer & Senior Vice President Architecture and Analytics, ABB Digital.

Satish Gannu

Satish Gannu is the Chief Security Officer at ABB Ability.

Entrepreneurship: Established Vishleshan Technology, an analytics company. The purpose was to develop the product that provided predictive analytics and personalization to in-store retail.
Strategy: Created the cybersecurity strategy for ABB’s Cybersecurity and cybersecurity services business. His
Driving Revenue Growth: Directed Capture-Transform-Share solutions to grow by Cisco’s Emerging Technologies Group by 50+% YoY, generating $28M revenue in FY12. He also grew the Cisco’s IOS Threat Defense business from $50 million to $400 million over four years.
Turnarounds: Turned around an engineering start-up organization and developed capabilities to improve the quality and consistency of build releases to improve the customer experience.