Beyond Compliance: The Role of Threat Models in Safeguarding Critical Infrastructure

There has been much discussion over critical infrastructure lately, especially given recent cybersecurity legislation activity in Asia. In March, Malaysia passed the Cybersecurity Bill 2024,¹ establishing wide-reaching powers over critical information infrastructure (CII) along with regulations for cybersecurity service providers. The bill broadly resembles the Cybersecurity Act Singapore first passed in 2018² and updated in May 2024.³ In June 2024, Hong Kong legislators proposed the Protection of Critical Infrastructure (Computer System) Bill, a first for Hong Kong.⁴ 

Critical infrastructure as defined in legislation typically includes financial services, healthcare, energy, and critical IT systems.⁵  However, the varying interpretations of such legislation by practitioners, consultants, and operators often lead to negotiations between regulators and system owners on the scope and obligations of the laws. Typically, the boundary between a segment denoted as CII (critical information infrastructure) and non-CII, known as a “CII boundary,” must be declared to regulators via a government agency form.⁶ 

In 2021, China Law Insight published an analysis of how CII was defined.⁷ Notably, the United Kingdom and the United States defined CII sectors differently, based on the structure of enforcement agencies in charge of their respective industry sectors. Individual CII and non-CII assets can also be defined within the same subsystem (e.g., network equipment and data information systems may or may not be classified as CII). The analysis also referenced the 2019 Yunnan Cyberspace Administration’s research report, which concluded that before classifying an asset as CII, its business case must be defined.⁸ Such a finding leads to a natural conclusion that grey areas exist in this space. Stakeholders—even those within the same industry—may need to negotiate to clarify the exact nature of what CII business and operational processes entail.

While it is clear that the term “critical” is subjective, there are approaches to meeting CII cybersecurity requirements that are generally consistent. Meeting said requirements is nonnegotiable in light of the increasingly strict cybersecurity legislation governing CII, with severe penalties enforced for CII stakeholders that fail to provide sufficient cyberprotections. Thankfully, increasing awareness of harm beyond cybersecurity impact (e.g., physical) that could occur as a result of a cyberincident has prompted regulators to acknowledge the need to introduce a minimum baseline of cybersecurity requirements.

Compliance-Based Approach

Perhaps the simplest method to incorporate a minimum baseline of cybersecurity requirements is to impose compliance through legislation. With that approach, determining the CII boundary (i.e., the scope of the law) is paramount. Under Singapore’s Cybersecurity Act, system owners are required to complete a CII asset inventory that includes an organizational chart to identify key personnel, a list of assets subject to CII legislation, a CII network diagram, and identification of non-CII interconnected systems. The provision of that information kickstarts downstream activities such as a risk assessment to ensure that the risk the CII owners take is within their risk appetite and does not exceed the risk tolerance associated with their mission and business objectives.⁹ The US National Institute of Standards and Technology (NIST) provides a handy guide for enterprises to determine their risk appetite and tolerance, as shown in figure 1.¹⁰ 

Source: Quinn, S.; Ivy, N.; et al.; “Identifying and Estimating Cybersecurity Risk for Enterprise Risk Management,” NIST, USA, November 2021, https://nvlpubs.nist.gov/nistpubs/ir/2021/NIST.IR.8286A.pdf Reprinted courtesy of the National Institute of Standards and Technology, U.S. Department of Commerce

However, a purely compliance-based approach neglects important artifacts such as a risk picture, which is essential for an enterprise to perform cost-benefit analysis.

Developing a Risk Picture

One way of arriving at a risk picture is through threat modeling. Threat modeling is an engineering technique that assists in threat identification, attacks, vulnerabilities, and mitigations that can affect an application.¹¹  Typically, a threat model will provide relevant inputs for a risk assessment, as shown in figure 2.

Source: National Institute of Standards and Technology, “Guide for Conducting Risk Assessments,” USA, 2012, https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-30r1.pdf Reprinted courtesy of the National Institute of Standards and Technology, U.S. Department of Commerce.

The enumeration of threat events with a threat model such as STRIDE-LM¹²  enables the risk practitioner to assess the likelihood and impact of a threat event exploiting a vulnerability within the system.

Other Threat Models

Besides STRIDE-LM, there are threat models such as LINDDUN,¹³  PASTA,¹⁴  and attack trees¹⁵  that enable users to view systems from different perspectives to uncover threats that were previously not apparent. There are also hybrid threat modeling approaches—for example, Carnegie Mellon’s Hybrid Threat Modeling Method (hTMM), developed in 2018,¹⁶  which combines STRIDE, security cards, and persona non grata (PnG) models. At the governmental level, the Cyber Security Agency in Singapore has issued its own recommended hybrid threat model, combining the STRIDE-LM and MITRE ATT&CK frameworks.¹⁷  Figure 3 summarizes common threat models, their benefits, ease of use, best-suited industries, strengths, and limitations.

