What Security Operations Is

0.1 What security operations actually is

Security operations is the discipline of detecting threats, investigating incidents, and improving the organization's security posture over time. Not monitoring alerts. Not watching dashboards. Not "24/7 coverage" — a phrase that describes staffing hours, not operational capability. Security operations is the engineering discipline that turns a collection of security tools, detection rules, and analyst skills into a measured system that gets better every quarter.

Most organizations have security operations in some form — a SOC team, a managed SOC partner, or a security engineer who watches Sentinel between other tasks. What most organizations don't have is security operations as a discipline. The difference is documentation, measurement, and improvement. A team that triages alerts has security monitoring. A team that triages alerts using documented methodology, measures triage accuracy, tracks detection coverage, reviews false positive rates monthly, and reports quality metrics to leadership has security operations.

This course teaches security operations as the discipline. Thirteen modules take you from operational foundations (the documented processes, defined roles, and measurement frameworks that most SOCs lack) through detection engineering (28 production KQL rules), investigation playbooks, hardening baselines, automation, and the metrics and reporting that make the SOC accountable and improvable.

The discipline sits at the center of four security functions that depend on each other. SOC operations monitors and triages — consuming the output of detection rules. Detection engineering builds and maintains those rules — deciding what the SOC can see. Threat hunting searches for what the rules miss — discovering gaps. Incident response contains and remediates confirmed compromises — producing the post-mortem findings that should feed back into detection. When the SOC operations function is mature, the cycle works. When it runs on habit instead of documented process, the cycle breaks — hunt findings become reports nobody actions, IR post-mortems produce recommendations nobody implements, and detection rules stagnate while the threat landscape evolves.

0.2 Three operational layers

A SOC exists to answer a question every level of the organization asks in different forms: are we being attacked, and what are we doing about it? The board asks annually. The CISO asks weekly. The L1 analyst answers it every time they open an alert. The question has three layers, and each requires different operational capability.

Visibility — what data sources does the SOC monitor, what detection rules generate alerts from that data, and what proportion of relevant attack techniques are covered? Visibility is not binary. The SOC monitors what the detection rules cover. Everything else passes through undetected. An organization with 40 analytics rules might have visibility into credential compromise and known malware but zero visibility into OAuth consent abuse, token theft, or living-off-the-land techniques.

Response capability — when an alert fires, what happens? Who receives it, what decision framework do they use to classify it, what methodology guides the investigation, what containment actions can the SOC take independently, and what requires approval? Response capability defines the boundary between "we detected it" and "we resolved it."

The feedback loop — when an investigation reveals that a phishing campaign bypassed detection, who converts that finding into a new rule? When a rule produces false positives because it matches a legitimate admin workflow, who tunes it? When a post-incident review identifies a detection gap, who closes it?

Most SOCs operate the first two layers informally. The third — the feedback loop — is the layer most SOCs lack entirely. Without it, the SOC processes the same quality of alerts forever while the threat landscape evolves. Detection degrades. False positive rates climb. Investigation quality stays flat. The SOC becomes a team that watches alerts rather than a function that improves the organization's security posture.

This module introduces all three layers. Module 1 builds the operational foundation that makes them work. Modules 2-12 build the detection, investigation, and program maturity capabilities that the foundation supports.

0.3 Where most SOCs fail

SOCs fail in three patterns, each rooted in a missing operational discipline.

The habit SOC. The team triages alerts because the analysts know how. Nobody documented the triage methodology, the investigation process, or the escalation criteria. When the experienced analyst is on leave, investigation quality drops visibly. When a new analyst starts, they learn by watching the person next to them. The SOC is exactly as capable as the people on shift and exactly as fragile as their continued availability.

The speed SOC. The team measures MTTT (mean time to triage), SLA compliance, and alerts closed per shift. The dashboard is green. Leadership reports "4-minute MTTT and 98% SLA." Meanwhile, the mean time to detect actual compromises is 14 days — because the metrics measure how fast the SOC processes alerts, not whether the SOC catches attacks. The SOC is fast at handling its workload and slow at fulfilling its mission.

The stale SOC. Detection rules were deployed during the Sentinel implementation and haven't been evaluated since. The 23 template rules cover 10% of relevant ATT&CK techniques. Hunt findings go into reports nobody converts to rules. Incident post-mortems produce recommendations nobody implements. The detection library is a deployment artifact, not an engineered system. It was configured once and never revisited.

At Northgate Engineering, all three patterns existed simultaneously before INC-NE-2026-0227-001 — the AiTM campaign that operated undetected for 21 days while the dashboard reported green metrics. The SOC had habits (undocumented processes), speed (6-minute MTTT, 96% SLA), and staleness (23 template rules, no feedback loop). This course exists because of the gap between that default state and what security operations as a discipline makes possible.

0.4 The SOC maturity spectrum

SOC maturity is not a single number. It's a profile across capabilities — and the gap between the strongest and weakest capability reveals where the SOC is most vulnerable.

Five levels describe capability states. Level 1 (ad-hoc): the capability depends on individuals, not process. Level 2 (repeatable): documented process produces consistent results regardless of who's on shift. Level 3 (measured): quality metrics drive decisions — not just speed metrics. Level 4 (managed): scheduled improvement activities find and close gaps proactively. Level 5 (optimizing): the SOC experiments with new approaches and measures whether they improve outcomes.

Most SOCs operate at Level 1-2. This course builds to Level 3 — the level where the SOC can prove it's effective with data, not assertions. In Section 3 of the content, you'll see the three failure patterns in detail and assess which ones apply to your own SOC.

0.5 What this module covers

This module orients you to the course and establishes the conceptual foundation that Module 1 builds on.

Section 0.1 — What a SOC Actually Does. What a SOC does as a function — not alert monitoring, but the engineering discipline of detection, investigation, and measured improvement. How SOC operations connects to detection engineering, threat hunting, and incident response.

Section 0.2 — The Four Security Operations Functions. The four functions that depend on each other — SOC operations, detection engineering, threat hunting, and incident response. How the cycle works when the SOC is mature, and how it breaks when it runs on habit.

Section 0.3 — Where Most SOCs Fail. Three failure patterns — the habit SOC, the speed SOC, and the stale SOC. Northgate Engineering as the worked example of all three failing simultaneously.

Section 0.4 — The SOC Maturity Spectrum. Five maturity levels across eight capabilities. Why most SOCs operate at Level 1-2, and why this course builds to Level 3 — the level where the SOC can prove it's effective with data.

Section 0.5 — The Detection-and-Response Pipeline. How data flows from source through detection through investigation — the pipeline that connects your security tools into a system. Where the pipeline breaks and what each module does to fix it.

Section 0.6 — What This Course Builds. The thirteen modules and the three categories of deployable artifacts — operational foundation, detection and investigation capability, and a measured program.

Section 0.7 — Lab Environment and How to Study. M365 E5 developer tenant setup, Azure subscription with Sentinel, study rhythm, phase structure, and how to work through the course.

Section 0.8 — Module Summary. Key concepts from Module 0 and what Module 1 requires.

Go to Section 0.1 — What a SOC Actually Does to begin.