Skip to content
FR

Threat Modeling, Supply Chain Security and Awareness

Step 7 of 38

CISSP Threat Modeling, Supply Chain Risk and Security Awareness

Introduction

This lesson closes Domain 1, Security and Risk Management (16% of the exam, ISC2 exam outline effective 15 April 2024). Building on business continuity and risk management, CISSP threat modeling and supply chain security turn identified risks into practical controls. Here you learn three practices that feed and support that risk work: threat modeling (finding what can go wrong with a system before attackers do), supply chain risk management (controlling the risk that comes from suppliers, hardware, and software you did not build), and security awareness, education, and training (making people part of the control set).

Use the following scenarios to practice objectives 1.10–1.12; they are original examples, not predictions of actual exam questions. Practice classifying threats in a data flow, selecting contractual and technical supplier controls, and measuring whether a learning program improves behavior. Always think like a manager: identify the risk, choose the control that fits the business, and make sure the decision is documented and measurable.

Outline check, 27 October 2026: the 2024 outline remains current; ISC2 has announced a new outline effective 15 April 2027.

Learning objectives

After this lesson you can:

  1. Explain the purpose, timing, and steps of threat modeling.
  2. Apply STRIDE, PASTA, DREAD, and other methods to a scenario and choose the one that fits.
  3. Use data flow diagrams and trust boundaries to find threats and map them to controls.
  4. Describe supply chain risks and the controls used to manage suppliers, hardware, software, and services.
  5. Explain software bills of materials (SBOMs), hardware trust, and supplier assessment.
  6. Design security awareness, education, and training programs for different audiences.
  7. Measure training effectiveness and update material for emerging technology and threats.

1. Threat modeling

1.1 What it is and why it matters

Threat modeling is a structured way to identify threats to a system, rank them, and decide how to address them. Early analysis can avoid expensive redesign and reduce exposure after release; exact savings depend on the system. It also supports risk management by supplying the "threat" and "vulnerability" inputs to risk assessment.

A typical process answers four questions:

  1. What are we building? (assets, architecture, data flows, trust boundaries)
  2. What can go wrong? (threats, attackers, abuse cases)
  3. What are we going to do about it? (mitigate, transfer, avoid, accept)
  4. Did we do a good job? (validation, testing, review)

Threat models are living documents. Revisit them when the architecture changes, new integrations appear, or new attack techniques emerge.

1.2 Perspectives

  • Attacker-centric: starts from the adversary's goals, skills, and methods (used in PASTA and attack trees).
  • Asset-centric: starts from what is valuable and asks how it could be harmed.
  • Software/system-centric: starts from the design (components, data flows) and asks what can fail at each point (used in STRIDE).

1.3 Data flow diagrams and trust boundaries

A data flow diagram (DFD) shows external entities, processes, data stores, and data flows. A trust boundary is a line where the level of trust changes: Internet to DMZ, a browser to a web server, one tenant to another, a user process to the kernel. Trust-boundary crossings deserve explicit review, but components, internal flows, data stores and privileged insiders also create threats. Model the architecture and assumptions before prioritizing review by business impact.

1.4 STRIDE

STRIDE was created at Microsoft and categorizes threats. Each category violates a security property:

Letter Threat Property violated Example Typical controls
S Spoofing Authentication Stolen session token used to impersonate a customer Strong authentication, MFA, certificates
T Tampering Integrity Changing the price field in a request Server-side authorization and validation; authenticated integrity with MACs/signatures; access control
R Repudiation Nonrepudiation / accountability Administrator denies deleting a record Audit logs, digital signatures, time sync
I Information disclosure Confidentiality Verbose error message exposes a database path Encryption, least privilege, error handling
D Denial of service Availability Flooding an API with requests Rate limiting, redundancy, capacity planning
E Elevation of privilege Authorization A normal user reaches an admin function Least privilege, authorization checks, sandboxing

Exam tip: map the symptom to the property violated. "Someone claims they never placed the order" is repudiation; "an attacker changed the amount in transit" is tampering; "a regular user opened the admin console" is elevation of privilege.

1.5 PASTA

The Process for Attack Simulation and Threat Analysis (PASTA) is a seven-stage, risk-centric, attacker-focused method:

  1. Define business objectives.
  2. Define the technical scope.
  3. Decompose the application (architecture, data flows).
  4. Analyze threats (threat intelligence, attacker profiles).
  5. Analyze vulnerabilities and weaknesses.
  6. Model attacks (attack trees, simulation).
  7. Analyze risk and impact and define countermeasures.

PASTA is chosen when the business wants to tie threats to business impact and use real threat intelligence. STRIDE is chosen when developers need a simple, repeatable checklist applied to a design.

1.6 Other methods you should recognize

Method Key idea
DREAD Ranks threats by Damage, Reproducibility, Exploitability, Affected users, Discoverability. A subjective scoring aid; define scales and calibrate reviewers. The official outline does not promise a named method on any exam.
Attack trees A goal at the root and branches of ways to achieve it, with costs or probabilities.
VAST Scales threat modeling across agile teams and enterprises using application and operational models.
Trike Risk-based approach built around requirements and acceptable risk per actor.
LINDDUN Privacy threat categories: Linking, Identifying, Non-repudiation, Detecting, Data disclosure, Unawareness/Unintervenability, Non-compliance.
MITRE ATT&CK A knowledge base of adversary tactics and techniques used to map detections and test coverage; it is not a modeling process by itself.
CAPEC / CWE Catalogs of attack patterns and weakness types.

In LINDDUN, strong attribution can itself threaten privacy; in STRIDE, evidence supporting accountability mitigates repudiation. Balance audit needs with minimization, access and retention rules.

1.7 Worked example: STRIDE on a mobile payment feature

Scenario. A bank adds a "pay a friend" feature. The mobile app sends a payment request over TLS to an API gateway; the gateway calls a payment service, which writes to a ledger database and sends a notification through a third-party messaging provider.

Step 1: Draw the DFD. Entities: customer, messaging provider. Processes: mobile app, API gateway, payment service. Store: ledger database. Trust boundaries: the Internet between the app and the gateway, the internal network boundary to the payment service, and the boundary to the external provider.

Step 2: Apply STRIDE to the flows that cross boundaries.

  • App to gateway: Spoofing (stolen token), Tampering (modified amount, mitigated by TLS plus server-side validation), Repudiation (customer denies the payment).
  • Payment service to ledger: Tampering (SQL injection), Elevation of privilege (service account has database administrator rights).
  • Payment service to messaging provider: Information disclosure (payment details in message text), Denial of service (provider outage delays confirmations).

Step 3: Choose mitigations. MFA and session protections for spoofing; server-side authorization of payer, payee and amount, replay protection and idempotency for tampering and duplicate requests; tamper-resistant identity-linked logs for repudiation; parameterized queries and a least-privilege database account; masked content in notifications and a queue with retry for the provider.

Step 4: Record and validate. Each threat gets an owner, a mitigation, and a test case. Residual risks, such as reliance on the messaging provider, go to the risk register.

Why it works. Starting from the boundaries focused the analysis on the dangerous flows. Choosing only "encrypt everything" would address disclosure and tampering in transit but ignore repudiation, privilege, and availability.

2. Supply chain risk management

2.1 Why supply chains are a security problem

Modern organizations rely on cloud providers, managed service providers, software libraries, hardware components, and logistics. A weakness at a supplier becomes your weakness. Well-known patterns include compromised software updates, malicious open-source packages, tampered or counterfeit hardware, a breached managed service provider with access to many clients, and a supplier that fails financially or stops supporting a product.

Apply these practices throughout the secure software development lifecycle, including dependency selection, build provenance and update delivery.

2.2 Risk areas