Even if threat models are combined successfully, an enterprise may want to understand the sequence of events leading up to a compromise. In IT systems, this can be a crown jewel, whereas in OT systems, this can be a critical process. These can be encapsulated in the Cyber Kill Chain²³  or, more comprehensively, in an attack tree, which was initially developed by Bruce Scheider in 1999.²⁴  As shown in figure 4, the tree root is denoted as the goal for the attack, while the leaves are ways to achieve the goal.²⁵ 

The main attack pathways permit a focus on threats that allow attackers to achieve their objectives, as opposed to threats that, even if they materialize, do not result in significant gains for attackers. In figure 4, the values “P” and “I” are used to denote the likelihood of possibility between “Possible” and “Impossible,” assuming the attacker is a typical employee without specialized skills. Attack graphs can also be combined with existing threat models, one of which was proposed by several cybersecurity researchers in 2022.²⁶ 

But attack trees can be complex. For the uninitiated, Adam Shostack’s book, Threat Modeling Designing for Security provides many pre-worked analyses of attack trees.²⁷  An attack tree included in the book (figure 5) is useful in contextualizing a near-miss in a Florida (USA) water treatment plant attack, when sodium hydroxide levels were increased beyond safety limits.²⁸ 

Source: Shostack, A.; Threat Modeling: Designing for Security, Wiley Data and Cybersecurity, 2014, https://ieeexplore.ieee.org/document/9932386

The bypass protection rules shown in figure 6 are an example of an issue that needs to be mitigated due to a loss in integrity (something derivable with STRIDE-LM).

From Threat Models to Stakeholder Management

In the world of critical infrastructure, threat models and risk pictures need to be translated into the language of critical infrastructure, which is sector-specific and can be process-driven rather than data-driven. For instance, a brokerage that experiences a denial-of-service attack could face a serious risk of legal liabilities due to the financial losses arising from the inability to process transactions. However, if a nuclear plant’s cooling system could not be trusted to work (e.g., due to a cyberincident), that would constitute a safety risk, forcing a shutdown and hence the inability to provide power to customers.

Sector-specific cybersecurity measures often necessitate the incorporation of generic threat models in the context of the industries concerned.

For instance, in the world of nuclear plants, fault-tree analysis and classical probabilistic risk assessment techniques are extensively used to measure the risk of an event occurring and determine the chain of events required for a catastrophic outcome.²⁹ However, to a cybersecurity practitioner, these are termed “attack tree analyses” and “quantitative risk assessments.” These alone cannot provide sufficient tactical guidance from a risk mitigation angle. They would necessitate the use of a tactical threat model such as MITRE ATT&CK for ICS systems before being translated into safety-critical language (in both operations and regulatory forms). In the context of a nuclear plant, that might be how cyberattacks lead to physical impact. Some examples of these are illustrated in figure 7.

The example of a nuclear plant is highlighted due to its safety-critical nature. Sector-specific guidance—such as nuclear plant safety (by the IAEA)³⁰ and the US Cybersecurity and Infrastructure Security Agency’s nuclear-specific guidance to implement a cybersecurity framework³¹—is useful to help cybersecurity practitioners, process engineers, and regulators translate information seamlessly for their perspectives.

The nuclear example is just one type of critical infrastructure. A similar way of thinking can be applied to other critical infrastructure sectors to harmonize the views for different types of stakeholders. Specifically, it is important to use sector-specific language such as safety (e.g., for utilities), speed of transactions (e.g., for finance), and personal data (e.g., for healthcare).

Conclusion

The importance of securing CII cannot be overstated. Legislation passed to regulate CII seeks to codify some of the minimum benchmarks and regulations required. CII owners who want to understand the full spectrum of risk they might be undertaking should:

• Go beyond compliance and look at risk.
• Use different threat models to provide different insights to risk.
• Use prebuilt attack trees to further understand how attackers may achieve their objectives.
• Go through the sequence of steps on an attack tree to understand if existing security measures mitigate risk (even if the starting point might be outside the CII boundary).

Securing CII goes beyond cookie-cutter compliance. A risk picture is often necessary, and threat modeling enables risk practitioners to identify risk that manifests from any number of threats to their environment

Endnotes

