Threat Analysis and Threat Intelligence

Why Threat Analysis and Threat Intelligence Matter
Secure software cannot be designed in a vacuum. Before an architect can decide which controls to build, they must understand who might attack the system, what they are after, how they are likely to attack, and which weaknesses they will exploit. Threat analysis and threat intelligence provide exactly this understanding. In the CSSLP Domain 3 (Secure Software Architecture and Design), these activities are the foundation for threat modeling, attack surface evaluation, control selection, and risk-based prioritization. Fixing a design flaw at the architecture stage is dramatically cheaper than patching it in production, which is why ISC2 emphasizes performing threat analysis early and revisiting it throughout the Software Development Life Cycle (SDLC).

What Is Threat Analysis?
Threat analysis is the structured process of identifying, characterizing, and evaluating potential threats to a software system and its data. It answers the questions: What are the assets worth protecting? Who are the threat agents (adversaries)? What attack vectors could they use? What vulnerabilities might they exploit? What would the impact be? The outputs of threat analysis feed directly into threat modeling (e.g., STRIDE, PASTA, DREAD, attack trees, Trike, VAST, OCTAVE) and ultimately drive the selection of security controls and secure design patterns.

Key terminology you must know:
Threat: Any potential event or actor that could cause harm to an asset (e.g., an attacker stealing credentials).
Threat agent / threat actor: The entity that carries out the threat (insider, hacktivist, organized crime, nation-state, script kiddie, malicious code).
Vulnerability: A weakness that a threat can exploit (e.g., unvalidated input).
Attack vector: The path or means by which a threat reaches the asset (e.g., a public API, a phishing email).
Attack surface: The sum of all points where an attacker can try to enter or extract data.
Risk: The likelihood that a threat exploits a vulnerability multiplied by the impact. Threat alone is not risk; risk requires a threat, a vulnerability, and an impact.
Likelihood and impact: The two dimensions used to rank and prioritize threats.

What Is Threat Intelligence?
Threat intelligence is evidence-based, actionable knowledge about existing or emerging threats, including threat actors, their motivations, their tactics, techniques, and procedures (TTPs), indicators of compromise (IoCs), and exploited vulnerabilities. Whereas threat analysis is largely internal (focused on your system), threat intelligence is largely external (focused on the real-world threat landscape). Good threat intelligence makes threat analysis realistic: instead of imagining hypothetical attackers, architects design against attacks that are actually being carried out.

Types of threat intelligence:
Strategic: High-level, long-term trends for executives and risk owners (e.g., rise of ransomware targeting healthcare).
Tactical: Attacker TTPs, often mapped to frameworks like MITRE ATT&CK; useful to architects and security engineers.
Operational: Details about specific, imminent campaigns or incidents.
Technical: Specific IoCs such as malicious IP addresses, file hashes, domains, and exploit signatures; useful to SOC analysts and automated defenses.

Common sources of threat intelligence:
Open Source Intelligence (OSINT): Public vulnerability databases (NVD, CVE), vendor advisories, security blogs, Common Weakness Enumeration (CWE), CAPEC (Common Attack Pattern Enumeration and Classification), OWASP Top 10, SANS/CWE Top 25.
Commercial feeds and vendors: Subscription-based threat feeds and reports.
Information Sharing and Analysis Centers (ISACs) and ISAOs: Sector-specific sharing communities.
Government sources: CISA alerts, US-CERT, national CERTs.
Internal sources: Incident response data, logs, SIEM alerts, honeypots, bug bounty findings, and post-mortem reports.
Standards for sharing and exchanging intelligence include STIX (Structured Threat Information eXpression) for describing threat information and TAXII (Trusted Automated eXchange of Intelligence Information) for transporting it.

How Threat Analysis Works (The Process)
1. Define scope and objectives: Identify the system boundaries, business context, and security requirements (confidentiality, integrity, availability, non-repudiation, authentication, authorization).
2. Decompose the application: Create architecture diagrams, data flow diagrams (DFDs), identify entry points, exit points, trust boundaries, data stores, external dependencies, and privilege levels. Trust boundaries are especially important because attacks typically occur where data crosses from a lower-trust zone to a higher-trust zone.
3. Identify and classify assets: Determine what is valuable (customer data, credentials, cryptographic keys, intellectual property, system availability) and rank it by sensitivity and criticality.
4. Identify threat agents and their capabilities: Use threat intelligence to build realistic attacker profiles including skill, resources, motivation, and access (insider versus outsider).
5. Enumerate threats: Apply a methodology such as STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) to each component and data flow; use attack trees to map goals to paths; use CAPEC attack patterns and misuse/abuse cases to capture how legitimate functionality can be turned against the system.
6. Identify vulnerabilities and weaknesses: Map threats to potential design weaknesses (CWE), missing controls, insecure defaults, and third-party component risks.
7. Rate and prioritize: Use qualitative or quantitative scoring (DREAD, CVSS, likelihood × impact matrices, risk heat maps). Prioritization ensures limited resources address the most severe threats first.
8. Determine responses and controls: For each threat decide to mitigate (add a control), accept (document and sign off), transfer (insurance, outsourcing), or avoid (remove the feature). Map controls to secure design principles: least privilege, defense in depth, fail secure, complete mediation, separation of duties, economy of mechanism, open design, psychological acceptability, and leveraging existing components.
9. Document and communicate: Produce a threat model document and traceability to security requirements and test cases.
10. Iterate: Re-run analysis when architecture changes, when new threat intelligence appears, or after incidents. Threat analysis is continuous, not a one-time gate.

