Threat Modeling (TM) is a process for identifying and prioritizing potential cybersecurity threats to software, hardware or a system.   Contributing to the high value of TM is: 

• The ability to identify threats early in the design process when they are less expensive to address 
• Methodically prioritizing threats helps focus mitigation efforts efficiently 
• For existing (legacy) code, devices and systems, TM can help focus security improvements on the most critical areas.  

Like most high value activities, TM is high effort and has challenges including: 

• Handling legacy code and/or legacy devices and systems 
• TM for complex devices or systems can be overwhelming 
• Existing TM tools aren’t focused on identifying threats specific to IACS devices, systems and protocols 

This blog will focus on addressing each of the challenges above. 

Meeting Legacy Challenges 

True “clean sheet of paper” products are extremely rare, especially for software.   Even brand-new hardware products or systems typically contain software from previous generations of devices or systems.  This legacy code base can be immense and was often developed before SDL (Secure Development Lifecycle) practices were put in place.   In addition, many devices were developed prior to SDL adherence and continue to receive software updates.    Perhaps counterintuitively, TM can reduce the work of improving security for legacy code, devices and systems.  TM can help focus the SDL effort on areas of code, a device or the system which have the biggest impact on security.   In other words, TM can help find the security needles in the legacy haystack.  Consider the image below: 

Input from the external interactor (human, protocol messages, browser etc.) crosses a trust boundary, is validated by input validation code and then makes its way through functions in the main legacy code base.  The code performing input validation will have an outsized impact on the overall security of the device, software application or system.  In fact, current evidence shows more than 40% of all security vulnerabilities for software or devices are triggered by insufficient input validation. This means this code should be subjected to SDL activities such as static analysis, secure design/code reviews and security testing.  The TM helps identify the subset of legacy code performing input validation.  The rest of the main legacy code base can be treated as a black box and prioritized lower for SDL work.   Below is a more comprehensive example: 

In this example, inputs to the legacy device are identified and traced through the device.  For the web browser input, the HTTPS protocol messages are initially validated by the base IP protocol stack and later validated by the embedded web server.  The SDL can focus effort on the threats identified to the code performing input validation for both of these areas.    

TM for complex products or systems 

Many if not most products, software applications or systems are complex, consisting of many different components with complex interactions.   Modern design paradigms and the IEC 62443-4-1 standard advocate modular design principles.  The same modular approach can and should be taken with TM.  For example, consider the block diagrams below for a typical IACS device or IACS System.

Creating a single TM to cover all the components would be problematic.   In addition, many of the components are used in multiple devices or systems which implies TMs for them could be reusable.  Indeed this is the case.   For example, many different devices have embedded web servers and most of threats to these will be implementation agnostic as shown pictorially below: 

Most of the threats to an embedded web server will be independent from the implementation.   This implies a couple of things: 

1. Research on generic web server threats will identify most of the threats 
2. Most of the TM for an embedded web server will be re-usable.    

This same scenario applies to many components in devices such as protocol stacks, firewalls, I/O modules and flash memory.   So, breaking down the overall TM for a device or system as follows will improve results and increase efficiency: 

1. High level TM which identifies trust boundaries and components which need their own TM 
2. Component TMs:
   • Generic TM containing typical threats for that type of component 
   • Implementation specific threats.   In many cases, there will be no implementation specific threats

Another benefit of modular TM is that it supports the need to constantly update TMs to help keep up with the changing threat landscape.   For example, new threats and mitigations for web servers are constantly being identified.   If one uses a single web server TM for multiple devices or systems, they will all gain the benefits of the evolving web server TM.  

TM tool challenges for IACS 

Cybersecurity started in IT and as a result current TM tools are IT-oriented in the sense that they focus on IT security priorities (confidentiality, integrity) and IT technologies (Windows, IPv6, Cloud, SQL Databases etc.).   As a result, they are poor at identifying IACS-specific threats and tend to de-prioritize threats to availability which is the most important type of threat to IACS.   What are the options to address this? 

1. Use the tools to draw the threat model diagram and identify some high-level threats.   Perform research to identify IACS specific threats.  For example, threats to OT protocols,  IACS devices etc. 
2. Employ the modular TM approach described earlier so that threat and threat mitigation research can be leveraged across multiple products or systems. 

Conclusion: 

1. TM for legacy code and systems is extremely helpful in identifying the areas of the device, software or system which have the biggest potential impact on security and thus deserve the most focus for SDL activities. 
2. Modular TM can simplify and improve TM for complex devices, software or systems 
3. Most existing TM tools are focused on IT-specific threats and threat priorities.  Employing a modular TM approach can help mitigate this.