Introduction
The threat landscape is in a constant state of evolution in line with dependencies placed on complex technology infrastructures. Building—and sustaining—an effective defense-in-depth strategy to manage threats 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 the potential to affect their business assets, operations, and functions.
Why Threat Modeling?
In relation to information security, a threat is considered any intentional (e.g., criminal activity) or accidental (e.g., natural disaster) course of action with potential to adversely impact people, processes, or technology. Like business risk, threats can be classified according to their types, such as:
• Physical damage (e.g., fire, water);
• Service impact (e.g., electrical, telecommunication);
• Information compromise (e.g., eavesdropping, media theft);
• Technical failures (e.g., software defects, performance and capacity); or
• Operational compromise (e.g., abuse of rights, denial of service [DoS])
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. For example, the Structured Threat Information Expression (STIX) framework, illustrated in Figure F.1, is designed to improve the overall management and understanding of threat information so that organizations can better develop mitigation strategies and countermeasures that are meaningful, adaptable, extensible, and automated.
Figure F.1 Structured threat information expression (STIX)framework.
Within the STIX framework, organizations can utilize a common language for representing the following nine constructs of how threats work:
• Observables are the resulting outputs that might be or have been seen across an organization (i.e., service degradation).
• Indicators describe one or more observable patterns that, combined with other relevant and contextual information, represent artifacts and/or behaviors of interest (i.e., file hashes).
• 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) describe the attack patterns, tools, exploits, infrastructure, victim targeting, and other methods used by the adversary or attacker.
• Exploit targets are 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 occurrences where threat actors perform a set of TTPs or incidents that could be experienced throughout an organization.
• Threat actors identify and/or 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. Alternatively, by completing a threat modeling exercise organizations can get a better understanding of threats targeting them and be better prepared to prioritize which strategies are best suited for reducing their overall 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 an overall risk management program—allows organizations to meet the requirements for maintaining security properties of confidentiality, integrity, and availability (CIA), along with authorization, authentication and non-repudiation. The STRIDE acronym is formed using the first letter of the following six threat categories:
• Spoofing is the unauthorized use of authentication information, such as a username and password, to gain access into objects or assets.
• Tampering involves the malicious and unauthorized (1) alteration of data communication between subjects such as business workflows or (2) modification of 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. Non-repudiation 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.
• Information disclosure involves exposure of information to subjects that are, under normal circumstances, not authorized to gain access, such as an intruder reading data communications between two systems.
• 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 and functions become much more inter-related with complex technologies, it is crucial that organizations do not continue to manage threats on a case-by-case basis as they are identified. Instead of managing threats through specific technology functionalities, organizations should manage their attack surface with the goal of reducing a much larger number of threats without getting into the specifics.
Figure F.2 Threat tree workflow.
To manage threats from a risk-based approach, organizations should focus on assessing threats as part of their overall risk management program. The relationship between threats and business risk is illustrated in Figure F.2, whereby threats are represented as direct contributors and drivers for impact to business operations and functions.
Threat Modeling Methodologies
Threat modeling is the process used to identify objectives and vulnerabilities, quantify exposure, and develop strategies to mitigate and countermeasure threats. Through the creation of a structured representation of collected information, organizations are better informed and can prioritize 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; each follows a different approach. 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 organizations can determine which one aligns best to their specific needs. While not all threat models are 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 organizations to systematically identify and prioritize threats that have the greatest potential impact on 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 dataflow and workflow diagrams to illustrate the relationships and connectivity between systems and objects
• Decompose the application: Provides further details about 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 organizations when it comes to reducing the attack surface and improving security of 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.
PASTA (Process for Attack Simulation and Threat Analysis)
Developed by Marco Morana and Tony “UV”, this is a threat model that is platform agnostic and can be applied to most systems and 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 a 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 TTPs
• 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 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 the TRIKE 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 should assets, operations, and functions:
• Requirements focuses on obtaining an understanding of the target system or software, including the intended operations, all subject interactions, the actions that trigger what functionality, and rules that constrain actions.
• 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 illustrating 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 the understanding the risk factors that are in and out of scope for each component 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 that 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; or
• 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 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 demonstrating how each threat can lead to business impact
• Threat assessment matrix addresses, in sections, each security principle (i.e., 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 (entirely) eliminated as a business risk.
Threat modeling should not be treated as a program that is executed as a one-time exercise. It must be performed as an iterative and adaptable process that is constantly evolving alongside the 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 more effective defense-in-depth strategies can be implemented.