How Threat Intelligence Integrates Into Secure Design
Threat intelligence informs the design phase by identifying which attack patterns are currently prevalent against similar technologies (e.g., API abuse, credential stuffing, supply chain attacks on dependencies), which vulnerabilities in chosen frameworks and libraries are being actively exploited, and which threat actors target the organization's industry. Architects use this to prioritize mitigations, choose secure components, define secure configuration baselines, and establish logging and monitoring requirements that will detect the known TTPs. It also feeds into the software bill of materials (SBOM) and third-party component risk management, since many real-world compromises originate in vulnerable dependencies. The intelligence lifecycle (direction/planning, collection, processing, analysis, dissemination, feedback) should align with SDLC checkpoints so the development team receives relevant, timely, and actionable information rather than raw data.

Common Pitfalls to Avoid
Treating threat analysis as a one-time checkbox; focusing only on external attackers while ignoring insiders and supply chain; confusing a vulnerability with a threat or a risk; failing to involve business stakeholders when ranking impact; relying on unvetted or stale intelligence; and designing controls for sensational but improbable threats while neglecting common, high-likelihood ones such as injection and broken access control.

Exam Tips: Answering Questions on Threat Analysis and Threat Intelligence
1. Know the vocabulary precisely. The exam frequently tests whether you can distinguish threat, threat agent, vulnerability, attack vector, exploit, and risk. If a question describes a weakness in code, that is a vulnerability; if it describes an actor or event that could cause harm, that is a threat; if it combines likelihood and impact, that is risk.
2. Timing matters: earliest is best. When asked when threat analysis or threat modeling should be performed, choose the earliest reasonable phase (requirements or design) and answers that emphasize revisiting it iteratively throughout the SDLC. Avoid answers that confine it to testing or post-deployment.
3. Match the methodology to the question. STRIDE is threat categorization per component; DREAD is risk ranking/scoring; PASTA is a risk-centric, seven-stage, attacker-focused methodology aligned with business objectives; attack trees model attacker goals hierarchically; CAPEC catalogs attack patterns; CWE catalogs weaknesses; CVE identifies specific vulnerabilities; CVSS scores vulnerability severity; MITRE ATT&CK maps adversary TTPs.
4. Remember the four risk responses. Mitigate, accept, transfer, avoid. Ignoring a risk is never a correct answer. Acceptance requires documented approval by an appropriate business owner.
5. Trust boundaries and data flows are the focus of decomposition. If a question asks where to concentrate threat analysis within a DFD, look for the answer involving trust boundaries, entry points, or where data moves between privilege levels.
6. Threat intelligence should be relevant, timely, accurate, and actionable. Questions about selecting or evaluating intelligence sources reward answers that emphasize credibility, relevance to the organization's technology stack and industry, and actionability over volume. Recognize STIX/TAXII as the sharing standards and ISACs as sector-based sharing communities.
7. Prioritize by risk, not by count. When asked how to handle a long list of identified threats, the best answer involves ranking by likelihood and impact (business risk) rather than fixing them in the order found or fixing only the easiest ones.
8. Think like ISC2: management and process perspective. The CSSLP exam often prefers the answer that is holistic, documented, repeatable, and aligned with business objectives over a purely technical quick fix. Choose answers that involve stakeholders, documentation, and traceability to requirements.
9. Watch for distractors about tools. Automated scanners and threat intelligence feeds support but do not replace human-led threat analysis during design. An answer that claims a tool alone satisfies threat modeling requirements is usually wrong.
10. Include insiders and the supply chain. If answer choices differ by breadth of threat agents considered, the more complete option that includes insiders, partners, and third-party components is typically correct.
11. Read for qualifiers. Words like BEST, MOST, FIRST, and PRIMARY signal that multiple answers may be partially correct; choose the one that most directly addresses the stated goal. For FIRST questions about threat analysis, the answer is usually defining scope, identifying assets, or decomposing the application rather than selecting controls.
12. Connect threats to requirements and tests. Expect scenario questions where the correct follow-through after identifying a threat is to derive a security requirement and a corresponding test case (misuse or abuse case), demonstrating traceability across the SDLC.

Summary
Threat analysis identifies and prioritizes what could go wrong with your software; threat intelligence grounds that analysis in the real-world activities of adversaries. Together they drive secure architecture decisions, control selection, and risk-based prioritization. For the CSSLP exam, master the terminology, understand the major methodologies and catalogs, remember that analysis begins early and repeats continuously, and favor answers that are risk-based, business-aligned, documented, and comprehensive in the threat agents and attack vectors they consider.