CISSP Domain: Domain 1 – Security and Risk Management

CISSP Objective: 1.10 Understand and apply threat modeling concepts and methodologies

Focus: Threat Modeling, Threat Identification & Attack Analysis

Summary

CISSP Threat Modeling provides a structured approach to identifying threats, attack paths, trust boundaries, vulnerabilities, and potential business impact before they become security incidents. This Domain 1 pillar guide covers STRIDE, PASTA, DREAD, attack trees, misuse and abuse cases, attack surface analysis, threat actors, risk prioritization, cloud, supply-chain, and AI threat modeling from the risk-based perspective required for the CISSP exam.

Threat modeling is the structured process of identifying potential threats, understanding how attacks could occur, evaluating their potential impact, and determining appropriate security controls before those threats become incidents.

For CISSP candidates, threat modeling is not simply a software-development exercise or a list of frameworks such as STRIDE. It represents a broader risk-based way of thinking:

Threat modeling connects security governance, risk management, architecture, application security, vulnerability management, and secure design. Although candidates may encounter threat modeling concepts across several CISSP domains, its risk-management foundations make it particularly important when studying Domain 1: Security and Risk Management.

This pillar guide explains the threat-modeling concepts, methodologies, processes, attack analysis techniques, and exam-thinking principles CISSP candidates should understand.

1. What Is Threat Modeling?

Threat modeling is a systematic process for identifying and analyzing threats against systems, applications, business processes, architectures, and information assets.

A threat model attempts to answer fundamental questions:

1. What are we protecting?

2. Who or what could threaten it?

3. How could an attack occur?

4. What would the impact be?

5. What protections already exist?

6. What additional controls are needed?

7. What risk remains?

Threat modeling should ideally occur early in the lifecycle, when security weaknesses can often be addressed more efficiently.

It should also continue as systems, threats, architectures, dependencies, and business requirements change.

2. Why Threat Modeling Matters

Traditional security approaches sometimes discover weaknesses only after systems have been deployed.

Threat modeling attempts to identify security problems earlier.

It can help organizations:

• Identify threats systematically

• Discover architectural weaknesses

• Understand attack paths

• Prioritize security requirements

• Reduce attack surface

• Select appropriate controls

• Improve secure design

• Support risk assessments

• Focus security testing

• Evaluate trust boundaries

• Identify abuse cases

• Improve communication among stakeholders

The goal is not to predict every possible attack.

The goal is to make threat identification structured, repeatable, risk-based, and useful for decision-making.

3. Threat Modeling vs. Risk Assessment

Threat modeling and risk assessment are closely related but are not identical.

Threat Modeling

Primarily asks:

It emphasizes:

• Threat actors

• Attack paths

• Trust boundaries

• Assets

• Entry points

• Attack techniques

• Architectural weaknesses

Risk Assessment

Primarily asks:

It considers:

• Threats

• Vulnerabilities

• Likelihood

• Impact

• Existing controls

• Business consequences

• Residual risk

Threat modeling can therefore provide important input into risk assessment.

A useful relationship is:

Asset → Threat → Vulnerability → Attack Scenario → Impact → Risk → Control

4. Threat vs. Vulnerability vs. Risk

These concepts must be clearly distinguished.

Threat

Something capable of causing harm.

Examples:

• Cybercriminal

• Malicious insider

• Fire

• Malware

• Nation-state actor

Vulnerability

A weakness that can potentially be exploited or triggered.

Examples:

• Unpatched software

• Weak authentication

• Misconfigured cloud storage

• Excessive privileges

Risk

The potential for loss or harm when threats interact with vulnerabilities in ways that affect organizational objectives.

A simple conceptual relationship is:

5. Threat Events

A threat source and a threat event are also different.

A threat source is the entity or condition capable of causing harm.

A threat event is the actual occurrence or action that could result in harm.

For example:

Threat source: Malicious insider

Threat event: Unauthorized extraction of customer information

