The Four Security Operations Functions

Four functions, one cycle

Security operations has evolved into four distinct functions. Each does something different. Each depends on the others. Most organizations have three of them in some form. The fourth varies, some organizations lack detection engineering, others lack threat hunting, and a surprising number lack formal incident response. But the cycle requires all four to function. When any one is absent, every function degrades.

The cycle is not a theoretical model. It's the operational reality of how security programs improve. Threat intelligence and coverage analysis inform what the detection engineer builds. Detection rules feed the SOC. The SOC's triage results inform tuning. Threat hunting searches for what the rules miss. Incident response identifies what the rules should have caught. Each function's output is the next function's input. The cycle turns, and the program improves. Stop any one function, and the cycle stalls.

Estimated time: 35 minutes.

SOC operations: the operational core

The SOC is where alerts arrive, investigations begin, and determinations are made. The SOC analyst is the first responder, they receive the alert, evaluate whether it's real, determine its severity, and either close it or hand it off.

SOC operations is reactive by design. It responds to what the detection rules produce. The quality of SOC work is bounded by the quality of the alerts it receives. A SOC operating against a detection library with a 47% false positive rate spends nearly half its time dismissing noise. The SOC can't fix this by working harder or triaging faster. It can only be fixed by improving the detection rules upstream, which is detection engineering's job.

But the SOC produces something detection engineering needs: classified incidents. Every alert the SOC closes with a disposition, true positive, false positive, benign true positive, or undetermined, is a data point that feeds the tuning process. Without SOC dispositions, detection engineering has no signal for which rules need tuning. Every incident the SOC escalates and investigates produces findings about how attacks behave in the environment, findings that feed the detection backlog. Without SOC investigations, detection engineering has no intelligence about which techniques to prioritize.

The SOC is the consumer of detection rules and the producer of detection intelligence. Both roles are necessary. Most SOCs perform the consumer role. This course builds the infrastructure that makes the producer role systematic.

Detection engineering: building what the SOC sees

Detection engineering builds and maintains the detection rules that the SOC consumes. The detection engineer takes threat intelligence, hunt findings, incident post-mortems, and ATT&CK coverage analysis and turns them into production detection rules, tested, tuned, documented, versioned, deployed, and maintained on a cadence.

Without detection engineering, the detection library is a deployment artifact. Rules are enabled during the SIEM implementation, augmented reactively after incidents, and never systematically evaluated, tested, or maintained. The library degrades over time as the environment changes and the threat landscape evolves. New admin workflows generate false positives that nobody tunes. New attack techniques emerge that nobody writes rules for. The coverage gap widens invisibly.

Detection engineering is the function that most organizations lack. It's also the function that this course teaches alongside SOC operations, because SOC operations without detection engineering is a response capability without an improvement mechanism. Module 2 of this course teaches detection engineering methodology. Modules 3-6 build 28 production detection rules. The Detection Engineering course on this platform goes deeper, 71 rules across 13 modules with a detection-as-code pipeline and board reporting.

The detection engineer's daily work

The daily work is not writing KQL all day. KQL is the implementation tool, maybe 25% of the role. The other 75% is the thinking that makes the implementation effective. Threat modeling, which attack techniques are relevant to this organization, given its industry, technology stack, and crown jewels. Hypothesis development, what would this technique look like in this organization's telemetry, and what signals distinguish it from legitimate activity. Rule specification, documenting the hypothesis, the ATT&CK mapping, the data source, the detection logic, the false positive profile, and the analyst response procedure before writing a single line of KQL. Testing, running the rule against historical attack data and legitimate noise to verify it fires correctly and doesn't drown the SOC. Tuning, monthly review of false positive data with targeted fixes for each source. Measurement. ATT&CK coverage percentage, mean time to detect, false positive rate, rule health score.

The detection engineer's highest-value output is not the individual rule. It's the measured, maintained program, the system that tells leadership exactly what the detection library covers, where the gaps are, and how coverage is improving over time.

Threat hunting: finding what the rules miss

Threat hunting proactively searches for evidence of compromise that detection rules have missed. Where the SOC reacts to alerts, the threat hunter operates in the silence, the techniques and behaviors that produce telemetry but no alert.

Hunting is hypothesis-driven. "I believe attackers may be abusing OAuth consent grants to establish persistent access, let me query CloudAppEvents for anomalous consent patterns." The hypothesis drives the query. The query produces findings. The findings either confirm the hypothesis (the technique is being used) or refute it (no evidence in the current data). Either outcome is valuable. A confirmed finding triggers investigation and response. A refuted hypothesis suggests that either the technique isn't being used or the query needs refinement.

The critical output of threat hunting is the detection gap. Every technique a hunt discovers that the detection library doesn't cover is a gap that should become a detection rule. The Threat Hunting course on this platform teaches the methodology, hypothesis development, ATT&CK-aligned hunting campaigns, UEBA composite risk scoring, and retroactive IOC sweeps.

The hunt-to-detection pipeline

When a hunt produces a finding, that finding should become a detection rule. In most organizations, it becomes a paragraph in a hunt report that nobody converts into automation. The hunt report goes to SharePoint. The recommendation sits alongside 40 other recommendations from previous hunts. Nobody tracks whether the recommendations are implemented.

The hunt-to-detection pipeline is the mechanism that converts hunt findings into deployed detection rules. It requires someone (the detection engineer or L3 analyst) to receive the finding, design the detection logic, build and test the rule, and deploy it. Without the pipeline, hunting is intelligence without action, the organization spends resources discovering gaps and then does nothing about them.

