4.1 SOC ADR maturity model
Level | Activities | Configurations | Evidence / How to Prove It |
LEVEL 1 | |||
ADR alerts are ingested into SIEM | SIEM connector deployed and parsing correctly | SIEM shows ADR as an active log source; test alert received | |
Analysts can identify ADR alerts in the queue | Basic triage documentation exists | The triage decision tree (3.4) is documented and accessible | |
Escalation path to AppSec is defined | Contact list or on-call rotation documented | Escalation contact is in SOAR/runbook/wiki | |
ADR alerts are triaged within a defined SLA | Alert priority mapping is configured | SLA compliance report from the ticketing system | |
LEVEL 2 | |||
ADR alerts are correlated with other data sources (WAF, EDR, threat intel) | SIEM correlation rules include ADR events | Correlation rule audit; sample correlated incident | |
SOC can differentiate ADR alert types and apply context-specific triage | Alert categorization by vuln type, exploit status, app tier | Triage playbook has ADR-specific branches | |
ADR-specific runbooks exist in SOAR | Automated enrichment (e.g., app owner lookup, vuln context) | SOAR playbook inventory includes ADR runbooks | |
Regular (monthly) review of ADR alert quality with AppSec | Scheduled recurring meeting | Meeting notes/action items from last 3 reviews | |
LEVEL 3 | |||
ADR data actively informs threat hunting (proactive, not just reactive) | Hunting queries use ADR telemetry (e.g., “show all exploit attempts against apps with known vulns”) | Documented threat hunts using ADR data | |
SOAR runbooks include automated response actions for ADR alerts | Automated enrichment, ticket creation, escalation workflows | SOAR playbook execution logs | |
ADR metrics are tracked and reported to leadership | Dashboard with MTTD, triage SLA, alert volume trends | Monthly/quarterly report | |
SOC provides feedback loop to AppSec on exploit trends, attack patterns | Structured report or feed from SOC → AppSec | Evidence of actionable intelligence shared |