Assessing OT and IIoT cybersecurity risk

This blog is co-authored by Ryan Dsouza, AWS and John Cusimano, Deloitte

Introduction

Innovative and forward-looking oil and gas, electrical generation and distribution, aviation, maritime, rail, utilities, and manufacturing companies who use Operational Technology (OT) to run their businesses are adopting the cloud in many forms as a result of their digital transformation initiatives. Data lakes, Internet of Things (IoT), edge technology, machine-to-machine communication, and machine learning (ML) are enablers for this industrial digital transformation. This is driving changes to the OT landscape, and as these environments continue to evolve, OT environments are leveraging more IT solutions to improve the productivity and efficiency of production operations.

Industrial customers often start their digital transformation journey by sending OT data to the cloud for analysis and analytics without sending commands back to the industrial automation and control system (IACS). This process is often called “open loop” operations, since there is one-way communication from edge to cloud. Customers generally find this relatively easy to secure and manage.

However, one of the goals of Industrial Internet of Things (IIoT) solutions is to optimize operations by generating an automatic or operator-initiated response in the factory or plant, based on insights gained from cloud analytics. This process is often referred to as “closed loop” operations with two-way communication between edge and cloud. The security and compliance practices for closed loop operations are more rigorous because closed loop operations manipulate OT devices remotely. Developing these practices should be rooted in a cyber risk assessment to help businesses understand and prioritize security concerns.

This convergence of IT and OT systems creates a mix of technologies that were designed to operate within hostile networks environments with ones that were not, which creates the need for new risk management considerations. When taking advantage of IT technologies in OT environments, it’s important to conduct a cybersecurity risk assessment to fully understand and proactively manage risks, gaps, and vulnerabilities.

In the ten security golden rules for industrial IoT solutions, AWS provides recommendations including conducting a cyber-security risk assessment at the start of an IIoT digital transformation project and using it to inform system design. There is a well-defined and mature methodology that has been used in performing risk assessments on IT systems for decades called ‘Threat Modeling,’ which is further explained in an AWS Security Blog called How to approach threat modeling. In this post, we will help you apply this guidance specifically for an OT/IIoT use-case and audience as well as highlight the unique considerations in OT/IIoT environments.

Understanding cybersecurity risk

People often struggle with the term risk and what it means in the context of cybersecurity. Risk is generally defined as a function of probability and impact, where the probability is the likelihood of an event occurring, and the impact is a measure of the extent of the adverse circumstance (i.e., the consequence). The common formulaic way of expressing this is:

Risk = Likelihood x Impact

In the field of information security risk management, the likelihood component in the above formula is broken down into its core elements: threats and vulnerabilities. The common formulaic way expressing this is:

Cybersecurity Risk = Threats x Vulnerabilities x Impact

A good reference to learn more about cyber risk is the National Institute of Standards and Technology (NIST) cyber security framework which follows a risk-based logic: “identify, protect, detect, respond, recover.” The NIST framework refers to the many common IT and OT security standards, such as ISO/IEC 27000, COBIT, ISA/IEC 62443. NIST states that, “Risk is a function of the likelihood of a given threat-source exercising a particular potential vulnerability, and the resulting impact of that adverse event on the organization.”

7-step approach to assessing OT and IIoT cybersecurity risk

There are several standards, best practices, and methodologies, such as ISA/IEC 62443, Cyber PHA, NIST, etc. that provide guidance on conducting cybersecurity risk assessments for IACSs. Most of them are generally in agreement with one another about the key points, so we have summarized the guidance from those sources into a 7-step approach that aligns with “what are we working on,” “what could go wrong,” and “what are we going to do about it,” as follows:

Define the system being assessed
Identify consequences of unintended access or behavior
Enumerate known vulnerabilities
Identify threats
Estimate likelihood
Rank the discovered risks
Develop a risk mitigation strategy

Let’s talk through each of these steps briefly.

Step 1 – Define the system being assessed

This step aligns with “what are we working on.” Clearly documenting and defining the OT and IIoT system being assessed is a critical first step. It involves creating diagrams that describe both the logical and physical connectivity that cover the full application from sensors to cloud and everything in-between. Best practice from ISA/IEC 62443 standards is to partition the system into security zones and conduits. As per ISA/IEC 62443-3-2, Security Risk Assessment for System Design, a key step in the risk assessment process is to determine the scope of the risk assessment by partitioning the System Under Consideration (SUC) into separate Zones and Conduits. The intent is to identify those assets which share common security characteristics in order to establish a set of common security requirements that reduce cybersecurity risk. Partitioning the SUC into Zones and Conduits can also reduce overall risk by limiting the impact of a cyber incident. Part 3-2 requires or recommends that some assets are appropriately partitioned as follows:

