Security teams often treat threat modeling, detection engineering, and SOC operations as distinct silos. Threat modeling outputs get documented but rarely reach the SOC. SOC engineers build detections but often without context of business priorities. And SOC operations fight daily battles without clear alignment to threat models or crown jewels.
This fragmentation creates what I call the “detection disconnect.”
In practice, everything in the SOC is incident response — and incident response is only effective when informed by models, threats, and business context. To solve this, we built an integrated process that links Threat Modeling → SOC Engineering → SOC Operations into a closed feedback loop.
1. Threat Modeling Team
Using PASTA (Process for Attack Simulation and Threat Analysis) as the foundation, extended with STRIDE, the threat modeling process captures:
- Business context & crown jewels (PASTA stages 1–2)
- System decomposition & trust boundaries
- Threat enumeration per component
This ensures modeling is not theoretical, but anchored in what actually matters to the business.
2. SOC Engineering
The outputs of threat modeling are mapped directly to adversary behavior using MITRE ATT&CK. This phase translates abstract models into operational detections through:
- Mapping threats to ATT&CK TTPs (bridging models with adversary reality)
- Vulnerability analysis & attack simulation (validating risks are exploitable)
- Detection engineering (building Sigma rules, Splunk searches, SOAR playbooks)
This is the translation layer — where business impact, adversary tradecraft, and telemetry meet.
3. SOC Operations
SOC operations receive engineered detections that are already connected to crown jewels and adversary TTPs. Their role becomes:
- Deploying detections and monitoring
- Executing incident response playbooks
- Risk reporting and continuous improvement (PASTA stage 7 + scoring via DREAD/FAIR)
The critical element is feedback: operational lessons learned are not lost. They flow back into threat modeling and detection engineering, continuously refining the cycle.
Why This Model Matters
Traditional SOCs often end up being alert factories — overwhelmed by false positives, disconnected from business priorities. By embedding threat modeling into engineering and operations, every detection and every alert is:
- Traceable to a business crown jewel
- Aligned to a threat model component
- Anchored in a MITRE ATT&CK TTP
This creates a business-driven SOC where detection, response, and risk reporting form one coherent narrative.
Beyond Process: Toward UTIOM
This is not just a process flow. It reflects a Unified Threat-Informed Operations Model (UTIOM) — my vision where:
- Threat modeling informs engineering
- Engineering powers operations
- Operations feed continuous improvement back to modeling
It’s a cycle, not a pipeline. And it’s how modern SOCs can evolve beyond firefighting into true threat-informed defense.
Closing Thoughts
The modern SOC cannot afford silos. Threat modeling, engineering, and operations must function as one. The loop must remain closed, with every detection tied back to the business and every response informing the next model.
This is how we move from disconnected tools and alerts to a resilient, business-aligned SOC.
ReZaAdineH 
Leave a comment