1 SOAR & Automation
SOAR — Security Orchestration, Automation and Response — automates repetitive SOC work. Google describes its SOAR capability as a central environment for security workflows, integrations, automated investigation, and response playbooks. A typical automated flow:
SIEM detects malicious IP
↓
SOAR queries threat intelligence
↓
SOAR checks user/device context
↓
If high confidence → EDR isolates endpoint
↓
Ticket created → SOC analyst notified
Automation can dramatically cut response time — but organisations have to be careful. Automatically disabling accounts or blocking infrastructure based on a weak detection can cause a major business outage just as easily as it prevents one. SOAR playbooks need the same tuning discipline as the detections that trigger them.
2 AI in the Modern SOC
Modern platforms increasingly use machine learning, generative AI and agentic automation to help analysts summarise incidents, write investigation queries, correlate alerts, analyse suspicious behaviour, prioritise cases, recommend response actions, and automate repetitive investigation steps. Microsoft, Elastic, Google, CrowdStrike and Palo Alto are all building this in.
AI output is evidence assistance, not unquestionable truth.
An analyst still has to verify timestamps, users, IP addresses, commands, process trees, authentication activity, and the actual underlying log records — not just trust an AI-generated summary at face value. Future SOC analysts will likely spend less time manually searching individual alerts and more time validating, correlating, and directing automated investigation systems — the investigation mindset from Lesson 3 becomes more important as the raw searching gets automated, not less.
3 SOC Metrics
Other useful measurements: alert volume, incident volume, false-positive rate, alert backlog, number of escalations, detection coverage, and time to containment. Use these carefully — closing alerts quickly doesn't automatically mean the SOC is effective; a team could hit great MTTA/MTTR numbers purely by rubber-stamping alerts without real investigation.
4 Threat Hunting
Traditional SOC monitoring is reactive: alert occurs → analyst investigates. Threat hunting flips that around — analyst develops a hypothesis → searches the environment → looks for attacker behaviour that hasn't triggered anything yet. Example hypothesis: "an attacker may be using PowerShell to download payloads." The hunter searches for powershell.exe combined with Invoke-WebRequest, DownloadString, curl, wget, or EncodedCommand, then investigates whatever looks unusual in the results.
Detection asks "can we automatically catch this again?" Hunting asks "can we find what our existing detections might have missed?" A mature program cycles between them: threat intelligence → hunt → suspicious behaviour discovered → detection rule created → rule tested → rule deployed → SOC monitors the new alert. This loop is exactly how a SOC's detection capability actually improves over time — hunting finds the gaps, engineering (Lesson 2) closes them.
5 NDR & IDS/IPS
NDR (Network Detection and Response) analyses network flows, DNS, TLS metadata, packet data, protocol behaviour, and east-west (internal) traffic — looking for beaconing, lateral movement, port scanning, unusual protocols, large data transfers, or communication with known attacker infrastructure. NDR is particularly valuable exactly where EDR agents can't be installed (Lesson 2's legacy-endpoint problem again).
Before EDR and XDR existed, network intrusion detection was one of the SOC's primary tools. IDS (Intrusion Detection System) detects suspicious activity; IPS (Intrusion Prevention System) can actively block it. You may encounter Snort, Suricata, or products from Cisco, Palo Alto, Fortinet, and Check Point — Suricata and Snort in particular remain excellent teaching tools because you can watch a signature match against real network packets directly.
6 SOC, IAM & Active Directory
Identity has become one of the most important telemetry sources a SOC has. Analysts regularly investigate password attacks, MFA failures and resets, new authentication methods, privilege escalation, role changes, service accounts, inactive accounts, suspicious sessions, and token activity — all concepts from Module 9 and Module 10, now viewed through the SOC lens:
01:12 User successfully authenticates
01:14 New MFA method registered
01:18 Password reset
01:20 Global Administrator role assigned
01:23 Security logging disabled
The value is entirely in the sequence, not any single line — treated independently, each event could be explained away; correlated, this is a textbook account-takeover-to-privilege-escalation chain.
On-premises Active Directory remains extremely relevant even in cloud-first companies, often still supporting legacy applications, manufacturing environments, datacentres, VPN authentication, and file servers. SOC analysts should be comfortable investigating Domain Admins/Enterprise Admins activity, service accounts, Kerberos, NTLM, Group Policy, and Domain Controllers — Microsoft's Defender architecture continues to include on-premises AD monitoring via Defender for Identity specifically because hybrid identity security stays this important. NTLM usage itself is often worth monitoring, since it can indicate legacy systems or a weaker authentication path being used instead of Kerberos (Module 9, Lesson 5) — Microsoft continues to publish guidance for auditing NTLM in current Windows environments for exactly this reason.
7 A Global Enterprise Scenario
Picture a company with 70,000 employees across 120 countries, 40,000 Windows endpoints, 8,000 macOS endpoints, 5,000 Linux servers, 2 Active Directory forests, Entra ID, AWS, Azure, GCP, Microsoft 365, Salesforce, SAP, a legacy mainframe, and industrial control systems. Security monitoring there might involve Microsoft Sentinel, CrowdStrike, Splunk, legacy ArcSight, cloud-native security services, firewalls, IDS, AD logs, EDR telemetry, and SaaS audit logs — all at once. This mixed, several-generations-deep environment is much closer to reality than the clean single-vendor diagrams in a product demo, and it's exactly the kind of environment Module 10's global IAM challenges and Module 9's legacy-vs-modern authentication both described from their own angles.
8 Interview Questions
More importantly than reciting these: you should be able to demonstrate the answers by actually analysing telemetry, which is exactly what the lab pack from Lesson 5 is for.
Capstone – Build Your Own Mini SOC
Home lab. Build a small practice environment: a Windows 11 workstation, a Windows Server + AD Domain Controller, an Ubuntu Linux server, Sysmon, a SIEM (Microsoft Sentinel, Splunk, Elastic Security, Security Onion, or Wazuh all work), a firewall, and a separate testing machine. Generate controlled events yourself — failed passwords, successful authentication, PowerShell execution, new user creation, group membership changes, SSH login failures, web requests, firewall connections — and watch how legitimate and suspicious activity actually looks from the defender's side. The point isn't learning to attack systems; it's learning to see.
Genuine log exercise. Take a raw log file with several thousand real-shaped events (your home lab output, or the lab pack's data) and, without a prepared dashboard, answer: which users had repeated failed authentication? Which external IP generated the most failures? Did any successful authentication follow those failures? Which privileged accounts authenticated? Was any new admin account created? Did any host run suspicious PowerShell? Which endpoints reached unusual external destinations? This forces you to work from evidence, not a colourful pre-built dashboard doing the thinking for you.
Investigation report. Once you've completed Lab 12 (the capstone) from the lesson-5 pack, write it up properly: Incident Title, Severity, Executive Summary, Affected Users, Affected Devices, Initial Detection, Timeline, Evidence, Indicators, MITRE ATT&CK Mapping, Investigation Findings, Potential Business Impact, Containment Actions, Recommended Remediation, and Additional Investigation Required. This is the exact documentation shape expected in a real, professional SOC.
Module 11 Outcome
The single most important lesson from this whole module:
Security Operations is not about staring at alerts. It's about turning telemetry into evidence, and evidence into decisions.
A SOC analyst constantly moves through the same loop, no matter what technology sits underneath it:
Technology keeps changing — antivirus became EDR, EDR expanded into XDR, SIEM keeps absorbing automation, threat intelligence, behaviour analytics and AI-assisted investigation — but the underlying analyst skills stay remarkably stable: understand the system, understand the network, understand authentication, understand the logs, understand normal behaviour, recognise abnormal behaviour, validate evidence, and communicate clearly. Those skills transfer between Sentinel, Splunk, QRadar, Elastic, Google Security Operations, CrowdStrike, Cortex, and whatever platform comes next.
Across all 6 lessons plus the lab pack, you should now be able to explain SIEM, EDR, XDR and how they relate; describe the main detection approaches and use MITRE ATT&CK vocabulary; triage an alert methodically, building a timeline and distinguishing false positives from false negatives; read Windows, Linux, network, cloud and SaaS logs; investigate a genuine multi-stage incident end to end; and describe SOAR, threat hunting, SOC metrics, and where AI realistically fits into modern security operations. Module 12 (Incident Response) picks up exactly where a confirmed incident leaves off here — containment, eradication, recovery, and the process that follows once the SOC has already done its job.