Isolate business and control system assets
Isolate temporarily connected devices
Isolate wireless devices
Isolate safety-related devices
Isolate devices connected via external networks (example: Internet)

Defining the system also involves a functional description of system operations, an asset inventory, dataflows, and other information required for the assessment team to understand ‘normal’ operations.

Figure 1: ISA/IEC 62443-3-2 Risk Assessment workflow (Courtesy of ISA)

The following example in Figure 2 shows the zones and conduits in a Data Flow Diagram (DFD) with different components in an IIoT system with Zone boundaries between IIoT device, IIoT Gateway, and Cloud and Trust Zones between different cloud services. For example, in AWS, customers can use multiple AWS accounts and AWS Virtual Private Cloud (Amazon VPC) to launch AWS resources in a logically isolated manner.

Figure 2: Example of zones and conduits in IACS with IIoT systems

Step 2 – Identify consequences of unintended access or behavior

The next step is considering what could go wrong if the IACS and IIoT system were to be accessed inappropriately. The access could result in one or more of the following consequences:

a) unauthorized access, theft, or misuse of confidential information

b) publication of information to unauthorized destinations

c) loss of integrity or reliability of process data and production information

d) loss of system availability

e) process upsets leading to compromised process functionality, inferior product quality, lost production capacity, compromised process safety, or environmental releases

f) equipment damage

g) personal injury

h) violation of legal and regulatory requirements

i) knock-on effects on critical systems at the local, regional, or national scale

j) threat to a nation’s security

While many of these consequences are possible for both IT and IACS systems, consequences e, f, g, and i are more likely with cyber-physical systems that can change the physical domain. This is the characteristic that distinguishes IACS and IIoT systems from IT systems and defines the scope of the SUC.

When performing this assessment, the team should evaluate and document the impact to process safety, reliability, and the environment in addition to evaluating the impact of data confidentiality, integrity, and availability (CIA) anywhere in the system, considering both data at rest and data in transit. Having defined security zone and conduits in Step 1 is beneficial because it enables the assessment team to compartmentalize the consequences by zone or conduit as shown in the example in Figure 2.

Step 3 – Enumerate known vulnerabilities

In this step, which aligns with “what could go wrong,” the assessment team evaluates and documents known cybersecurity vulnerabilities in the system. This information can be gathered in a number of ways such as using vulnerability scanning tools and/or vulnerability research on the system components and their configuration. This doesn’t necessarily need to be an exhaustive list of every common vulnerabilities and exposures (CVE), but it should at least include classes of vulnerabilities that unauthorized users may be able to exploit. Again, having partitioned the system into zones and conduits is beneficial as the team can organize their vulnerability discovery and documentation efforts by zone and conduit.

Step 4 – Identify threats

In this step, which aligns with “what could go wrong,” the assessment team considers the credible threats (threat actors, threat sources, threat types) that could attempt to exploit the vulnerabilities identified in Step 3 and uses a model like STRIDE to enumerate “what could go wrong” in each element of the DFD. One good source to reference is the MITRE ATT&CK® for Industrial Control Systems (ICS) framework as MITRE provides broad guidance on describing the actions an adversary may take while operating within an ICS network. It highlights particular aspects of the specialized applications and protocols that ICS systems typically use, and that adversaries take advantage of, to interface with physical equipment. MITRE ATT&CK breaks down the lifecycle of a cyber incident using Tactics, where each Tactic describes a specific goal that an adversary may need to achieve using Techniques, which describes a specific method of achieving the related goal. For example, an unauthorized user may exploit a weakness in remote services (Technique) to gain initial access (Tactic) to the IIoT system. Using a combination of Tactics and Techniques can provide concrete guidance for an IIoT system threat modeling exercise.

Step 5 – Estimate likelihood

This step aligns with “What are we going to do about it.” When attempting to assess cybersecurity risk, many people have difficulty estimating likelihood. While it’s challenging, it can be estimated by decomposing likelihood into its core elements of threats and vulnerabilities and using semi-quantitative methods to define ranges of likelihood. A high-quality reference for this step is the Factor Analysis of Information Risk (FAIR) framework published by the FAIR Institute. They have developed a model for understanding, analyzing, and quantifying cybersecurity and operational risk. The FAIR framework factors security risk into its elements making it easier to understand and more practical to assess.

