How to engineer real OT security outcomes with IEC 62443 risk assessment

Summary: go well beyond the checkbox towards true IEC 62443 compliance. Learn how an IEC 62443 risk assessment can be used to set testable Security Levels (SLs) for your OT/ICS environment. This is an actionable guide.

Before we begin, don’t forget to check out our previous post on “Why OT security governance can no longer wait: A CISO's call to action” here. I am sure you will find this post useful.  

Let’s begin by understanding why OT security assessments usually do not live up to expectations or turn into an exercise that looks good in paper only. 

Why your OT risk assessment is failing

A week ago someone told you that you need an Operational Technology (OT) risk assessment. So, you hire a risk assessment vendor, or approach an OEM. They spend weeks interviewing people, looking at network diagrams, checking out desktop applications, and running searches on Google on “How to conduct an OT security assessment”.

You get back a 18-page report full of "High," "Medium," and "Low" risks, and a list of random gaps with vague recommendation to "patch systems" and "improve segmentation." The report includes extensive details on the IT side but for some reason, the recommendations and findings do not make any sense on the OT side.

You then approach a true OT security assessment vendor like Shieldworkz and get them to review the report and what do we find?

· The report is just a template where random gobbledegook has been added to make content look big and comprehensive

· On deeper study, we see assets and processes listed that do not even belong to the customer

· While the assessor claims to have done a IEC 62443-based report, there is no evidence for that

· The report is basically of very little use to the customer  

So what went wrong? You didn't perform a risk assessment; you completed a compliance checkbox and engaged the wrong assessment vendor.

This is a scenario that we come across many times.

In the world of Industrial Control Systems (ICS), the whole exercise of risk assessment isn't just an audit. It's an reengineering process carried out in slow motion. The IEC 62443 series, specifically IEC 62443-3-2: Security Risk Assessment for System Design does talk about understanding the risks that emerge from systems and countering them with robust system, process and network design to build an environment that offers itself for defense.

The raw power of IEC 62443: From "Risk" to "Testable requirements"

This is essentially the single most important concept to grasp: The goal of a 62443 risk assessment is not to create a compendium of risks and vulnerabilities.

Instead, the goal is to determine the Target Security Level (SL-T) for different parts of your plant and figuring out what is keeping you from reaching that level.

Think of it like a safety and security essential such as a fire audit for a tall building like One World Trade. You don't just say, "That the design of a particular aspect is 'high risk'." You say, "That aspect must achieve a Safety Integrity Level (SIL) 3." This SIL-3 rating comes with a set of specific, non-negotiable, and testable engineering requirements.

IEC 62443 applies this very same logic to cybersecurity.

•    Security Level 1 (SL-1): Protects against accidental misuse.

•    Security Level 2 (SL-2): Protects against "hacktivists" with simple tools or a bigger level of misuse.

•    Security Level 3 (SL-3): Protects against "skilled attackers" (e.g., industrial espionage).

•    Security Level 4 (SL-4): Protects against "nation-state" actors with vast resources and ability to conduct deep attacks.

Your risk assessment is the formal sequence of tests you use to justify saying, "This production line (Zone) must be SL-2, but this critical boiler safety system (Zone) must be SL-3." Everything requires evidence

Once you have that SL-T, you have figured out your blueprint. But we have more things to do. You simply turn to IEC 62443-3-3 (System Security Requirements) and get a complete list of requirements (like "enforce strong passwords," "use encrypted protocols," "restrict data flows") that your system must have to achieve that specific Security Level.

And voila, your risk assessment is no longer a vague report or an undefined process. It's a build specification.

Imagine, the interstellar 3i Atlas were to turn into a mothership launching hostile probes, would you just sit around and wait till they attack or would you initiate a set of pre-defined exercises to contain the threat? [That’s just a line I just thought of while penning this one]. The idea is to ensure we give the effort adequate level of attention and thought.    

Consequence-based zoning

These days everything is about consequence.

So, how do you determine the target SL? You use the most powerful (and most misunderstood) tool in the 62443 standard: Zones and Conduits.

This is the unique insight: Stop drawing your zones based solely on your network diagram.

