Theory — Security Operations Centers (SOC)
Theory — Security Operations Centers (SOC)
You've been working with Azure Monitor, Application Insights, and Microsoft Sentinel all day. Now let's look at what happens when these tools actually fire — because the people who use them every day are called a Security Operations Center (SOC).
This page explains how SOCs work so you can write detection rules that analysts will actually find useful.
What is a SOC?
A Security Operations Center is an organisational unit responsible for continuous monitoring, detection, and response to cyber threats.
A SOC needs three things working together:
- People — The analysts who investigate alerts and incidents.
- Processes — The playbooks, runbooks, and escalation procedures that guide investigations.
- Technology — The tools that collect telemetry, generate alerts, and help analysts investigate (like Microsoft Sentinel).
How SOC Teams Are Organised
Teams structure their security operations differently depending on size, budget, and maturity. Some use a three-tier model; others use L1/L2/L3 labels or completely different structures. The most common approach in larger organisations is:
Tier 1 — Triage Analyst
Role: The first line of defence. Tier 1 analysts monitor alerts in real-time and determine whether each alert is a false positive or a genuine incident.
| Activity | Description |
|---|---|
| Alert triage | Review incoming Sentinel incidents and categorise them (False Positive, Informational, True Positive) |
| Initial containment | Follow playbooks to isolate affected systems (e.g., disable a compromised user account) |
| Escalation | Pass confirmed incidents to Tier 2 with initial findings documented |
Tools used: Microsoft Sentinel Incidents blade, basic KQL queries, email/Slack.
Key skill: Speed and accuracy in classification. A Tier 1 analyst might triage 50–100 alerts per shift.
Tier 2 — Threat Hunter / Investigator
Role: Tier 2 analysts take escalated incidents and perform deep investigations. They connect the dots between seemingly unrelated alerts and determine the full scope of a breach.
| Activity | Description |
|---|---|
| Incident investigation | Trace the attack chain across multiple systems and log sources |
| Threat hunting | Proactively search for hidden threats using advanced KQL queries (hunting queries) |
| Rule tuning | Adjust analytics rules to reduce false positives and improve detection quality |
Tools used: Sentinel Workbooks, advanced KQL, hunting queries, threat intelligence feeds.
Key skill: Analytical thinking and understanding the attack lifecycle. Tier 2 analysts spend less time in the inbox and more time in the data.
Tier 3 — Incident Responder / Threat Hunter
Role: Tier 3 analysts handle the most complex incidents, often involving active breaches, advanced persistent threats (APTs), or zero-day exploits. They also design detection logic and mentor lower tiers.
| Activity | Description |
|---|---|
| Advanced incident response | Lead the investigation of active breaches and coordinate remediation |
| Detection engineering | Design new analytics rules, hunting queries, and automation workflows |
| Threat intelligence | Analyse adversary tactics and map them to the MITRE ATT&CK framework |
Tools used: Full Sentinel suite, custom scripts, threat intel platforms, forensic tools.
Key skill: Deep technical expertise and creativity in thinking like an attacker.
The Incident Response Lifecycle
When a SOC detects a potential security event, it follows a structured lifecycle. Microsoft Sentinel is designed to support every stage of this process.
Stage 1 — Preparation
SOC teams ensure monitoring is in place, analytics rules are configured, and playbooks are ready. This is what you are building in Day 4.
Stage 2 — Identification
An analytics rule triggers an incident, or a Tier 1 analyst spots something unusual in the dashboards. The incident is created in Sentinel.
Stage 3 — Containment
The immediate goal is to stop the bleeding. This might mean:
- Blocking an IP address in the firewall
- Disabling a compromised user account
- Isolating a virtual machine from the network
Automation Rules in Sentinel can trigger this containment automatically (e.g., "If a critical incident is created, disable the affected Azure AD account").
Stage 4 — Eradication
Remove the attacker's access: delete malicious files, remove rogue accounts, patch the vulnerability that was exploited.
Stage 5 — Recovery
Restore systems from clean backups, verify they are secure, and return to normal operations.
Stage 6 — Lessons Learned
This stage is often rushed or skipped entirely. The SOC reviews:
- What happened?
- What did we detect, and when?
- What did we miss?
- How can we improve our detection rules and response process?
Mapping Azure Tools to the SOC Workflow
Understanding how the tools map to the SOC helps you design better experiences for the analysts who will use them daily.
| SOC Activity | Azure Tool | Data Source |
|---|---|---|
| Monitor overall security posture | Workbooks (Security Overview workbook) | Sentinel data connectors |
| Triage incoming alerts | Incidents blade in Sentinel | Analytics Rules |
| Investigate a specific incident | Sentinel Incident details + KQL queries | Log Analytics tables |
| Proactively search for hidden threats | Hunting Queries | Log Analytics tables |
| Automate response to common incidents | Automation Rules | Sentinel incidents |
| Understand attack patterns | Workbooks + Threat Intelligence | MITRE ATT&CK mappings |
Key Takeaways
- A SOC works because of people, processes, and technology working together — tools like Sentinel are just one piece of that puzzle.
- The Incident Response lifecycle has six stages — from Preparation through Lessons Learned — and Microsoft Sentinel is designed to support every stage.
- As an engineer building detection rules, you're designing the first step of the SOC's daily workflow. Good detection rules make Tier 1 analysts' jobs easier; bad rules cause them to ignore real threats or drown them in noise.