Making this distinction helps create more precise threat scenarios.

6. Assets

Threat modeling begins by understanding what needs protection.

Assets may include:

• Information

• Applications

• Databases

• Credentials

• Cryptographic keys

• Servers

• Networks

• Cloud services

• Business processes

• Intellectual property

• Reputation

• Physical facilities

• Human safety

Not all assets have equal value.

Threat analysis should therefore consider business importance, not simply technical components.

7. Asset Identification

Before asking what can go wrong, understand:

• What information exists?

• Where is it stored?

• Where does it flow?

• Who uses it?

• Which systems process it?

• What dependencies exist?

• What would happen if it were disclosed?

• What would happen if it were modified?

• What would happen if it became unavailable?

This connects threat modeling directly to the CIA Triad.

8. Threat Modeling and the CIA Triad

Threats can often be evaluated according to their potential impact on:

Confidentiality

Could information be disclosed to unauthorized parties?

Integrity

Could information or systems be improperly altered?

Availability

Could legitimate users lose access to systems or information?

Additional properties may include:

• Authenticity

• Accountability

• Privacy

• Non-repudiation

Thinking in terms of security objectives helps ensure that threat analysis is not limited to obvious intrusion scenarios.

9. Understand the System

A threat model requires an accurate understanding of the system being analyzed.

This can include:

• Components

• Applications

• Databases

• APIs

• Networks

• Users

• External systems

• Cloud services

• Authentication systems

• Administrative interfaces

• Data flows

• Third-party dependencies

An incomplete architecture model can produce an incomplete threat model.

10. Data Flow Diagrams

A Data Flow Diagram (DFD) is commonly used to visualize how information moves through a system.

A threat-modeling DFD may identify:

• External entities

• Processes

• Data stores

• Data flows

• Trust boundaries

DFDs help analysts understand where information enters, moves, changes, and leaves the environment.

They can reveal security questions that are difficult to identify from written documentation alone.

11. Trust Boundaries

A trust boundary exists where the level of trust or security context changes.

Examples include:

• Internet → corporate network

• User device → application

• Application → database

• Corporate network → cloud provider

• Standard user → privileged environment

• Third-party service → internal API

Crossing a trust boundary often requires additional security controls.

These may include:

• Authentication

• Authorization

• Encryption

• Validation

• Logging

• Segmentation

CISSP Exam Principle

Whenever data crosses a trust boundary, ask:

12. Entry Points

Entry points are interfaces through which users, systems, or attackers can interact with a system.

Examples include:

• Web interfaces

• APIs

• Login pages

• Network services

• Administrative interfaces

• File uploads

• Email

• Remote access

• Physical interfaces

Identifying entry points helps reveal the attack surface.

13. Attack Surface

The attack surface represents the collection of potential points where an attacker may attempt to enter, manipulate, extract information from, or otherwise interact with a system.

Attack surface can include:

• Open ports

• APIs

• User interfaces

• Accounts

• Administrative services

• Cloud resources

• Third-party integrations

• Remote access

• Software dependencies

A fundamental security objective is:

This may involve:

• Disabling unused services

• Removing unnecessary software

• Restricting administrative interfaces

• Eliminating unused accounts

• Limiting APIs

• Segmenting networks

• Applying least privilege

14. Threat Actors

Threat modeling should consider who or what might cause harm.

Threat actors can include:

Cybercriminals

Often financially motivated.

Nation-State Actors

May pursue espionage, disruption, intelligence, or strategic objectives.

Insiders

Employees, contractors, partners, or others with legitimate access.

Hacktivists

May be motivated by ideological or social objectives.

Competitors

May seek economic or strategic advantage.

Opportunistic Attackers

May target exposed systems without specifically selecting the organization beforehand.

Threats can also originate from nonmalicious sources such as:

• Human error

• System failure

• Natural disasters

• Supply-chain failure

15. Threat Actor Capability and Motivation

Not all threat actors pose equal risk.

Analysis may consider:

• Motivation

• Capability

• Resources

• Access

• Intent

• Opportunity

• Target preference

For example, a highly capable threat actor with no interest in a particular asset may represent less immediate risk than a moderately capable insider with direct access and strong motivation.

16. Attack Vectors

An attack vector is a path or method through which a threat can attempt compromise.

Examples include:

• Phishing

• Credential theft

• Exploitation of vulnerabilities

• Malicious attachments

• Web application attacks

• Supply-chain compromise

• Physical access

• Social engineering

• Misconfigured cloud services

• Stolen devices

Threat modeling identifies plausible vectors relevant to the specific environment.

17. Attack Paths

An attack path describes a sequence of steps through which an attacker may progress toward an objective.

For example:

Phishing

↓

Credential Theft

↓

Initial Access

↓

Privilege Escalation

↓

Lateral Movement

↓

Database Access

↓

Data Exfiltration

This approach helps organizations understand that serious incidents often result from multiple weaknesses chained together.

18. Threat Scenarios

A useful threat scenario connects:

Threat actor + Asset + Attack vector + Vulnerability + Potential impact

Example:

This scenario is more useful than simply listing:

It provides context for risk analysis and control selection.

19. STRIDE Threat Modeling

STRIDE is one of the best-known threat classification approaches.

The acronym represents:

S – Spoofing

T – Tampering

R – Repudiation

I – Information Disclosure

D – Denial of Service

E – Elevation of Privilege

CISSP candidates should understand what each category represents.

20. Spoofing

Spoofing involves pretending to be another user, system, service, or entity.

Examples:

• Stolen credentials

• Session impersonation

• Forged identity

• Service impersonation

Primary security concern: Authenticity / Authentication

Controls may include:

• MFA

• Strong authentication

• Certificates

• Secure session management

21. Tampering

Tampering involves unauthorized modification of information, software, configurations, or communications.

Examples:

• Modifying database records

• Altering software

• Changing configuration files

• Manipulating messages

Primary security concern: Integrity

Controls may include:

• Hashing

• Digital signatures

• Access control

• File integrity monitoring

• Change management

22. Repudiation

Repudiation concerns the ability of an individual or system to deny performing an action when sufficient evidence does not exist to establish accountability.

Examples:

• User denies approving a transaction.

• Administrator denies changing a configuration.

Primary concern: Accountability / Non-repudiation

Controls may include:

• Audit logging

• Digital signatures

• Time synchronization

• Secure audit trails

• Strong identity management

23. Information Disclosure

Information disclosure occurs when information is exposed to unauthorized entities.

Examples:

• Database leakage

• Exposed cloud storage

• Unencrypted communications

• Excessive permissions

Primary concern: Confidentiality

Controls may include:

• Encryption

• Access controls

• Data classification

• DLP

• Need to know

24. Denial of Service

Denial of service affects the ability of legitimate users to access systems or information.

Examples:

• Resource exhaustion

• Network flooding

• Application overload

• Dependency failure

Primary concern: Availability

Controls may include:

• Redundancy

• Rate limiting

• Capacity management

• DDoS protection

• Resilience

25. Elevation of Privilege

Elevation of privilege occurs when an attacker obtains permissions beyond those legitimately authorized.

Examples:

• Standard user becomes administrator

• Application gains system-level privileges

• Compromised account accesses privileged functions

Controls may include:

• Least privilege

• Privilege separation

• Secure configuration

• Patching

• PAM

• Access control

26. STRIDE and Security Objectives

A useful conceptual mapping is:

This mapping helps candidates understand STRIDE conceptually rather than merely memorizing the acronym.

27. PASTA

PASTA — Process for Attack Simulation and Threat Analysis is a risk-centric threat-modeling methodology.

It emphasizes understanding:

• Business objectives

• Technical scope

• Application decomposition

• Threats

• Vulnerabilities

• Attack scenarios

• Risk and impact

PASTA connects technical threat analysis with business risk.

