Appendix H: Threat Modeling
Introduction
The threat landscape is constantly evolving and escalating as more and more business operations are relying on complex technology infrastructures. Building and sustaining effective mitigating and defense-in-depth strategies requires organizations to have a balanced understanding of both their adversaries and themselves so they can comprehend the nature of threats they face.
Threat risk modeling is an essential exercise that must be viewed as a component of every organization’s overall risk management program. This exercise should be completed to build appropriate countermeasures that effectively reduce business risk impact through the identification of contributing threats. It is important that a structured threat risk assessment is completed to better understand the individual security threats that have potential to affect their business assets, operations, and functions.
Why Threat Modeling?
Specific to information security, a threat is any intentional (eg, cybercrime) or accidental (eg, natural disaster) course of action with the potential to adversely impact people, processes, or technology. Similar to business risk, threats can be classified according to their types, such as:
• Physical damage (eg, fire, water)
• Service impact (eg, electrical, telecommunication)
• Information compromise (eg, eavesdropping, media theft)
• Technical failures (eg, software defects, performance, and capacity)
• Operational compromise (eg, abuse of rights, denial of service)
It is important to recognize that even though the resulting impact(s) of individual security threats can be different, there are commonalities in how all threats are structured and work. Under the structured threat information expression (STIX) framework, illustrated in Figure H.1, organizations can utilize a common language for representing the nine constructs of how threats work. STIX is designed to improve the overall management and understanding of threat information so that organizations can develop mitigation strategies and countermeasures that are meaningful, adaptable, extensible, and automated.
• Observables are the resulting outputs that might be or have been seen across an organization (ie, service degradation)
Figure H.1 Structured threat information expression framework. TTP, tactics, techniques, and procedures.
• Incidents are distinct instances of indicators that are affecting an organization accompanied by information discovered or decided upon during an investigation
• Adversary tactics, techniques, and procedures (TTP) describes the attack patterns, tools, exploits, infrastructure, victim targeting, and other methods used by the adversary or attacker
• Exploit targets describe vulnerabilities, weaknesses, or configurations that can be exploited
• Courses of action are specific countermeasures taken as corrective or preventative response actions to protect an exploit target or mitigate the potential impact of an incident
• Campaigns are event occurrences where threat actors perform a set of TTPs or incidents that are potentially experienced throughout an organization
• Threat actors identify and characterize the malicious adversary with intent and observed behaviors that represent a threat to an organization
It is not realistic or feasible to implement strategies that will mitigate all known threats to business assets, operations, or function. Alternatively, by completing a threat modeling exercise organizations can get a better understanding of threats targeting them and be better prepared to prioritize strategies for reducing their attack surface. STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) is a threat classification scheme that can be used to characterize individual threats based on TTP commonalities and implement countermeasures to reduce the overall attack surface.
Application of the STRIDE scheme as part of the overall risk management program allows organizations to meet the requirements for maintaining security properties of confidentiality, integrity, and availability, along with authorization, authentication, and nonrepudiation. The STRIDE acronym is formed using the first letter of the following six threat categories:
• Tampering involves the malicious and unauthorized (1) alteration of data communication between subjects3 such as business workflows or (2) modification to persistent objects or assets such as database content.
• Repudiation is the explicit denial of performing actions where proof cannot be otherwise obtained, such as executing unauthorized acts against an object or asset. Nonrepudiation is the mitigating control where a record of actions is maintained such as generating an audit log event for specific acts against an object or asset.
• Denial of service attacks decrease the availability and reliability of objects or assets by making them temporarily unavailable or unusable, such as overwhelming a system with access requests.
• Elevation of privilege occurs when unprivileged subjects obtain privileged access and are subsequently authorized to gain access to objects or assets, such as exploiting defenses and impersonating a trusted system.
Business Risk Association
As business operations become much more interrelated with complex technologies, it is crucial that organizations do not continue to manage threats on a case-by-case basis. Alternatively, instead of managing threats through specific technology functionalities, organization should manage their attack surface with the goal of reducing a much larger number of threats without getting into the specifics.
To manage threats from a risk-based approach, organizations should put focus on assessing threats as part of their overall risk management program. The relationship between threats and business risk is illustrated in Figure H.2 whereby threats are represented as direct contributors and drivers for impact to business operations and functions.
Threat Modeling Methodologies
Threat modeling is a process used to identify objectives and vulnerabilities, quantify the organization’s exposure, and develop strategies to mitigate and countermeasure threats. Through the creation of a structured representation of all collected information, organizations are better informed and can make prioritized decision-making to improve their risk posture.
Organizations should ensure that threat modeling is performed as an iterative process and not as a one-time exercise. Threat modeling should be performed consistently throughout each phase of the system and software development to:
• ensure threats that are not identified during initial assessments are subsequently discovered; and
• adapt to changes in system or software designs and evolving business requirements
Several threat models have been published to enable the classification and categorization of individual threats in different ways. In some instances, organizations might find that adopting one threat model over another may not be appropriate for them because it does not meet their business requirements. In all cases, a functional run-through of threat models should be performed so that organizations can determine which one aligns best to their specific needs. While there might be threat models not specified below, the following are examples of methodologies that can be adopted to support a risk management program.
Microsoft Threat Modeling
Developed by Microsoft in 2003, this threat model allows organization to systematically identify and prioritize threats that have the greatest potential impact to business assets, operations, and functions. Leveraging the STRIDE classification scheme, organizations can address individual threats by executing the following six stages:
• Identify assets documents all systems and objects that need to be protected
• Create an architecture overview uses data flow and workflow diagrams to illustrate the relationships and connectivity between systems and objects
• Decompose the application provides further details of the architecture to uncover weaknesses and vulnerabilities in design, implementation, or configuration
• Identify the threats discovers the exact weaknesses and vulnerabilities that could affect the systems and objects
• Document the threats records the attributes of each weakness and vulnerability using a common classification scheme
• Rate the threats scores threats to determine the priority for implementing mitigating countermeasures
Microsoft’s threat modeling methodology is designed to address the unique challenges faced by organization when it comes to reducing the attack surface and improving security of their systems and software. Those involved in performing threat modeling using Microsoft’s methodology will find that, while it focuses more on the technical aspects of business risk, it is easy to learn and adopt throughout any organization.
Process For Attack Simulation And Threat Analysis (Pasta)
Developed by Marco Morana and Tony UV., this is a threat model that is platform agnostic and can be applied to most systems or software development methodologies. This model is focused on aligning business objectives with technical requirements through the completion of the following seven steps:
• Define the business and security objectives documents functional capabilities by completing a business impact analysis from the security and regulatory compliance requirements perspective
• Define the technical scope describes the inclusion of technical assets and components that will be enumerated for threats
• Decompose the application identifies the individual component data flows from which threat and vulnerability assessments are performed
• Threat analysis extracts detailed threat intelligence and assesses the likelihood of attack scenarios occurring
• Weakness and vulnerabilities analysis involves mapping threat analysis results with enumerated weaknesses to develop use/abuse cases and vulnerabilities scoring systems
• Attack/exploits enumeration and modeling establishes an attacker’s perspective of the attack surface including exploit targets or TTP’s
• Risk and impact analysis provides qualitative and quantitative assessments of the business risk and impact along with mitigation strategy options
PASTA was designed by combining several threat modeling approaches to give organizations an attacker’s perspective of threats so that they can identify mitigation strategies that follow an asset-centric approach. While there are technical aspects included in this methodology, the inclusion of business relevant aspects changes it from a purely technical exercise into a process that requires the involvement of key organizational stakeholders.
TRIKE
Developed by Eleanor Saitta, Brenda Larcom, and Michael Eddington, version 1.0 of this threat model was published in 2005 as a way of providing organizations with a unified framework for security auditing from a risk management perspective. The intention of using this methodology was to enable communication between multiple stakeholders to describe security characteristics of a system or software from the high-level architecture to the low-level implementation details.
TRIKE follows a risk-based approach where organizations sequentially complete four models to determine the impact threats have to assets, operations, and functions:
• Implementation focuses on gathering information about the implementation. From previously documenting what operation(s) the system or software is intended to perform, the following assessments can be made:
• Identifying the actions that do not align within the scope of the intended actions for the system or software
• Examining the individual components and develop data flow diagrams for how they are interconnected
• Creating a workflow that illustrates the relationship between subjects, actions, triggers, and operations.
• Threat focuses on identifying the threats against the implementation model. By developing an attack graph for a specific component or against the entire system or software, weaknesses can be identified and subsequently mitigation strategies created.
• Risk focuses on understanding the risk factors that are in and out of scope for each components of the system or software. Risks identified can be assumed resulting in changing the prioritization of weaknesses and vulnerabilities documented during the threat model. It is important to note that this risk model is still considered experimental within the TRIKE methodology and is subject to change.
Under version 1.0, organizations may experience performance issues after reaching a certain threshold of actors, and assets are included in a single system assessment. Since the initial release, there have been subsequent versions of the methodology, both versions 1.5 and 2.0, which are only partially documented and are still currently experimental. Organizations must exercise caution when considering the use of the latter versions of this methodology as they have not been fully tested against real systems or software.
Threat Risk Matrix
From the threat modeling exercise, a formalized report should be created to document the security aspects of the system or software architecture including additional attributes that link the identified threat to a business risk mitigation strategy. Publishing a threat report helps to prioritize, manage, and align potential threats across the organization with communication to key stakeholders such as:
• designers who can use secure software engineering principles relating to technologies and functionality;
• developers who author systems or software following recommended mitigation strategies; and
• testers and auditors who can verify and validate that the application security components were built as designed.
As a supplement to the overall risk assessment report provided in the Templates section of this book, a dedicated threat and risk assessment (TRA) report can be included to illustrate how the assessed threats contribute to the overall business risk. Even though this additional report is included as part of the larger risk report, it should still contain sufficient information so that it can be used as a stand-alone report. At a minimum the TRA report, as provided in the Templates section of this book, should include:
• Executive summary: provides a high-level summary of the threat assessment and findings
• Overall risk statement: presents justification for the final risk score of each security principle specified in the assessment matrix
• Methodology: provides an explanation of how the threat modeling exercise was conducted
• Assumptions: identifies circumstances and outcomes taken for granted during the assessment
• Threat tree workflows: demonstrates how each threat can lead to business impact
• Threat assessment matrix: addresses, in sections, each security principle (ie, confidentiality, integrity, availability, etc.) with details about each individual threat including the:
• unique identifier for recognizing a specific threat
• name and description of the threat that was assessed
• risk score that was assigned to the threat
• description of countermeasures identified to mitigate the threat
• description of residual risk remaining after countermeasures are implemented
Threat Modeling: Next Steps
Organizations must acknowledge that over time, threats evolve resulting in changes to the business risk and impact. While countermeasures can be implemented to reduce an attack surface, it is important to remember that threats exist regardless of the mitigation strategies previously implemented and cannot be completely eliminated as a potential business risk impact.
Threat modeling should not be treated as a program that is executed as a one-time exercise. It must be performed as an iterative process that is capable of adapting to the evolving threat landscape, changes to systems and software designs, and shifting business requirements.
Summary
As part of an overall risk management strategy, threat modeling focuses specifically on security threats that have potential to affect their business assets, operations, and functions. By performing threat modeling, organizations will gain a better understanding of the threats they face so that more effective defense-in-depth strategies can be implemented.