2.7 Threat Modeling, Supply Chain Risk, and Third-Party Governance

Model Threats Before They Become Incidents

Threat modeling is a structured way to ask what can go wrong before a system or process is deployed. It is not only for developers. A privacy workflow, cloud migration, vendor integration, warehouse network, identity redesign, or merger can all benefit from threat modeling. The output should influence design, control selection, testing, monitoring, and risk acceptance.

A practical threat model starts with assets and objectives. What data, service, process, or safety function must be protected? Who uses it? Where are the trust boundaries? What data flows cross networks, accounts, regions, vendors, or privilege levels? What assumptions are being made? The model should be simple enough to use but specific enough to reveal design risk.

Common methods include STRIDE, attack trees, misuse cases, abuse cases, kill chain analysis, and MITRE ATT&CK-informed discussions. STRIDE considers spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. The method is less important than the discipline: identify credible threats, rank them, choose controls, assign owners, and validate the results.

Threat modeling should be scenario-rich. For an API that lets partners submit orders, spoofing may involve stolen partner credentials. Tampering may involve changing quantity or account numbers in transit. Repudiation may involve denying a submitted order. Information disclosure may involve returning another partner's order data. Denial of service may involve flooding the order endpoint. Elevation of privilege may involve using partner access to reach administrative functions.

Supply chain risk extends the model beyond the organization's walls. Software dependencies may contain vulnerabilities or malicious updates. Hardware may arrive with tampered firmware. A managed service provider may hold privileged credentials. A cloud provider region outage may affect availability. A single supplier may create concentration risk. A subcontractor may process regulated data without being visible to the customer.

Third-party governance covers the vendor lifecycle. Before selection, define business need, data involved, criticality, regulatory scope, and risk tier. During due diligence, review security program evidence, certifications or assessment reports, vulnerability management, incident history, privacy practices, subcontractors, financial stability, and business continuity. During contracting, define security requirements, audit rights, notification timing, data return, data deletion, service levels, and liability. After onboarding, monitor performance and risk.

A vendor risk tiering checklist includes:

• Does the vendor process confidential, regulated, or personal data?
• Does the vendor have production access or privileged access?
• Would vendor outage stop critical business processes?
• Does the vendor use subprocessors or offshore support?
• Is the vendor hard to replace quickly?
• Are contractual controls, audit rights, and incident notification terms adequate?
• Is there an exit plan, data return plan, and deletion evidence requirement?

Contracts matter because technical controls alone cannot govern an external party. Security addenda, data processing agreements, service level agreements, right-to-audit clauses, breach notification terms, vulnerability disclosure expectations, subcontractor approval, and return or destruction terms create enforceable obligations. Security teams should provide requirements, but procurement and legal usually execute contract language.

Monitoring should continue after signature. Annual questionnaires are not enough for critical suppliers. Depending on risk tier, the organization may review independent audit reports, penetration test summaries, vulnerability remediation, business continuity exercise results, incident notifications, access logs, service performance, subprocessor changes, and financial or geopolitical indicators. Vendor risk changes when services, data, ownership, or threat conditions change.

Scenario: a company wants a payroll SaaS provider. The vendor will process employee personal data, tax identifiers, bank details, and compensation. Risk governance should include privacy review, encryption and access controls, administrator roles, data residency, breach notification, backup and recovery, subcontractors, support access, audit evidence, and exit terms. A low price should not override protection of highly sensitive data.

Scenario: developers want to add an open source package that saves weeks of work. The threat model should consider maintainer reputation, dependency tree, license, known vulnerabilities, update cadence, package integrity, build pipeline controls, and whether the code handles sensitive data. The answer is not automatically reject open source. The answer is to manage dependency risk with policy, tooling, review, and update processes.

Scenario: a managed service provider requires domain administrator access for troubleshooting. That access creates high supply chain and insider risk. A CISSP-oriented design would prefer least privilege, just-in-time access, MFA, session recording, approval workflow, network segmentation, named accounts, contractual limits, monitoring, and rapid revocation. If broad access remains necessary, residual risk needs explicit acceptance.

Threat modeling and vendor governance should feed each other. If a threat model shows that a vendor integration can alter customer balances, vendor due diligence and contract controls must be stronger. If due diligence shows weak incident response, the architecture may need compensating monitoring and tighter data minimization. Risk treatment can be technical, contractual, procedural, or a combination.