A simplified conceptual sequence is:

Business objectives

↓

Technical scope

↓

Application decomposition

↓

Threat analysis

↓

Vulnerability analysis

↓

Attack modeling

↓

Risk and impact analysis

CISSP Perspective

PASTA is useful to recognize as a risk-oriented methodology, whereas STRIDE primarily provides categories for identifying threats.

28. DREAD

DREAD is historically associated with rating or prioritizing threats.

The acronym commonly represents:

• Damage Potential

• Reproducibility

• Exploitability

• Affected Users

• Discoverability

It can help illustrate factors considered when evaluating threats.

However, candidates should avoid assuming every organization uses DREAD or that it is the required approach to threat prioritization.

The broader CISSP lesson is:

29. Attack Trees

An attack tree represents an attacker's objective and the possible paths toward achieving it.

The root represents the attacker's goal.

Branches represent possible attack approaches.

For example:

Goal: Obtain confidential customer data

↓

Compromise user account

or

Exploit application

or

Compromise database

or

Steal backup

Each path can then be decomposed into additional steps.

Attack trees help analysts explore alternative attack strategies systematically.

30. Attack Trees vs. Attack Paths

These concepts are related.

An attack path generally describes a specific sequence toward compromise.

An attack tree represents multiple possible ways an attacker could achieve an objective.

Attack trees therefore help analysts explore alternative routes rather than focusing on only one scenario.

31. Misuse Cases

A traditional use case describes how a legitimate user interacts with a system to achieve an intended objective.

A misuse case describes how a malicious or unauthorized actor might abuse the system.

Example:

Use case: Customer resets password.

Misuse case: Attacker abuses password recovery to take over another user's account.

Thinking about misuse can reveal security requirements overlooked by normal functional design.

32. Abuse Cases

Abuse cases similarly examine how legitimate functionality might be intentionally misused.

Examples:

• Repeatedly submitting transactions to exploit business logic

• Using search functionality to enumerate users

• Uploading malicious files

• Manipulating password-reset workflows

This is particularly useful in application security and secure development.

33. Threat Libraries

Organizations may maintain threat libraries containing known threat patterns.

These can improve consistency and reduce the likelihood that common threats are overlooked.

Sources may include:

• Historical incidents

• Internal threat intelligence

• Industry knowledge

• Threat frameworks

• Vulnerability information

• Previous assessments

Threat libraries should support analysis rather than replace critical thinking.

34. MITRE ATT&CK and Threat Modeling

MITRE ATT&CK provides structured knowledge about adversary tactics and techniques.

It can support threat modeling by helping organizations understand:

• How attackers gain access

• How they execute actions

• How they establish persistence

• How they escalate privileges

• How they evade defenses

• How they discover environments

• How they move laterally

• How they collect or exfiltrate information

ATT&CK is particularly useful when analyzing realistic adversary behavior.

It should not be confused with a complete risk-management framework.

35. Threat Intelligence

Threat intelligence can improve threat models by adding information about:

• Active adversaries

• Common attack techniques

• Industry targeting

• Exploited vulnerabilities

• Malware campaigns

• Emerging threats

However, threat modeling should not focus exclusively on the latest threat intelligence.

Architecture weaknesses may remain important even when no active campaign currently targets them.

36. Vulnerability Analysis

Threat modeling often identifies situations where a threat could exploit a weakness.

Vulnerability information may come from:

• Vulnerability scanners

• Penetration tests

• Code reviews

• Configuration assessments

• Architecture reviews

• Threat intelligence

• Security testing

Threat modeling gives vulnerabilities context.

A vulnerability on an isolated low-value system may present different risk than the same weakness on an internet-facing critical system.

37. Threat Modeling vs. Vulnerability Assessment

A vulnerability assessment asks:

Threat modeling asks:

The two activities complement each other.

Neither completely replaces the other.

38. Threat Modeling vs. Penetration Testing

Penetration testing attempts to identify and exploit weaknesses under controlled conditions.