Incident response: learning from what got through

Incident response investigates and contains confirmed compromises. The responder takes an escalated alert, determines the full scope, every system the attacker touched, every action they took, the full timeline, contains the threat, and leads remediation.

IR operates at the end of the detection pipeline. If detection is late, response is late. Every hour of dwell time the attacker gains before detection increases the blast radius. M-Trends 2026 documented attacker hand-offs, initial access brokers passing credentials to ransomware operators, in under 30 seconds. When the initial access goes undetected for days, the ransomware operator has time to map the network, identify backup systems, disable security tools, and stage encryption. When detection catches the initial access within minutes, the response team can contain before escalation.

The economics are stark. IBM's 2025 Cost of a Data Breach Report found that organizations using AI and automation in their security operations cut their breach lifecycle by 80 days and saved $1.9 million per incident. But the AI and automation only help if the detection rules exist to trigger the automated response. The fastest SOAR playbook in the world does nothing if no analytics rule fires for the technique the attacker is using. Detection quality is the upstream constraint that determines whether speed improvements at the response layer actually reduce breach impact.

The post-mortem feedback loop

IR teams routinely discover during post-mortems that telemetry existed at every phase of the attack chain. If a detection rule had queried that telemetry, the incident would have been caught days or weeks earlier. The post-mortem produces a list of detection gaps, techniques the attacker used that no rule detected.

That list is the highest-priority input for the detection backlog. A detection gap discovered during an incident is not theoretical, it's a confirmed technique that an attacker used against your environment. The rule built from that gap is the most valuable detection in the library because it's derived from real attack behavior, not a vendor advisory.

Without the feedback loop from IR to detection engineering, the same gaps persist. The same techniques succeed. The post-mortem recommendations accumulate in a document that nobody converts to action. The Incident Response course on this platform teaches the investigation methodology, from evidence acquisition through timeline reconstruction to the post-mortem and program improvement.

The cycle in practice: NE before and after

At Northgate Engineering before INC-NE-2026-0227-001, the cycle was broken at every connection point.

The SOC triaged alerts but classified every closure as either "True Positive" or "False Positive", no benign-true-positive category, no undetermined category, no structured false positive analysis that identified which rules were noisiest. Detection engineering had no signal for tuning because the disposition data was binary and undifferentiated.

Threat hunting ran one hunt per quarter, mandated by the ISO 27001 control. Each hunt produced a report. The reports recommended detection improvements. The recommendations sat in a shared folder. Nobody tracked implementation. The OAuth consent grant hunt from Q3 recommended a detection rule. The Q1 hunt six months later found the same technique, still undetected. The recommendation was copied verbatim from the Q3 report.

Incident response conducted post-incident reviews after every Severity 1 incident. The reviews identified detection gaps. The gaps went into the review document. Nobody converted them to detection rules because nobody's job description included "convert IR findings into deployed detections." The detection engineer role didn't exist. The SOC lead was too consumed by queue management to perform the function informally.

After the AiTM incident, Rachel Okafor restructured the connections. SOC dispositions expanded to four categories with structured false positive analysis that fed a monthly tuning review. Hunt recommendations went directly to the detection backlog with assigned owners and target deployment dates. IR post-mortem findings became detection requirements with the same tracking. The SOC lead's schedule was restructured to protect 10 hours per week for L3 work, the detection feedback that the cycle requires.

The cycle didn't require new tools. It required operational connections between functions that already existed. Those connections are what this course builds.

Where this course sits in the cycle

This course. SOC Operations, teaches the operational core. The SOC is not the most technically demanding of the four functions. Detection engineering requires deeper KQL skill. Threat hunting requires deeper analytical reasoning. Incident response requires deeper forensic capability. But the SOC is the function that the other three depend on.

Detection rules that fire in a SOC without an escalation framework produce alerts that sit in the queue until someone decides they matter, or don't. Investigation playbooks designed for a SOC without shift handover procedures produce investigations that restart every morning because the overnight context was lost. Threat hunt findings that feed into a SOC without a feedback loop produce intelligence that nobody converts to action.

The SOC as enabler

The SOC's operational infrastructure, the documented triage methodology, the escalation framework, the metrics, the charter, the handover procedures, is what makes the other three functions effective. A detection rule is only as valuable as the SOC's ability to triage it correctly and investigate it thoroughly. A hunt finding is only as valuable as the mechanism that converts it to a deployed rule. An IR post-mortem is only as valuable as the process that ensures the recommendations get implemented.

This course builds that operational infrastructure. When you complete it, the SOC doesn't just process alerts, it operates as the hub that connects detection, hunting, and response into a cycle that improves.

How this course connects to other courses

The four functions map to four courses on this platform:

SOC Operations (this course) teaches the operational core, triage, investigation, escalation, metrics, and the operational infrastructure that makes everything else work. Detection Engineering teaches the rule lifecycle, from threat model to deployed rule to board report. 71 production KQL rules across 13 modules. Threat Hunting teaches hypothesis-driven search. ATT&CK-aligned campaigns, UEBA scoring, and the methodology for finding what rules miss. Incident Response teaches investigation methodology, evidence acquisition, timeline reconstruction, containment, and the post-mortem process that feeds the cycle.

Each course stands alone. Each course is more effective when the learner understands the cycle. If you're completing SOC Operations first, you'll understand how the operational infrastructure you build supports the detection rules, hunt campaigns, and investigation procedures from the other courses.