Step 6 – Rank the discovered risks

In this step, which aligns with “what are we going to do about it,” threat scenarios are defined by describing how a threat can result in a consequence. Threat scenarios include threat actors, threat actions, and the vulnerabilities they may exploit to carry out the event. Once the scenario is defined, the risk can be scored and ranked based on the severity of the consequence and the likelihood of each threat. One good way to conduct this step is in a workshop setting where the assessment team walks through each zone and conduit and develops and analyzes credible threat scenarios. Ranking of the risks is typically guided by the use of a risk matrix which is a matrix of likelihood on one axis and impact on the other. Risk matrices are typically developed by corporate risk management or health, safety, and environmental organizations.

Figure 3: Example Risk Matrix

Step 7 – Develop a risk mitigation strategy

This step aligns with “what are we going to do about it.” Once the risk assessment is completed and its results analyzed, a report should be produced documenting the risks to the organization as well as a plan to mitigate risks to a tolerable level, providing decision makers with a concise risk and remediation picture. This plan is commonly based on safety, financial contribution, or even brand protection- whichever matters most to the organization. An effective remediation plan includes a prioritized list of actions, budgetary estimates, schedules, and resource requirements. Typically, these plans include short-term projects to mitigate high and critical risks and long-term projects that may involve many resources, modernizing the OT environment with new equipment, and training.

Figure 4: Example Risk mitigation roadmap (click to enlarge)

Conclusion

In this blog post, we outlined specific actions that enable customers to understand and assess cyber risk when implementing IIoT solutions. It is a critical activity within OT/IT convergence risk management and helps to answer the questions: “What can go wrong?” “What is the likelihood that it could go wrong?” and “What are the consequences?” These actions help improve overall risk visibility and awareness and lay the foundation for building a secure-by-design IIoT solution. Deloitte and AWS are collaborating to help industrial companies effectively manage the risks coming from industrial digital transformation initiatives by offering IIoT cyber risk assessments. Learn more about Deloitte’s risk assessments and the Cyber PHA methodology here and AWS IIoT services.

To learn more about IoT security best practices, visit The Internet of Things on AWS – Official Blog.

About the authors

Ryan Dsouza is a Principal Solutions Architect for IoT at AWS. Based in New York City, Ryan helps customers design, develop, and operate more secure, scalable, and innovative solutions using the breadth and depth of AWS capabilities to deliver measurable business outcomes. Ryan has more than 25 years of experience in digital platforms, smart manufacturing, energy management, building and industrial automation, and OT/IIoT security across a diverse range of industries. Before AWS, Ryan worked for Accenture, SIEMENS, General Electric, IBM, and AECOM, serving customers for their digital transformation initiatives.

John Cusimano is an electrical & computer engineer and business leader with more than 30 years of experience in process control, functional safety, operational technology (OT) and industrial cybersecurity. He is a managing director within Deloitte & Touche LLP’s Cyber OT practice.

John has performed countless industrial control system (ICS) cybersecurity vulnerability and risk assessments. He is a voting member of the ISA 99 cybersecurity standards committee. As part of that committee, he chaired the subcommittee that authored the ISA/IEC 62443-3-2:2020 standard, “IACS Security Risk Assessment & Design”. He was the developer and instructor of multiple industrial cybersecurity offered by Deloitte and ISA.

John is a Certified Functional Safety Expert (CFSE), a Certified Information Systems Security Professional (CISSP), Global Industrial Cyber Security Professional (GICSP), and ISA 62443 Expert.

This article contains general information only and Deloitte and AWS are not, by means of this article, rendering accounting, business, financial, investment, legal, tax, or other professional advice or services. This article is not a substitute for such professional advice or services, nor should it be used as a basis for any decision or action that may affect your business. Before making any decision or taking any action that may affect your business, you should consult a qualified professional advisor. Deloitte and AWS shall not be responsible for any loss sustained by any person who relies on this article. As used in this document, “Deloitte” means Deloitte & Touche LLP, a subsidiary of Deloitte LLP. Please see www.deloitte.com/us/about for a detailed description of our legal structure. Certain services may not be available to attest clients under the rules and regulations of public accounting.

The Internet of Things on AWS – Official Blog