Threat modeling primarily analyzes potential threats and attack paths.

Threat modeling can occur before a system exists.

Penetration testing generally requires an implemented environment or component to test.

A strong security lifecycle can use both.

39. Threat Modeling and Secure Design

Threat modeling is most valuable when performed early.

During design, teams can change:

• Architecture

• Trust boundaries

• Authentication mechanisms

• Data flows

• Interfaces

• Privileges

• Dependencies

After deployment, correcting these issues may become significantly more expensive.

This supports the principle:

40. Threat Modeling in the SDLC

Threat modeling can be integrated throughout the system development lifecycle.

Requirements

Identify security objectives and critical assets.

Design

Analyze architecture, trust boundaries, data flows, and threats.

Development

Implement security requirements and mitigations.

Testing

Validate controls and test identified attack scenarios.

Deployment

Verify secure configuration and assumptions.

Operations

Update the model as threats and systems change.

Retirement

Address data disposal, credentials, dependencies, and decommissioning risk.

Threat modeling should therefore be treated as a lifecycle activity rather than a one-time diagram.

41. Security Requirements from Threat Models

A major output of threat modeling should be actionable security requirements.

For example:

Threat: Credential theft could allow account takeover.

Security requirements:

• Require MFA.

• Implement rate limiting.

• Monitor anomalous authentication.

• Protect session tokens.

• Provide secure account recovery.

Threat models that generate no decisions or requirements provide limited value.

42. Selecting Controls

Once threats are understood, controls can be selected.

Controls may:

• Prevent

• Detect

• Correct

• Deter

• Recover

• Compensate

Selection should consider:

• Risk

• Cost

• Effectiveness

• Business requirements

• Architecture

• Legal obligations

• Operational impact

The strongest technical control is not automatically the best business control.

43. Mitigation

Mitigation reduces the likelihood or impact of a threat scenario.

Examples include:

• MFA

• Encryption

• Segmentation

• Input validation

• Secure coding

• Logging

• Redundancy

• Least privilege

After mitigation, residual risk remains.

That residual risk should be evaluated through the organization's risk-management process.

44. Threat Prioritization

Organizations rarely have unlimited resources.

Threats must therefore be prioritized.

Factors can include:

• Likelihood

• Impact

• Asset criticality

• Threat capability

• Exposure

• Existing controls

• Exploitability

• Business consequences

Prioritization should focus resources on the threats creating the greatest meaningful risk.

45. Likelihood

Likelihood represents the probability or possibility that a threat scenario will occur.

Factors may include:

• Threat capability

• Motivation

• Exposure

• Vulnerability

• Existing controls

• Historical events

• Threat intelligence

Likelihood does not need to be mathematically precise in every assessment.

Organizations may use qualitative ratings such as:

• Low

• Medium

• High

46. Impact

Impact represents the potential consequences if a threat scenario occurs.

Impact may include:

• Financial loss

• Operational disruption

• Safety consequences

• Regulatory penalties

• Privacy harm

• Reputation damage

• Loss of intellectual property

• Contractual consequences

CISSP candidates should avoid viewing impact only through a technical lens.

The ultimate concern is often business impact.

47. Qualitative Threat Prioritization

Organizations may prioritize threats using categories such as:

Likelihood: High

Impact: High

Overall Risk: High

Qualitative analysis is useful when exact numerical information is unavailable or unnecessary.

48. Quantitative Analysis

Some organizations may use quantitative methods to estimate financial or probabilistic impact.

Threat-model outputs can contribute to calculations involving:

• Loss magnitude

• Event frequency

• Expected loss

• Control cost

However, threat modeling itself should not be confused with quantitative risk analysis.

49. Threat Modeling and Risk Treatment

After risks are evaluated, organizations may:

Avoid

Stop the risky activity.

Mitigate

Implement controls to reduce risk.

Transfer or Share

Shift or distribute portions of the risk through mechanisms such as contracts or insurance.