Area Examples of risk Typical control
Software Vulnerable or malicious libraries, unsigned updates SBOM, software composition analysis, code signing, verified sources
Hardware Counterfeit parts, implanted components, firmware tampering Trusted suppliers, tamper-evident packaging, hardware root of trust, inspection
Services Cloud or MSP breach, weak segregation, outage Due diligence, contracts, monitoring, exit plans
Logistics Interception in transit, delayed delivery Chain of custody, secure shipping, multiple sources
Financial/geopolitical Supplier insolvency, sanctions, export limits Alternate suppliers, escrow, contract clauses

2.3 Supplier assessment and selection

A defensible process includes:

  1. Classify suppliers by criticality and data access (a stationery vendor differs from a payroll processor).
  2. Due diligence before contracting: security questionnaires, independent reports (SOC 2, ISO/IEC 27001 certification), penetration test summaries, financial health, and references.
  3. Contract requirements: security and privacy obligations, breach notification windows, subcontractor controls (fourth parties), the right to audit, data return and destruction at exit, liability and insurance, and service-level agreements.
  4. Onboarding with least privilege and separate environments.
  5. Ongoing monitoring: periodic reassessment, performance reviews, news and threat intelligence about the supplier, and testing continuity arrangements.
  6. Offboarding: revoke access, return data, apply retention/legal holds and verify deletion where permitted. Cover backups and subprocessors; obtain evidence of agreed deletion and remaining retention limits.

Standards such as NIST SP 800-161 (cybersecurity supply chain risk management) and ISO/IEC 27036 (supplier relationships) provide structures.

2.4 Service requirements

Security requirements should be written as measurable service requirements: availability percentage, recovery time, incident response time, patch timelines, encryption of data at rest and in transit, logging access for the customer, and data location. Include penalties or remedies for failure and termination rights. Differentiate SLAs (customer–provider), operational-level agreements (internal), and underpinning contracts (provider–subcontractor).

2.5 Hardware trust

  • Trusted foundry and trusted supplier programs reduce counterfeit and implant risk.
  • A hardware root of trust anchors security functions. Secure Boot verifies approved boot signatures/policy and can prevent unapproved code loading; Measured Boot records measurements for later evaluation or attestation rather than blocking execution by itself.
  • Tamper-evident seals, inspection, and supply chain provenance detect interference in transit.
  • Physically unclonable functions (PUFs) use manufacturing variation to support device identity or key derivation, helping detect substitution. Validate implementation and lifecycle assumptions: “unclonable” is not a guarantee against modeling or physical attacks.
  • Buy through approved, verified channels and check provenance; authorization and seals reduce risk but cannot prove the absence of malicious hardware.

2.6 Software bills of materials

A software bill of materials (SBOM) is a formal, machine-readable inventory of the components and dependencies in a software product, with versions and suppliers. Common formats are SPDX and CycloneDX. A current, release-linked SBOM can speed identification of products containing a vulnerable component. It is an inventory, not proof that a product is exploitable or free of malicious code; completeness, transitive dependencies and runtime configuration matter. Requiring an SBOM from vendors, and generating one for software you build, supports vulnerability management, license compliance, and incident response. Pair it with software composition analysis and Vulnerability Exploitability eXchange (VEX) statements describing a specific product/version and vulnerability status: affected, not affected, fixed or under investigation. Check issuer, timestamp, scope and justification; a vendor assertion is evidence to assess, not a blanket exemption from mitigation.

Signed updates and attestations help establish artifact origin and integrity when their trust chain is verified; even correctly signed software can be compromised. Check build provenance, update channels and deployed behavior alongside the SBOM.

2.7 Worked example: responding to a supplier security event

Scenario. A hospital group uses a cloud-based radiology viewer. The vendor notifies customers that a third-party component in its product has a critical vulnerability that is being exploited. The contract requires 72-hour notification and quarterly vulnerability reporting, and gives the hospital the right to audit.

