(from Brook Schoenfield’s Threat Modelling Methods)
Threat modelling is an analysis technique often employed to identify the security needs of a system. As such, threat modelling is often undertaken while designing software and digital systems; threat modelling must be considered a foundational technique underlying system security, and in particular, secure design. Threat modelling is a key technique for system security’s associated development processes and strategies, the Security Development Life cycle (SDL) also called the Secure Software Development Lifecycle (S-SDLC).
Sometimes, systems are deployed without a threat model. In these cases, system stakeholders may choose to build a threat model post-release to identify any security weaknesses or un/under mitigated risks that are already in service.
In either case, the threat model’s output offers software makers a set of implementable improvements designed to improve the overall attack resilience and compromise survivability of the target system and its stakeholders.
Threat modelling can be defined as, “a technique to identify the attacks a system must resist and the defences that will bring the system to a desired defensive state[1].”
The definition highlights a few key points. First, threat modelling is not a design or an architecture, it is an analysis technique. Next, its purpose is to identify attacks and defences. Third, and this is key, the defences bring the system to its “desired defensive state.” That is, the object is not to bring the system to an ivory tower security perfection (which, of course, doesn’t actually exist in the real world, anyway).
In order to complete a threat model, one must first understand what defensive state a system’s stakeholders expect the system to achieve. To put that in a different way, a priori to analysing the attacks and specifying the defences, the analyst must understand against what the system must defend and to what level—what is commonly termed its ‘security posture.’… From the understanding of stakeholder risk tolerance, one may then derive the security posture of a system, its “desired defensive state”—that is, the appropriate defences that will resist those attacks against which the system and its stakeholders will defend.”
The primary output of a threat model undertaken as a software design activity must be a set of defences that taken together provide sufficient protection to the needs of the system’s stakeholders. Since risk tolerances and relevant threats are organizationally and system dependent, there is no “perfect” set of defences for every situation. Brook will base defence findings on industry best practices, as given by publications such as National Institute of Standards and Technology (NIST) security publications and/or customer standards and policies, as required.
Most threat model methodologies answer one or more of the following questions:
Job 1 for engineering-based security as described in NIST SP 800-160, is to determine what types of "assets" the organization desires to protect.
An asset is an item of value. There are many different types of assets. Assets are broadly categorized as either tangible or intangible. Tangible assets include physical items, such as hardware, computing platforms, other technology components, and humans. Intangible assets include firmware, software, capabilities, functions, data, services, trademarks, intellectual property, copyrights, patents, image, or reputation.
Within asset categories, assets can be further identified and described in terms of common asset classes.
NIST SP 800-160v1r1 Engineering Trustworthy Secure Systems November 2022 → 3.4 The Concept of Assets
Asset Class 1: Material Resources and Infrastructure
This asset class includes physical property (e.g., buildings, facilities, equipment) and physical resources (e.g., water, fuel). It also includes the physical and organizational structures/facilities (i.e., infrastructure) needed for an activity or the operation of an enterprise or society. An infrastructure may be comprised of assets in other classes.
Asset Class 2: System Capability
This asset class is the set of capabilities or services provided by the system. System capability is determined by (1) the nature of the system (e.g., entertainment, vehicular, medical, financial, industrial, or recreational) and (2) the use of the system to achieve mission or business objectives.
Asset Class 3: Human Resources
This asset class includes personnel who are part of the system and are directly or indirectly involved with or affected by the system. The consequences of loss associated with the system may significantly change the importance of this asset class.
Asset Class 4: Intellectual Property
This asset class includes technology, trade secrets, recipes, and other items that constitute an advantage over competitors. The advantage is domain-specific and may be referred to as a technological advantage, competitive advantage, or combative advantage.
Asset Class 5: Data and Information
This asset class includes data, information (aggregations of data), and all encodings and representations of data and information (e.g., digital, optical, audio, visual).
Asset Class 6: Derivative Non-Tangibles
This asset class is comprised of derivative, non-tangible assets, such as image, reputation, and trust. These assets are defined, assessed, and affected, positively and negatively, by the success or failure to provide adequate protection for assets in the other classes.