Security Operations and Management
Security Operations and Management
Security operations is the day-to-day machinery that keeps detection and response running: people, process, and tooling organized around a defined scope. Candidates must understand the operating model (in-house SOC vs. MSSP vs. hybrid), tiered analyst roles (Tier 1 triage, Tier 2 investigation, Tier 3 threat hunting/IR), and the service management functions that surround them: change management, configuration management, asset inventory, and knowledge management.
Key concepts to master:
- Governance artifacts: policies (intent), standards (mandatory specifics), procedures (step-by-step), guidelines (recommended). Questions often swap these definitions.
- Metrics and SLAs: MTTD (mean time to detect), MTTA (acknowledge), MTTR (respond/remediate). Know which metric a scenario is describing.
- Roles and separation of duties: the person who approves a firewall change should not be the person who implements it.
- Asset and configuration baselines: you cannot protect or detect on assets you have not inventoried; hardening baselines (CIS Benchmarks) anchor configuration management.
- Vulnerability and patch management as a recurring operational cycle, distinct from incident response.
Traps: confusing policy with procedure; assuming MTTR means "time to detect"; treating threat hunting as reactive (it is hypothesis-driven and proactive); and forgetting that MSSP contracts still leave the customer accountable for governance and data.
Rule of thumb: Policy says what and why; standard says how much/how; procedure says how, step by step; guideline says nice-to-have. If a question asks for the document that tells an analyst exactly which steps to take, the answer is procedure.
Worked example: An organization wants a document stating "all privileged accounts require MFA." That is a policy statement. The specific cipher suites and token types allowed belong in a standard. The click-by-click enrollment steps belong in a procedure.