Accept

Formally acknowledge the remaining risk when authorized.

Threat modeling supports these decisions by making attack scenarios and potential consequences clearer.

50. Residual Risk

Controls rarely eliminate all risk.

The risk remaining after controls are implemented is residual risk.

Security teams can recommend controls and communicate residual risk.

Appropriate business or risk owners should make acceptance decisions according to organizational authority.

CISSP Principle

51. Threat Modeling and Defense in Depth

Threat models can identify places where multiple complementary controls are appropriate.

For example:

Threat: Stolen administrator credentials.

Potential controls:

• MFA

• PAM

• Network restrictions

• Least privilege

• Session monitoring

• Behavioral analytics

• Audit logging

If one layer fails, another may still reduce the likelihood or impact of compromise.

This is defense in depth.

52. Threat Modeling and Zero Trust

Zero Trust concepts complement threat modeling.

Instead of assuming that internal entities are trustworthy, analysts ask:

• Who is requesting access?

• What device is being used?

• What resource is requested?

• What context exists?

• What privileges are necessary?

• What happens if the identity is compromised?

Threat modeling can expose assumptions based on implicit trust.

Zero Trust seeks to reduce those assumptions through explicit verification and limited access.

53. Insider Threat Modeling

Not every threat originates outside the organization.

Insider threat scenarios may involve:

Malicious Insiders

Intentionally misuse authorized access.

Negligent Insiders

Create risk through mistakes or failure to follow requirements.

Compromised Insiders

Legitimate accounts are taken over by external attackers.

Controls can include:

• Least privilege

• Separation of duties

• Monitoring

• Data loss prevention

• Privileged access management

• Security awareness

• Access reviews

54. Third-Party Threat Modeling

Modern architectures depend heavily on external services.

Threat models should consider:

• Cloud providers

• SaaS services

• Vendors

• APIs

• Contractors

• Managed service providers

• Software suppliers

Questions include:

• What data does the third party access?

• What happens if the provider is compromised?

• What dependencies exist?

• What access is granted?

• How is trust established?

• How would an incident affect the organization?

55. Supply Chain Threat Modeling

Supply-chain attacks can compromise trusted products or services before they reach the organization.

Threat scenarios may involve:

• Malicious software updates

• Compromised dependencies

• Hardware manipulation

• Vendor compromise

• Stolen signing keys

• Open-source package compromise

Organizations should identify critical dependencies and evaluate their associated risk.

56. Cloud Threat Modeling

Cloud architectures create unique trust boundaries and dependencies.

Threat modeling should consider:

• Shared responsibility

• Identity and access

• APIs

• Misconfiguration

• Data exposure

• Tenant isolation

• Management interfaces

• Encryption

• Logging

• Provider dependencies

The fundamental process remains unchanged:

Assets → Architecture → Trust Boundaries → Threats → Risk → Controls

57. AI Threat Modeling

Artificial intelligence creates additional attack surfaces and threat scenarios.

Potential AI-related threats include:

• Prompt injection

• Training-data poisoning

• Sensitive information disclosure

• Model theft

• Unauthorized model access

• Manipulated outputs

• Insecure AI integrations

• Third-party model compromise

• Excessive agency

• Supply-chain risk

Threat modeling for AI should consider the entire ecosystem:

Data → Model → Application → User → Plugins/Tools → External Services → Outputs

58. AI Data Threats

AI systems may process:

• Personal information

• Intellectual property

• Credentials

• Business-sensitive information

• Proprietary datasets

Threat models should therefore evaluate confidentiality, integrity, privacy, retention, and authorization throughout the AI data lifecycle.

59. Human Threats and Social Engineering

Threat modeling should not be restricted to technology.

Attackers frequently target people.

Threat scenarios may involve:

• Phishing

• Pretexting

• Impersonation

• Business email compromise

• Help-desk manipulation

• Tailgating

Human processes can represent important trust boundaries and attack paths.

60. Physical Threats

