Security Operations and Reporting
Security Operations and Reporting
This domain tests SOC discipline: triage, escalation, documentation, metrics, and communication with technical and executive audiences.
Core rules and concepts
- A ticket moves through detection, triage, severity assignment, investigation, escalation, and closure with a recorded disposition (true positive, false positive, benign, inconclusive).
- Severity should reflect asset criticality, data sensitivity, exploitability, and scope, not the alert source or the analyst's workload.
- Track MTTD (mean time to detect), MTTR (mean time to respond or resolve; define it), false-positive rate, backlog, and SLA adherence. Report medians and percentiles alongside means so outliers do not hide the distribution.
- Shift handovers should list open incidents, pending actions, and context needed to continue safely.
- Executive reporting leads with business impact, scope, residual risk, and decisions needed. Technical detail such as queries, IOCs, and packet captures belongs in an appendix or a separate audience-specific report.
- Legal, privacy, and regulatory notification obligations vary; involve legal/compliance early rather than improvising.
Worked example
A monthly dashboard shows MTTD improved by 40% while MTTR worsened by 25%. Before concluding the team responds more slowly, segment by severity and incident type. The improvement may come from faster detection of low-severity commodity alerts, while a few complex incidents inflate the mean. Reasoning: compare medians, check whether the mix of incidents changed, and verify how response start and end are timestamped. Do not present a single blended metric as proof of performance.
Traps that cost marks
- Reporting averages without medians or percentiles.
- Confusing detection time with response time.
- Closing tickets without a disposition.
- Sharing unverified indicators.
- Giving executives raw packet captures instead of impact.