Building a Defense Cybersecurity Stack, Part 1: Threat Model, Asset Inventory, and CTI Foundation

Defense cybersecurity is enterprise cybersecurity with three multipliers — nation-state adversaries, classified-enclave network topology, and operational-technology coupling. The platforms that work in this context are built from the threat model out: assets catalogued by classification and criticality, threat intelligence flowing through STIX/TAXII pipelines, detection and response layered on top. The platforms that fail were built by re-skinning commercial security software with a defense label. This four-part series walks through how to do it right. Part 1 covers the foundation.

The architectural framing is in The Complete Guide to Defense Cybersecurity. The C2 build series at Building a C2 System from Scratch is the platform this cyber stack defends; the NATO interop series at NATO Interoperability Implementation Walkthrough sets the coalition-data-sharing context.

Step 1: Build an Explicit Threat Model

Defense cybersecurity that does not start from an explicit threat model is defense cybersecurity that defends against a fiction. The threat model documents who the platform defends against, what those adversaries can do, and what they want. Every subsequent architectural decision references the model.

The components of a defense-grade threat model:

• Threat actors. Nation-state adversaries (with named country attributions where the operational context supports it), state-affiliated groups, criminal actors, insiders, supply-chain compromise vectors. Each actor has motive, capability, and patience profiles.
• Adversary tactics. MITRE ATT&CK mapping is the common language; align with it from sprint one. Specific TTPs (tactics, techniques, procedures) the platform anticipates.
• Adversary objectives. Reconnaissance, persistence, lateral movement, data exfiltration, operational disruption, kinetic preparation. Different objectives require different defensive postures.
• Attack surface. Network ingress points, supply-chain dependencies, human-facing surfaces (phishing, social engineering), operational-technology interfaces.
• Assumed adversary capabilities. Zero-day exploitation, custom-tooled implants, signals-intercept-capable, dwell-time-tolerant. The platform's defensive engineering scales to these capabilities, not to commercial-criminal-grade.
• Out-of-scope threats. Explicitly enumerated: physical security of the data centre, electromagnetic security beyond standard practice, threats handled by other parts of the security architecture. Scoping prevents scope-creep into infinite defense.

The threat model is a living document, versioned in the repository alongside source code, reviewed by security and engineering leads. It is the procurement-grade artefact that accreditation reviewers ask for first.

Step 2: Asset Inventory with Classification and Criticality

The cyber stack defends specific assets. Cataloguing them is unglamorous and decisive — programmes that skip the asset inventory defend against the wrong adversary and the wrong attack surface.

The asset catalogue captures, for each asset:

• Asset identifier and friendly name. Stable, human-readable, traceable across the security toolchain.
• Asset type. System, database, network segment, application service, model weight, training dataset, operational technology controller.
• Classification level. NATO RESTRICTED, NATO SECRET, COSMIC TOP SECRET, national equivalents. The level shapes everything downstream.
• Compartments and releasability. Per STANAG 4774 conventions (see Part 3 of the NATO interop series).
• Criticality tier. Mission-critical, mission-essential, mission-supporting, administrative. Different tiers warrant different defensive postures.
• Ownership. The organization responsible for the asset's operation and security.
• Network enclave. Which classified or unclassified network the asset operates on.
• Dependencies. What other assets this one depends on; what depends on it.

The catalogue is automated where possible (CMDB integration, discovery scanning where permitted) and curated where automation falls short (operational-technology assets often require manual cataloguing). Living document, versioned, the foundation for everything that follows.

Step 3: Establish the CTI Pipeline

Cyber Threat Intelligence is the layer that makes detection meaningful. Raw indicators flowing in, contextualized threat data flowing through, actionable intelligence flowing out to the detection and response toolchain. The pipeline architecture matters as much as the inputs.

The pipeline stages:

Ingestion. Multiple feed types: STIX/TAXII feeds from commercial vendors, partner CSIRT bulletins, national CERT advisories, vulnerability databases (NVD, vendor advisories), OSINT sources. Each feed has its own format, authentication, and trust model.

Normalization. Convert inputs to a canonical CTI representation — STIX 2.1 objects (indicators, malware, threat actors, campaigns, attack patterns). Normalization is one-way; the canonical form is what consumers see. The detailed CTI platform engineering is in CTI Platforms for Defense.

Deduplication and correlation. The same indicator may appear in five feeds. Deduplicate aggressively. Correlate indicators sharing context — same threat actor, same campaign, same attack pattern — into composite intelligence packages.

Enrichment. Add context the raw feeds lack: confidence scoring, MITRE ATT&CK mapping, asset-relevance scoring against the inventory, classification-handling guidance, releasability tags.

Distribution. Push to SIEM/SOAR for detection rules, to EDR for endpoint blocklists, to network security tools for traffic filtering, to threat-hunt teams as research inputs, to the operational fusion stack where cyber observables enter the multi-INT picture (see Fusion Pipeline, Part 3).

Step 4: STIX/TAXII Implementation

STIX (Structured Threat Information Expression) is the data model for cyber threat intelligence. TAXII (Trusted Automated Exchange of Intelligence Information) is the transport protocol. Together they are the lingua franca of CTI exchange between defense organizations and commercial threat intelligence providers.

The implementation reality:

Consumer-side first. Most defense programmes consume STIX/TAXII from commercial vendors (Mandiant, Recorded Future, CrowdStrike, MITRE) and partner CSIRTs. The consumer-side TAXII 2.x client is well-understood and tractable.

Schema validation at the boundary. Every incoming STIX object is validated against the schema before further processing. Malformed input is logged and rejected. Schema violations have been used as injection vectors; strict validation is the structural defense.

Confidence scoring. STIX objects have confidence fields. Use them. A vendor's high-confidence indicator and an OSINT-derived low-confidence indicator get different handling in the downstream detection pipeline.

Provider-side selectively. Programmes that share intelligence with partners — coalition CSIRTs, ISAC participation, internal-to-external sharing for incident response — implement TAXII provider endpoints. The implementation is heavier than consumer-side and requires the classification-handling discipline from Part 3 of this series.

Step 5: OSINT Pipeline with Source Diversity

Open-source intelligence is a high-value CTI input. Social media, paste sites, ransomware-leak sites, technical forums, vendor security advisories, news. OSINT detection of an attack against partner forces or infrastructure is operational-value intelligence that vendor feeds often lag on.

The OSINT pipeline pattern:

Source diversity. No single source dominates. Multiple sources reduce single-feed bias and surface false positives faster.

Confidence by source. Each source has a calibrated confidence score based on historical accuracy. A claimed indicator on a anonymous forum is treated differently from a confirmed indicator in a national CERT advisory.

Attribution and citation. Every OSINT-derived indicator carries the source URL, snapshot timestamp, and analyst note. Without provenance, the indicator cannot survive review and cannot be propagated to coalition partners.

Legal and ethical guardrails. OSINT collection from social media has legal constraints that vary by jurisdiction. The platform's OSINT collection policy is documented, reviewed by legal, and enforced in code. The detailed treatment is in OSINT Threat Monitoring for Defense.

Step 6: Cyber-as-Fusion-Discipline

Modern defense cybersecurity treats cyber observables as another intelligence discipline alongside SIGINT, IMINT, ELINT. The cyber stack's outputs flow into the operational fusion pipeline; the operational fusion pipeline's outputs enrich cyber decision-making. The integration is bidirectional.

The architectural pattern:

Cyber events as observations. Confirmed compromises, attack-attempt detections, attributed campaigns — each becomes an observation in the canonical track schema, tagged with cyber-discipline metadata. The detailed pattern is in Building a Defense Fusion Pipeline, Part 3.

CTI enrichment of physical-domain tracks. When a cyber indicator suggests adversary activity at a geographic location, the indicator enriches the physical-domain track in the operational picture. A SIGINT collection point co-located with a confirmed cyber compromise becomes a higher-priority track for the operator.

Shared classification machinery. The classification labels on cyber data flow through the same STANAG 4774/4778 binding as physical-domain data. Cyber-specific compartments and releasability work alongside the broader classification system.

Step 7: Repository Structure for Cyber Code

Cyber stack code is sensitive — incorrect changes can disable detection, miss compromises, or leak classified material. Repository discipline mitigates the risk.

The structure that works:

• cyber/threat-model/ — versioned threat model documents, MITRE ATT&CK mappings, asset-tier classifications.
• cyber/asset-inventory/ — the catalogue from Step 2, with discovery automation and manual curation merging.
• cyber/cti/feeds/ — feed configurations, normalization rules per source, deduplication policies.
• cyber/cti/enrichment/ — enrichment pipelines, confidence-scoring rules, asset-relevance scoring.
• cyber/detection-rules/ — SIEM detection content (Sigma rules, vendor-specific formats), version-controlled, tested in CI against captured event data.
• cyber/playbooks/ — SOAR response playbooks, tested in CI, reviewed by security leadership before deployment.
• cyber/forensics/ — collection and analysis tooling, chain-of-custody procedures.
• cyber/ADRs/ — Architecture Decision Records for significant cyber-architecture choices.

What's Next

Part 1 has built the foundation. Explicit threat model, asset inventory with classification, CTI pipeline ingesting STIX/TAXII and OSINT, cyber-as-fusion-discipline integration, repository discipline. The cyber stack now has a clear-eyed view of what it defends against, what it defends, and where its intelligence comes from.

Part 2 implements the operations layer: SIEM and SOAR engineered for classified enclaves, cross-CERT integration, automated playbook discipline, the practical realities that distinguish operational cyber from PowerPoint cyber.