Threat models may also include physical events.

Examples:

• Unauthorized facility access

• Device theft

• Fire

• Flood

• Power loss

• Equipment damage

• Environmental failure

A comprehensive threat model considers relevant human, technical, environmental, and physical threats.

61. Threat Modeling Documentation

A useful threat model may document:

• Scope

• Assets

• Architecture

• Data flows

• Trust boundaries

• Threat actors

• Threat scenarios

• Vulnerabilities

• Existing controls

• Risk ratings

• Recommended controls

• Residual risk

• Owners

• Review dates

Documentation supports repeatability and future reassessment.

62. Threat Model Ownership

Threat modeling is rarely the responsibility of one person.

Participants may include:

• Security architects

• Developers

• System architects

• Risk professionals

• Business owners

• Operations

• Privacy professionals

• Cloud teams

• Product owners

Cross-functional participation improves the quality of assumptions and threat identification.

63. When Should Threat Models Be Updated?

Threat models should be revisited when meaningful changes occur.

Triggers may include:

• Architecture changes

• New interfaces

• New data types

• New vendors

• Cloud migration

• Major software changes

• New authentication mechanisms

• Significant vulnerabilities

• New threat intelligence

• Security incidents

• AI integration

• Changes in business requirements

Threat models become less useful if they no longer represent the actual environment.

64. Common CISSP Threat Modeling Traps

Trap: Threat modeling is only for software developers

False. Threat modeling can apply to applications, infrastructure, business processes, cloud systems, third parties, and architectures.

Trap: A threat and vulnerability are the same

False. A threat can cause harm; a vulnerability is a weakness.

Trap: STRIDE calculates organizational risk

Not by itself. STRIDE primarily helps categorize threats.

Trap: DREAD and STRIDE perform the same function

No. STRIDE identifies categories of threats, while DREAD has historically been used as a threat-rating approach.

Trap: Threat modeling replaces penetration testing

False. They provide different forms of analysis.

Trap: Threat modeling replaces risk assessment

False. Threat modeling provides valuable input into broader risk assessment.

Trap: Every identified threat requires the strongest possible control

False. Controls should be proportional to risk and business requirements.

Trap: Only external attackers should be modeled

False. Insiders, human error, third parties, environmental events, and supply-chain threats may also matter.

Trap: Threat modeling happens once during design

False. It should evolve with the system and threat environment.

65. High-Yield CISSP Threat Modeling Concepts

Candidates should be comfortable with:

• Threat

• Threat source

• Threat event

• Vulnerability

• Risk

• Asset

• Threat actor

• Attack vector

• Attack surface

• Attack path

• Threat scenario

• Trust boundary

• Data flow diagram

• STRIDE

• Spoofing

• Tampering

• Repudiation

• Information disclosure

• Denial of service

• Elevation of privilege

• PASTA

• DREAD

• Attack trees

• Misuse cases

• Abuse cases

• Threat intelligence

• Vulnerability analysis

• Secure by design

• Threat prioritization

• Likelihood

• Impact

• Risk treatment

• Residual risk

• Defense in depth

• Zero Trust

• Insider threats

• Third-party threats

• Supply-chain threats

• Cloud threats

• AI threats

66. Threat Modeling Topic Cluster

This pillar should become the central internal-link hub for deeper GoCyberNinja threat-modeling content.

Threat Modeling Foundations

• What Is Threat Modeling?

• Threat vs. Vulnerability vs. Risk

• Threat Sources and Threat Events

• Threat Actors

• Attack Vectors

• Attack Surface Analysis

• Attack Paths

• Trust Boundaries

Threat Modeling Methodologies

• STRIDE Threat Modeling

• PASTA Threat Modeling

• DREAD Threat Rating

• Threat Modeling Framework Comparison

Attack Analysis

• Attack Trees

• Attack Paths

• Misuse Cases

• Abuse Cases

• Threat Scenarios

• MITRE ATT&CK for CISSP

Secure Architecture

