Threat modelling for OT

Original post by @Odba

How do you threat model OT environment? A system specific threat modeling is useful for product but not a whole enterprise OT en environments. Any recommendations or resources would be be helpful!

1 Like

Original post by @Jacob_Teale

This is a great question!

If anything threat modeling should be prioritised more so for OT systems. OT is such a broad spectrum of technology, often more complex, and containing weird and wonderful protocols (ModBus, etc), and so a significant proportion of security flaws introduced into enterprises are because there’s traditionally been inconsistency between OT & IT’s security posturing; this is a symptom of dislocated teams often working in isolation - a consistent and enterprise-wide threat modeling initiative is advisable to avoid this.

Therefore, just like OT shouldn’t be developed in isolation, it shouldn’t be threat modeled in isolation. Proprietary protocols, OT specific technologies, and OT assets should all be included in the threat model. Crowd-sourcing as much information internally on the specifics at play will help identify attack vectors that might otherwise be overlooked.

It’s also useful to use regulatory frameworks or industry guides for OT security to guide the threat model.NIST recently posted a draft 3rd revision of its Guide to Operational Technology (OT) Security 800-82:SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security | CSRC

Of course, there’s also standards like IEC 62443 that you’ll want to be taking into account.

Wonder if you agree? Hope this helps!

Original post by Charles

I agree with @Jacob_Teale’s comments, note that NIST 800-82 rev 3 overlaps with 62443 3-3 (System) controls series. I would recommend waiting and then revisiting NIST 800-82 once it has been published, there are changes expected.

There are various established methods for threat modeling OT environments and hence protecting assets and critical systems. It is partly dependant on the end user/threat model team to which threat modeling methodology they choose to apply. It is recommended to start creating a security program which will also cover an in-depth threat modeling exercise. The threat model could be revisited on a regular basis, e.g. if new equipment or networks are integrated the threat model can be updated to cover them as well.

For example you can follow an ICS Layered Threat Modeling approach as described in ICS Layered Threat Modeling | SANS Institute by SANS.

Another recommended approach is as per ANSI 62443 4-1 Section 6.3 SR-2: Threat Model - ANSI/ISA-62443‑4‑1‑2018, Security for industrial automation and control systems - Part 4-1: Secure product development lifecycle requirements (formerly Part 4-1: Product security development life-cycl. Described there you will find a series of subject areas that will prompt you to begin defining a clear list of the OT system characteristics that should be taken into consideration in the threat model. You can take into consideration characteristics associated with communications types, network or trust boundaries, scope of the equipment being considered (any external dependencies), attack vectors etc… Once the threats and attack vectors have been defined you can begin applying appropriate countermeasures and controls.

Take a look at some of the sources we have mentioned.