Welcome to the last edition of 2022!

The end of this year is dominated by content in our social feeds on ChatGPT, the impressive OpenAI chat bot. We could not stay behind and created some more content with the help of the bot.

Of course, the other content is all created by humans, we think.

Our complete TMI line-up:

• Threat Modeling ICS & OT Landscapes – Mind that Gap, there’s a sharp EDGE!, a guest blog post by Charles Marrow
• Curated content: SLSA dip — At the Source of the problem! Article by François Proulx
• Curated content: Integrating threat modeling with DevOps. Article by a team of security experts at Microsoft.
• Toreon blog post: An interview on Threat Modeling with ChatGTP, by interviewer Steven Wierckx.
• Toreon Tip for the holidays: Applying STRIDE on your hotel, by Miguel Llamazares

Happy reading!

Seba, Steven, Thomas & ChatGPT

Introduction

This article covers some important aspects of the current Industrial Control System (ICS) & Operational Technology (OT) security complexities. There is a secure-boot vulnerability scenario and the arduous process of rectifying the issue via remote updates. We have a brief look at how some of these issues can be solved during a product’s design phase introducing threat modeling to the equation. And finally, we provide a brief introduction to industry accepted methodologies currently being utilized for threat modeling ICS & OT infrastructure and products.

Cybersecurity & Infrastructure Security Agency (CISA) identified 16 critical infrastructure sectors that require cybersecurity attention.^[1] Some of the applicable industries include sectors corresponding to chemical, healthcare, manufacturing, food, transportation, defense and nuclear areas, just to mention a select few. These industries all have some common architecture principles and structures; for example, all will be utilizing some form of control system or network infrastructure to ensure the required processes and services are functioning as per their intended purposes. A typical ICS architecture is shown in figure 1, the architecture provides an example of the complexity of a complete system. These systems contain many different elements which are coupled together or interconnected through various types of communications mediums.

These systems, network devices and services, which orchestrate harmoniously, are predominantly being connected to untrusted networks. ICS and corresponding OT are increasingly being targeted by malicious attacks. An example attack on a water treatment plant adjusted dangerous chemical levels in the water supply with the potential to be lethal if the attack had not been identified and stopped. In this example the intrusion was via a remote access program with insecure configurations. ^[3] Motives for attacks vary and therefore could be directed at different industry areas without any form of warning.

Figure 1. ISA95 SCADA architecture²

Figure 2 details common control system network protocols, again providing an insight into the complexity of these networks and the multitude of protocols that have to be managed within the boundaries of the system components.

Each device on the network has a dedicated function and applicable working protocols. These negotiating protocols must be used to transfer the data between different devices at different levels/layers of the network topology. On closer inspection of each device and its associated protocols, it becomes apparent that the attack surface of these devices is substantial.

Threats could be subjected to any of the device’s core components. The actual resulting attack may not be directed at the subject device but used to laterally move across the network, resulting in gaining access to other resources or assets with greater value or potential for inflicting a greater impact.

Figure 2. Protocols (ISA 95)^[4]

Many devices are still using legacy protocols for industrial applications, one example is the Modbus protocol that operates on port 502.^[5] In its standard form, before any security has been layered on top, this protocol transmits data un-encrypted in a raw format that could be readable through various network sniffing techniques. To securely communicate data using this protocol the information must be encrypted using industry standard methods, these include Transport Layer Security (TLS) and using x.509 certificates.^[6] This protocol has many known weaknesses and vulnerabilities of varying severity and complexity.^[7] Running a shodan.io (Industrial control systems section) query on port:502 shows there are approximately 464k hosts utilizing this protocol, further details of geographic distribution and vulnerabilities of this protocol are shown in Figure 3.^[8]

Figure 3. Port:502 shodan.io scan results ^[9]

Harnessing the power of threat modeling to Identify potential security issues

Typical scenario – a secure-boot process vulnerability is found in a product, a firmware update or  patch must be built and deployed remotely to devices already in service.

Example threat and weakness:

As per Common Weakness Enumeration (CWE) CWE-1274: Improper Access Control for Volatile Memory Containing Boot Code. In this case an adversary could bypass the secure-boot process and execute their own untrusted, malicious boot code.^[10] A directly associated vulnerability of this CWE is notified in Common Vulnerability and Exposure (CVE) CVE-2019-2267 and details many affected products which serve as a critical device processing component. ^[11]