Step 1: Establish exposure. Match the deployed product/version to its current SBOM and vendor advisory/VEX. The SBOM can show component presence; reachability and exploitability require configuration evidence, analysis or testing. Check your own logs for indicators of compromise.

Step 2: Contain. Coordinate with clinical operations and incident responders, restrict unneeded interfaces, monitor and apply verified compensating controls. If exploitation is suspected, activate incident response; do not wait for a complete inventory or vendor report before urgent protective action.

Step 3: Use the contract. Demand a remediation timeline, evidence of the fix, and an incident report. Exercise the right to audit if answers are inadequate.

Step 4: Reduce dependency risk. Add the event to the risk register, evaluate a secondary supplier or an exit plan, and update the supplier risk rating.

Why not automatically terminate immediately? Abrupt loss of radiology can create serious safety risk; active exploitation can also demand immediate isolation. Choose containment, clinical fallback and restoration based on current impact and authority. The balanced response is containment, verification, and contractual pressure.

3. Security awareness, education, and training

Supplier agreements and notification duties should align with legal compliance and security policy.

3.1 Three different things

Level Purpose Audience Example
Awareness Change attention and behavior; "what" and "why" Everyone Phishing recognition, reporting suspicious messages
Training Teach skills for a role; "how" People performing specific tasks Secure coding for developers, incident handling for the help desk
Education Build broader conceptual knowledge and long-term capability Learners needing deeper expertise, including professionals and leaders University courses, CISSP preparation

3.2 Designing a program

  1. Obtain management support and tie goals to risk. Use incident data and risk assessments to choose topics.
  2. Segment audiences: all employees, executives (targeted by whaling), developers, administrators, finance staff (business email compromise), contractors, and new hires.
  3. Vary methods: onboarding sessions, short microlearning modules, simulations, posters, newsletters, gamification, tabletop exercises, and role-based labs.
  4. Make reporting easy: a one-click "report phishing" button turns users into sensors.
  5. Repeat on an approved, risk-based schedule: include onboarding, role changes and incident-triggered refreshers; meet applicable regulatory or contractual frequencies. Annual awareness is a common baseline, not a universal rule for all organizations.
  6. Use positive reinforcement and avoid shaming.
  7. Acknowledge and document completion for audit purposes.

Core topics: password and MFA practices, phishing and social engineering (including MFA fatigue), data handling and classification, physical security (tailgating), remote work, social media, insider-threat indicators, incident reporting, and privacy duties.

3.3 Measuring effectiveness

Completion rates prove attendance, not behavior change. Better measures:

  • Simulated phishing click rate, report rate and reporting speed, interpreted together with message difficulty, audience, delivery, automated link scanning and reporting volume.
  • Time to report a suspicious message.
  • Number and severity of incidents caused by human error.
  • Knowledge assessments before and after training.
  • Observed behavior, such as tailgating tests or clean-desk audits.
  • Help desk metrics, such as password reset volume.
  • Feedback surveys and focus groups.

Use comparable exercises and a difficulty rating such as the NIST Phish Scale before comparing departments or time periods. A harder campaign can raise click rates without proving learning declined; more reported incidents can reflect better detection. Protect individual results and use feedback to improve controls.

3.4 Keeping material current

Update content for emerging technology and threats: deepfake voice calls and video impersonation, AI-generated phishing, QR-code phishing, MFA push fatigue, generative AI data leakage (staff pasting confidential data into public tools), and new regulations. Use threat intelligence and incident reviews to refresh the curriculum at least annually and after major events.

3.5 Worked example: fixing a weak awareness program

Scenario. A company holds one annual 45-minute video for all staff. Completion is 98%, yet phishing simulations show 24% of finance staff clicking, and two business email compromise attempts nearly succeeded last quarter.

Step 1: Diagnose. Completion is not behavior. The content is generic and the audience is not segmented. Finance faces payment-fraud tactics not covered.

Step 2: Redesign. Add a role-based module for finance on payment verification (call-back to a known number, dual approval for bank detail changes). Add quarterly microlearning and simulated phishing with just-in-time coaching.