¹ EY, “Malaysia: Cyber Security Bill 2024 Enhancing and Safeguarding Malaysia’s Cybersecurity Landscape,” 8 May 2024
² Singapore Statutes Online, “Cybersecurity Act 2018,” Republic of Singapore Government Gazette Acts Supplement, 16 March 2018
³ The Business Times, “Singapore Amends Cybersecurity Law to Better Secure National Interests, Essential Services,” 7 May 2024
⁴ Lee, J.; “Key Computer System Operators to Be Kept Confidential Under Proposed Cybersecurity Law, Security Chief Says,” Hong Kong Free Press, 2 July 2024
⁵ Cybersecurity and Infrastructure Security Agency, “Critical Infrastructure Sectors,” USA
⁶ Cybersecurity Agency of Singapore, CII Information Record
⁷ Xuanfeng, N.; Han, W.; et al.; “The National Important Equipment—Interpretation of the Regulations on the Security Protection of Critical Information Infrastructure,” China Law Insight, 13 September 2021
⁸ Ip, K.; Lau, N.; et al.; “China Cybersecurity and Data Protection: Monthly Update—August 2019 Issue,” Lexology, 19 August 2019
⁹ Duncan, B.; Zhao, Y.; et al.; “Corporate Governance, Risk Appetite and Cloud Security Risk: A Little Known Paradox. How Do We Square the Circle?,” Aberdeen University Research Archive (AURA)
¹⁰ National Institute of Standards and Technology (NIST), NIST SP 800-39 Managing Information Security Risk: Organization, Mission, and Information System View, USA, March 2011
¹¹ Microsoft, “Threat Modeling,”
¹² CSF Tools, “STRIDE-LM Threat Model,” 
¹³ Linddun, “Privacy Threat Modeling,” https://linddun.org/
¹⁴ Kirtley, N.; “PASTA Threat Modeling,” Threat-Modeling.com, 24 July 2022
¹⁵ Shevchenko, N.; Chick, T.; et al.; “Threat Modeling: A Summary of Available Methods,” Carnegie Mellon University, July 2018
¹⁶ Mead, N.; Shull, F.; et al.; “A Hybrid Threat Modeling Method,” Carnegie Mellon University Software Engineering Institute, 27 March 2018
¹⁷ CSA Singapore, “Guide to Cyber Threat Modelling,” February 2021
¹⁸ Microsoft Learn Challenge, “Microsoft Threat Modeling Tool,” 25 August 2022
¹⁹ CSF Tools, “STRIDE-LM Threat Model”
²⁰ Loveless, M.; “How We’re Creating a Threat Model Framework That Works for GitLab,” GitLab, 9 July 2021
²¹ MITRE Engenuity, “Threat Modeling with ATT&CK,” 24 July 2024
²² MITRE, “D3FEND – A Knowledge Graph of Cybersecurity Countermeasures,” 
²³ Lockheed Martin, “The Cyber Kill Chain” 
²⁴ Potteiger, B.; Martins, G.; et al.; “Software and Attack Centric Integrated Threat Modeling for Quantitative Risk Assessment,” Proceedings of the Symposium and Bootcamp on the Science of Security, 19 April 2016
²⁵ National Cyber Security Centre, “Using Attack Trees to Understand Cyber Security Risk,” United Kingdom
²⁶ Valenza, F.; Karafili, E.; et al.; “A Hybrid Threat Model for Smart Systems,” IEEE Transactions on Dependable and Secure Computing, vol. 20, iss. 5, 11 October 2022, p. 4403-4417
²⁷ Shostack, A.; “Front Matter” Threat Modeling: Designing for Security, Wiley Data and Cybersecurity, 2014
²⁸ Hollister, S.; Clark, M.; “Turns Out That Florida Water Treatment Facility Left the Doors Wide Open for Hackers,” The Verge, 10 February 2021
²⁹ Smidts, C.; Ray, I.; et al.; Cyber-Security Threats and Response Models in Nuclear Power Plants, Springer, 2022
³⁰ International Atomic Energy Agency, “Safety of Nuclear Power Plants: Design,” IAEA Safety Standards, 2016
³¹ Cybersecurity and Infrastructure Security Agency, “Nuclear Reactors, Materials, and Waste Sector,” USA

DONAVAN CHEAH | CRISC, CISSP, OSCE3, OSCP

Is a senior cybersecurity consultant with Thales. He has spoken at conferences about various topics such as threat modeling with the system development life cycle (SDLC) and moderated C-suite panel discussions on contemporary cybersecurity topics. He is also the creator of a Thales cybersecurity gamification experience, "Defend the Breach.”