As per CWE-1274, a potential mitigation would be to ensure that the design of volatile-memory protections is enough to prevent modification from an adversary or untrusted code. ^[12] Although this is a very specific case, details of correcting the issue are under the vendor to rectify with correction in the code as detailed, the issue remains on how to detect and protect early in the product software lifecycle. Once rectified, the code must be distributed securely to all corresponding products via an update or patch.

The next stage of the process enters the issue of systematically transferring the software update or patch securely across untrusted networks to each device. To be secure, the device must validate any software or firmware updates for authenticity and integrity before installation, to ensure that the data has not been modified during transit. An example of this weakness is described in CWE-494: Download of Code Without integrity Check.^[13]

Often these updates are overlooked due to disallowed un-scheduled maintenance cycles or purely based on the costs and man hours involved in processing these updates. There may also be cases whereby the technical capabilities to manage and perform the updates do not exist in the field. Many devices are not being updated on a sufficiently regular basis, as notified by CISA regarding the medical device industry, this notification can also be applied to industrial controls systems and operational technology, some of which may be operational for decades before being updated or finally decommissioned or retired. ^[14] 

Countering at this stage in the products lifecycle, could be by simply taking action to introduce regular software update cycles or un-planned hotfixes with patches in the case of a critical vulnerability notification for the device.

Should the aforementioned weaknesses be present in the device once put into service the rectification is much more complex to implement. If these weaknesses are identified during the development or at least pre-market testing stages of a devices lifecycle, the resources required to correct them are majorly reduced. Using a threat modeling approach to systematically check for known associated threats and weaknesses early on will save development hours and reduce the possibility of further threats once placed into service. Of course, working to correct all vulnerabilities for all system components is not feasible, vulnerabilities should be evaluated and prioritized on a criticality basis. The same can be said for threats to the infrastructure, threats should be prioritized for risk to service disruption and potential impact to business.

There are various methodologies currently suitable for use regarding threat modeling. Usage depends on the application or product under assessment.

IEC/ANSI 62443 4-1, Security for industrial automation and control systems – Part 4-1: Secure product development lifecycle requirements, incorporates threat modeling as a fundamental exercise for the secure product development lifecycle. ^[15] Adopting this step will ensure the product design will take into consideration many important aspects of security that would potentially not be considered if the practice was not adopted. The practice should be considered during the development phase rather than having to patch in security later in the product’s lifecycle. The threat modeling process encourages the gathering of system characteristics related to Data flows, processed data, protocols and ports etc. and then identifies specific threats and weaknesses. Once this information has been gathered related to the device, corresponding security controls are recommended, and secure coding practices can be implemented according to industry best practices. Dedicated countermeasures and controls are identified according to each functional use case and put in place to secure that particular subject area.

Other approaches to threat modeling ICS and OT are described in the ICS layered threat modeling SANS white paper. ^[16] The described methodologies explain how to define threats in a systematic approach that cover key factors of the modeled ICS architectures.

Threat modeling methods should be selected on a subject system or product basis. For example, threat modeling a single product or its software, the IEC/ANSI 62443 4-1 approach could be adopted. In the case of threat modeling ICS and OT the SANS guide approach would be advisable to follow, in these cases the entire system architecture can be modeled.

Conclusion

Threats to ICS, OT and subsequent devices embedded in critical infrastructure architectures are in no means easy to mitigate against due to the systems complexity and immense attack surface. Identification, detection and mitigation of common threats during design phases will support the deployment of secure products, which in turn will strengthen the overall system security. Understanding the processes and applying the correct methods to verify areas with security concerns is a fundamental requirement. Achieving this on an industrial scale will of course take a massive effort, this should be executed one control at a time. The use of proven methodologies and available threat modeling tools will facilitate the system security assessors and their development team counterparts.

Article: SLSA dip — At the Source of the problem!

Article: Curated content: Integrating threat modeling with DevOps.

Are you planning to travel during the end of the year? If so, you may want to take a tip from fellow threat modeler Miguel Llamazares, who applied his skills to threat modeling the minibar in his hotel room a few months ago.

We aim to make this a community-driven newsletter and welcome your input or feedback. If you have content or pointers for the next edition, please share them with us.

Kind regards,
Sebastien Deleersnyder
CTO, Toreon