Step 3: Measure. Baseline click and report rates. Set local targets, for example below 5% clicks and above 60% reporting within two quarters, using comparable campaign difficulty and consistent denominators. These are scenario goals, not industry pass marks. Track whether payment verification catches attempted fraud.

Step 4: Report to management. Show trend charts, near misses, and costs avoided.

Why other answers are weaker. Punishing clickers reduces reporting. Raising the video length does not address role-specific risk. Relying only on technical email filters ignores the human channel; defense in depth uses both.

4. Mini case study

Situation. Contoso Health builds a patient portal. The development team skipped design review to meet a deadline. Later, the penetration test finds that an attacker can change a record identifier in a URL to read another patient's data, and that logs cannot prove who changed a prescription. The portal uses an open-source form library maintained by one volunteer, which the team never inventoried. Staff have received security training only at hiring.

Questions.

  1. Which STRIDE categories describe the two penetration test findings?
  2. What supply chain control would have shown the library risk early?
  3. How should the awareness program change?

Commented solution.

  1. Reading another patient's record by changing an identifier is information disclosure, caused by a missing authorization check (also an elevation of privilege pattern). The inability to prove who changed a prescription is repudiation; the fix is tamper-resistant audit logging that ties each change to an authenticated identity.
  2. An SBOM and composition analysis identify the dependency and known vulnerabilities. A separate supplier/open-source project-health review assesses maintainer concentration, patch history and support, informing dependency alternatives and response plans.
  3. Move from a one-time hiring session to recurring, role-based training: developers need secure coding and threat modeling; set an approved awareness schedule and simulations for staff; measure click and report rates, and update content for new threats.

5. Common pitfalls and exam tips

  • Exam tip: pick STRIDE for category-by-category design analysis, PASTA for attacker-centric, business-risk-driven analysis, and DREAD for ranking.
  • Exam tip: threat modeling should happen as early as possible, ideally in design, and be repeated when the design changes.
  • Pitfall: treating MITRE ATT&CK as a threat modeling method. It is a knowledge base of adversary behavior.
  • Pitfall: assuming a supplier's certification replaces your own due diligence and contract terms.
  • Exam tip: "right to audit," breach notification timelines, and subcontractor flow-down are the contract clauses most often rewarded.
  • Pitfall: measuring awareness by completion rate only. The best answer measures behavior (report rate, incidents).
  • Pitfall: choosing technical controls when the scenario's root cause is a missing process, such as no supplier onboarding review.
  • Exam tip: awareness is for everyone, training is for a role, education is for career development.
  • Pitfall: punishing people who report mistakes, which suppresses incident reporting.

Key terms

  • Threat modeling: structured analysis of what can go wrong in a system.
  • STRIDE: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege.
  • PASTA: seven-stage, risk-centric, attacker-focused threat modeling method.
  • Trust boundary: line where trust level changes between components.
  • SBOM: inventory of software components and dependencies.
  • VEX: product/version-specific vulnerability status assertion, with issuer, date and supporting justification.
  • Fourth party: a supplier's subcontractor.
  • Right to audit: contract clause allowing inspection of a supplier's controls.
  • Hardware root of trust: trusted hardware/firmware foundation for critical security functions; design and lifecycle assurance remain necessary.
  • Awareness / training / education: attention, role skills, career knowledge.

Summary checklist

  • I can run a basic threat model with a data flow diagram and trust boundaries.
  • I can map scenarios to STRIDE categories and choose between STRIDE, PASTA, and DREAD.
  • I can list the main supply chain risks and the controls for software, hardware, and services.
  • I know the contract clauses that protect against supplier risk.
  • I can explain SBOM, SPDX, CycloneDX, and VEX.
  • I can distinguish awareness, training, and education and design for audiences.
  • I can measure training effectiveness with behavior-based metrics and update content for emerging threats.

Official sources