Chapter 4: How do I grow? — Maturity model
Persona: SOC Leader + AppSec Leader
Format: Use these tables as a self-assessment. Check off where you are, and identify what to do next.
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 |
4.2 AppSec ADR maturity model
Stage | Activities | Configurations | Evidence / How to prove it |
LEVEL 1 | |||
ADR deployed on Tier 0 (critical) applications | Agent installed, Monitor mode active | ADR console shows Tier 0 apps with active agents | |
Application metadata is complete (owner, tier, environment) | Metadata fields populated per 3.2 | ADR console export showing populated fields | |
Naming conventions aligned with SOC | Application names match CMDB / SOC convention | Cross-reference check with SOC (3.2 #1) | |
Vulnerability findings are triaged and ticketed | Integration with ticketing system (Jira, etc.) | Ticket backlog shows ADR-sourced findings | |
LEVEL 2 | |||
ADR deployed on Tier 0 and Tier 0 applications | Expanded agent deployment | ADR console shows Tier 0 + Tier 1 coverage | |
Block Mode enabled for high-confidence rules on Tier 0 apps | Policy configured per 3.5 rollout approach | ADR policy export showing Block rules per app | |
False positive rate is tracked and managed | Exception rules documented with rationale | FP rate metric; exception log with dates and reasons | |
Regular (monthly) review of alert quality with SOC | Scheduled recurring meeting | Meeting notes/action items from last 3 reviews | |
Actively-exploited vulns are reprioritized above backlog items | Process to escalate exploited vulnerabilities | Evidence: ticket priority changed based on ADR exploit data | |
LEVEL 3 | |||
ADR deployed across all application tiers | Full portfolio coverage | ADR console: coverage report vs. app inventory | |
Block Mode enabled broadly with low false-positive rate | Block policies validated across tiers | Block mode coverage %; FP rate < defined threshold | |
Mean Time to Remediate for ADR-discovered vulns is tracked and improving | Metric calculation per 4.3 | Trend report showing MTTR over time | |
AppSec provides proactive guidance to Engineering based on ADR attack trends | Structured report or briefing | Evidence of trend-based guidance shared with Eng |
4.3 Metrics That Actually Matter
Most guides mention MTTR without defining it. Here are 4 metrics with precise definitions.
# | Metric | Definition | Formula | Owner | What “Good” Looks Like |
1 | MTTD (Mean Time to Detect) — SOC | Average time from ADR alert generation to SOC analyst acknowledging/opening the alert in the SIEM | Σ(alert_acknowledged_time - alert_created_time) / count(alerts) | SOC Leader | Level 1: < 4 hrs Level 2: < 1 hr Level 3: < 15 min |
2 | MTTT (Mean Time to Triage) — SOC | Average time from alert acknowledgement to triage decision (escalate/close /investigate) | Σ(triage_decision_time - alert_acknowledged_time) / count(alerts) | SOC Leader | Level 1: < 2 hrs Level 2: < 30 min Level 3: < 10 min |
3 | MTTR (Mean Time to Remediate) — AppSec | Average time from vulnerability discovery (by ADR) to verified fix in production | Σ(patch_verified_in_prod_time - vuln_first_detected_time) / count(vulns) | AppSec Leader | Level 1: < 90 days Level 2: < 30 days Level 3: < 14 days (for Critical/High) |
4 | Block Coverage % — AppSec | Percentage of Tier 1/2 applications with Block Mode enabled for high-confidence rules | count(apps_with_block_mode) / count(tier1_and_tier2_apps) × 100 | AppSec Leader | Level 1: 0% (Monitor only) Level 2: > 50% Tier 1 Level 3: > 80% Tier 0+1 |
How to use these metrics: