SecOps

WHAT IT IS. Security operations is the running of security as a service with a shift pattern, not as a project with a deadline. Something watches the estate, something decides which of today's ten thousand signals deserve a human, and someone is awake when one of them turns out to be real. The output is not a tool inventory; it is measured time — how long an intrusion goes unnoticed, and how long it survives once noticed. WHY IT EXISTS. Detection without triage is a queue nobody reads. Most teams buy the sensor and skip the operating model, then discover during an incident that alerts route to a shared mailbox, nobody owns the decision to escalate, and the only person who understands the tooling is on holiday. SecOps exists to make the unglamorous half — ownership, rotas, runbooks, alert hygiene — as deliberate as the detection engineering. WHEN TO USE IT. As soon as you hold data or access that someone would want, which is earlier than most teams admit. It scales down: a small team can run one high-fidelity detection, one documented escalation path and a quarterly drill, and be genuinely better off than a large team with forty noisy rules. What does not scale down is the decision of who gets woken and what authority they hold. WHO OWNS IT. A security operations function owns detections, triage and the response process; engineering teams own the fixes and the telemetry their services emit. The pairing matters — a detection written without the owning team produces alerts nobody can action. Executive ownership sits with whoever can authorise disruptive containment at 03:00, and that authority must be written down before it is needed. WHAT GOOD LOOKS LIKE. Alerts carry an owner, a runbook link and an expected action. False-positive rate is measured and actively driven down, because analyst attention is the scarcest resource in the building. Mean time to detect and mean time to contain are tracked per detection class, not as a single vanity number. Security incidents use the same incident process as reliability ones — see /incidentops — with an added containment decision. Drills happen on a schedule, and at least one per year is a surprise. HOW TO IMPLEMENT. Start from the assets that would hurt most, not from the tool's default rule pack. Write three detections you can explain, each with a runbook in /runbooks and a named owner. Route them to a real on-call rotation with an escalation path. Instrument the funnel: signals in, alerts raised, alerts actioned, true positives. Review that funnel monthly and delete rules that never fire truly — a deleted noisy rule is a security improvement. Then rehearse: a tabletop exercise that ends with an assigned action list beats a shelf of policy. HOW TO ASSESS YOURSELF. Can you name who is on call for a security alert tonight, and what they are permitted to shut down without asking? Do you know your false-positive rate this month? When did you last practise a containment, and what broke in the practice? Run the assessment at /assess to score detection coverage, triage discipline and response rehearsal against the model below, and use /checklists for the pre-incident readiness pass.