• Defense in Depth

• Zero Trust Architecture

• Secure by Design

• Secure by Default

• Least Privilege

• Attack Surface Reduction

Risk Integration

• Risk Management

• Qualitative Risk Analysis

• Quantitative Risk Analysis

• Risk Treatment

• Residual Risk

• Risk Register

Modern Threat Modeling

• Cloud Threat Modeling

• Third-Party Threat Modeling

• Supply Chain Threat Modeling

• Insider Threat Modeling

• AI Threat Modeling

67. Quick CISSP Knowledge Check

1. What should normally occur before identifying specific threats against a system?

Answer: Understand the system, its business purpose, assets, architecture, data flows, and trust boundaries.

2. Which STRIDE category primarily addresses unauthorized modification?

Answer: Tampering.

3. Which STRIDE category is primarily associated with confidentiality?

Answer: Information Disclosure.

4. An attacker obtains administrative privileges from a normal user account. Which STRIDE category applies?

Answer: Elevation of Privilege.

5. What is a trust boundary?

Answer: A point where the level of trust or security context changes and where additional verification or protection may be necessary.

6. What is the primary difference between STRIDE and PASTA?

Answer: STRIDE primarily categorizes types of threats, while PASTA provides a broader risk-centric process connecting business objectives, technical analysis, attack scenarios, and risk.

7. Does threat modeling eliminate the need for penetration testing?

Answer: No. Threat modeling identifies potential threats and attack paths, while penetration testing evaluates weaknesses through controlled testing. They complement each other.

8. Who should accept significant residual risk identified through threat modeling?

Answer: The appropriately authorized business or risk owner.

68. Exam Thinking: The Threat Modeling Decision Chain

For CISSP questions involving threats, use this sequence:

Business Objective

↓

Critical Asset

↓

Architecture & Data Flow

↓

Trust Boundaries

↓

Threat Source / Threat Actor

↓

Threat Scenario

↓

Vulnerability

↓

Likelihood & Impact

↓

Risk

↓

Security Control

↓

Residual Risk

↓

Risk Owner Decision

This sequence prevents one of the most common exam mistakes:

69. STRIDE Quick Memory Map

For exam review:

S — Spoofing → Authentication

T — Tampering → Integrity

R — Repudiation → Accountability / Non-repudiation

I — Information Disclosure → Confidentiality

D — Denial of Service → Availability

E — Elevation of Privilege → Authorization

Do not memorize the letters alone.

Understand which security objective each threat attempts to violate.

70. The CISSP Threat Modeling Mindset

A CISSP approaches threat modeling from both technical and managerial perspectives.

The objective is not simply to produce a long list of attacks.

The objective is to determine:

• What matters to the organization

• What can threaten it

• How compromise could occur

• What the consequences would be

• Which risks deserve priority

• Which controls are appropriate

• Who owns the remaining risk

A technically interesting threat with negligible business impact may deserve less attention than a simple attack capable of disrupting a critical business process.

That distinction is central to CISSP thinking.

Final Takeaway

Threat modeling transforms security from a reactive activity into a structured process of anticipating how systems and business processes could fail or be attacked.

A strong threat model begins with business objectives and assets, examines architecture and data flows, identifies trust boundaries and attack surfaces, evaluates credible threat actors and attack paths, and converts those findings into prioritized security requirements.

Frameworks such as STRIDE, PASTA, DREAD, attack trees, misuse cases, and adversary knowledge sources such as MITRE

ATT&CK provide different ways to structure that analysis. They are tools—not the objective themselves.

The CISSP objective is broader:

Remember the core sequence:

Asset → Threat → Vulnerability → Attack Scenario → Impact → Risk → Control → Residual Risk

Once that relationship is clear, threat-modeling questions become much easier to reason through—and the same thinking strengthens your understanding of risk management, security architecture, application security, cloud security, supply-chain security, and AI security across the CISSP exam.

Related CISSP Topics

Continue your study with: