Auditors and new SOC leads often assume the SOC Queue blocks traffic. It does not. Enforcement belongs to the Security Decision Engine only.
Component roles
| Component | Role | Decides? | Changes state? |
|---|---|---|---|
| Incident | Record — what happened | No | Yes (workflow) |
| Campaign | Correlation — grouped narrative | No | Yes |
| SOC Queue | Prioritization — where to start | No | No |
| Security Case | Investigation workflow | No | Roadmap / partial |
| Decision Engine | Allow / Block / Challenge | Yes | No |
| Explanation Layer | Why this decision | No | Never changes enforcement |
SOC Queue behaviour (implemented)
- Priority score 0–100 with readable reasons
- Deduplication by application + IP + attack rule
- Read-only — no auto-remediation, no silent blocks
- Links to primary incident and campaign for context
Decision Engine behaviour (implemented)
- Two-phase pipeline: signal collector → policy-driven decision
- Actions: Allow, Block, Challenge, Log
- Conditions: risk score, threat intel, campaigns, geo, rules — via configured policies
- Threat intel feeds are advisory at import; blocking requires decision policies
Common mistake
Treating a high queue priority as “auto-block tomorrow.” Queue scores help analysts triage; only Protection mode + decision policies enforce blocks.
Audit trail
Decision explanation metadata is stored in traffic logs. The explanation layer documents rules, risk, TI, geo, and campaign influence — it never overrides the enforcement decision retroactively.