Most people get this wrong. They look at a network diagram, see a firewall, and say, "That's a zone." This is asset-based thinking, and it's weak. First of all the network diagram itself could be erroneous or it was last updated when Oumuamua was discovered for the first time.

An IEC 62443 Zone is a grouping of assets that share a common consequence.

Instead of commencing with assets, start by asking your engineers and safety managers these fundamental questions:

What is the absolute worst physical thing that can happen here?

· Possible answer: "A catastrophic boiler explosion or gas leak." (Safety Consequence)

What is the worst operational episode that can happen?

· Possible response: "The entire 'Batch 1' production line stops functioning for 24 hours." (Availability consequence)

What is the worst product related consequence that can manifest?

· Possible response: "Someone steals the secret formula for our product or information on process." (Confidentiality consequence)

Work in the reverse from there.

· Zone 1: Boiler Safety. Group every asset that could cause or prevent that boiler explosion-the safety PLC, its HMI, the engineering workstation used to program it, and the sensor network. This is your "Boiler Safety Zone."

· Zone 2: Batch 1 Production. Group all the PLCs, robots, and HMIs that run that specific line. This is your "Batch 1 Zone."

It doesn't matter if they are on the same VLAN or even the same physical switch. They are now grouped by a shared consequence to which they are tagged. You can now perform a detailed risk assessment on that specific consequence.

The risk of the "Boiler Safety Zone" failing is catastrophic. Your risk assessment will almost certainly demand a high Target Security Level, like SL-3. The "Batch 1 Zone" might be a costly operational failure but not catastrophic, so perhaps its risk assessment lands on SL-2.

You've just used risk to create a practical, defensible, and segmented security architecture.

An actionable 5-step plan for an IEC 62443-3-2-based risk assessment

With me so far?

Ready to do such an assessment for real on your infrastructure? Here is an actionable, step-by-step process.

Step 1: Assemble your "Avengers"

You cannot do this with just IT. You need a core team of:

•    OT/Engineering: The people who built and maintain the process. They know the physical consequences.

•    IT/Cybersecurity: The people who understand threats, vulnerabilities, and network architecture.

•    Safety: The people who have already done the physical risk assessments (e.g., HAZOP) and understand the real-world hazards.

Step 2: High-Level RA (define consequences)

Get this team in a room. Forget technology for an hour. Brainstorm and document the worst-case physical, operational, and business consequences for your facility. This is your "impact" criteria. This is the "what" you are protecting.

Step 3: Partitioning (Draw your actual zones)

Now, pull out the process diagrams (P&IDs) and network diagrams. Based on the consequences from Step 2, start grouping assets.

•    "All these devices are part of the 'Wastewater Treatment' process. If they fail, we have an environmental spill." -> This is a Zone.

•    "These two PLCs talk to each other over this specific cable to manage the 'Batch 1' line." -> This is a Conduit.

You are building a model of your plant based on consequence and communication.

Step 4: Detailed RA (Determine your target SLs)

For each Zone and Conduit you just defined, you now perform the "classic" risk assessment.

◦       Identify threats: Who might attack this? (e.g., Insider, Hacktivist)

◦       Identify vulnerabilities: What are the weaknesses? (e.g., Unpatched, default passwords)

◦       Determine likelihood: How likely is this attack?

◦       Determine consequence: You already did this! (e.g., Boiler explosion)

Now, you plot this on a risk matrix. Your company's risk tolerance will tell you what's acceptable. If the risk is unacceptably high, you must reduce it. How? By assigning a Target Security Level (SL-T). You are formally saying, "To reduce the risk of a boiler explosion to an acceptable level, this Zone must be engineered to SL-3."

Step 5: The gap analysis (AKA project plan)

Ok, so we have reached the final step. For each Zone, you have a Target (SL-T). Now, you measure what you currently have (your Achieved Security Level, or SL-A).

•    Zone: RTUs

•    Target (SL-T): SL-3

•    Achieved (SL-A): SL-1

The perceived gap between SL-T 3 and SL-A 1 is nothing but your project plan. You go to IEC 62443-3-3, pull all the requirements for SL-3, and you now have a prioritized, risk-based, and engineering-driven roadmap for securing your plant.

If you can do all this, then you are no longer just "assessing." You are actually engineering security.

Let’s discuss more.

Find out about our OT NDR solution.