This chapter covers the Security Operations Center (SOC) model and its core functions, including threat detection, incident response, and security monitoring. Understanding the SOC model is critical for the SC-900 exam, as it appears in approximately 10-15% of questions across domains like security concepts and Microsoft security solutions. You will learn the operational structure, key roles, and how Microsoft Sentinel and Defender XDR support SOC workflows.
Jump to a section
A Security Operations Center (SOC) functions much like a hospital emergency department (ED). The ED triage nurse is the first point of contact: they assess incoming patients (alerts) based on severity—critical (life-threatening) goes immediately to the trauma bay, urgent goes to a fast-track area, and non-urgent waits. This mirrors how a SOC uses a ticketing system with priority levels (e.g., Severity 1-4). The ED has specialists (surgeons, radiologists) who are called in for specific cases; similarly, a SOC has tiered analysts (Tier 1 triage, Tier 2 investigate, Tier 3 threat hunters). The ED maintains a whiteboard tracking patient status (active incidents), which is analogous to a SOC's incident dashboard. When a patient is discharged, a follow-up is scheduled to ensure no relapse—just as a SOC conducts post-incident reviews. The ED also has protocols for mass casualty events (surge capacity), paralleling a SOC's incident response plan for large-scale attacks. Both environments require 24/7 coverage, clear escalation paths, and continuous improvement based on outcomes.
What is a Security Operations Center (SOC)?
A Security Operations Center (SOC) is a centralized team that monitors, detects, analyzes, and responds to cybersecurity incidents. The SOC operates 24/7 and uses a combination of people, processes, and technology to protect an organization's information assets. The primary goal is to reduce the dwell time of threats—the period between initial compromise and detection—and to minimize the impact of security breaches.
The SOC Team Structure
SOC teams are typically organized into tiers: - Tier 1 (Triage): Monitors alerts, validates incidents, and escalates if necessary. They handle initial filtering of false positives. - Tier 2 (Investigation): Conducts deeper analysis, uses threat intelligence, and determines the scope of incidents. - Tier 3 (Advanced Analysis/Threat Hunting): Proactively searches for threats, reverse-engineers malware, and develops detection rules. - SOC Manager: Oversees operations, reports to CISO, and ensures SLAs are met. - Incident Responder: Handles containment, eradication, and recovery.
Core SOC Functions
Monitoring and Detection: Continuously collects logs from endpoints, network devices, servers, and cloud services. Uses SIEM (Security Information and Event Management) like Microsoft Sentinel to correlate events and generate alerts.
Incident Response: Follows a structured process—Preparation, Detection & Analysis, Containment, Eradication, Recovery, and Post-Incident Activity (based on NIST SP 800-61).
Threat Intelligence: Gathers and applies indicators of compromise (IOCs) such as IP addresses, domains, file hashes, and tactics, techniques, and procedures (TTPs) from frameworks like MITRE ATT&CK.
Vulnerability Management: Scans systems for known vulnerabilities and prioritizes patching based on risk.
Forensics and Analysis: Preserves evidence and performs root cause analysis.
Reporting and Compliance: Generates reports for stakeholders and meets regulatory requirements (e.g., GDPR, HIPAA).
Key Metrics and SLAs
Mean Time to Detect (MTTD): Target often < 1 hour for critical incidents.
Mean Time to Respond (MTTR): Target < 1 hour for containment.
Alert Triage Time: Typically 15 minutes for high-severity alerts.
False Positive Rate: Aim for < 10%.
How Microsoft Sentinel Supports SOC
Microsoft Sentinel is a cloud-native SIEM and SOAR (Security Orchestration, Automation, and Response) solution. It ingests data from Microsoft 365, Azure, and third-party sources. Key features: - Data Connectors: Pre-built connectors for Azure Active Directory, Office 365, Microsoft Defender for Cloud, etc. - Analytics Rules: Built-in and custom rules to detect threats (e.g., anomalous sign-ins, ransomware patterns). - Workbooks: Interactive dashboards for visualization. - Playbooks: Automated response workflows using Azure Logic Apps. - Threat Intelligence: Integrates with Microsoft Threat Intelligence and custom TAXII feeds.
Incident Response Steps in Detail
Preparation: Develop incident response plans, train staff, and deploy necessary tools.
Detection & Analysis: Identify suspicious activity through alerts, user reports, or threat intelligence. Analyze to confirm incident and determine scope.
Containment: Isolate affected systems (e.g., disable user account, block IP, disconnect from network).
Eradication: Remove malware, patch vulnerabilities, and eliminate root cause.
Recovery: Restore systems from clean backups, monitor for recurrence.
Post-Incident Activity: Conduct lessons learned, update procedures, and implement improvements.
Integration with Microsoft Defender XDR
Microsoft Defender XDR (Extended Detection and Response) correlates signals across endpoints, email, identities, and cloud apps. The SOC uses Defender XDR to:
Get unified incident view.
Automatically investigate and remediate.
Use advanced hunting queries (Kusto Query Language) for threat hunting.
Automation and SOAR
SOAR capabilities in Sentinel allow automation of repetitive tasks: - Playbooks: Triggered by alerts (e.g., automatically disable a compromised user account). - Incident Creation: Automatically create tickets in ServiceNow or Jira. - Enrichment: Query threat intelligence feeds to enrich alerts.
Common SOC Tools in Microsoft Ecosystem
Microsoft Sentinel: SIEM/SOAR.
Microsoft Defender for Cloud: Cloud security posture management.
Microsoft Defender for Endpoint: Endpoint detection and response.
Microsoft Defender for Office 365: Email and collaboration protection.
Azure Active Directory Identity Protection: Identity-based risk detection.
Example Alert Flow
Data Ingestion: Windows Event Logs sent to Sentinel via Azure Monitor Agent.
Alert Generation: Analytics rule detects multiple failed logins followed by a successful login from a new location.
Incident Creation: Sentinel creates an incident with severity High.
Automation: Playbook runs to disable the user account and notify admin.
Triage: Tier 1 analyst reviews incident, confirms malicious, escalates to Tier 2.
Investigation: Tier 2 uses Defender for Endpoint to check endpoint, finds malware.
Containment: Isolate device via Defender.
Remediation: Remove malware, reset password, enable account.
Post-Incident: Update detection rules and conduct lessons learned.
Exam Tips
Remember the three core SOC functions: Monitor, Detect, Respond.
Know the difference between SIEM (log aggregation/analysis) and SOAR (automation/orchestration).
Understand that Microsoft Sentinel is the primary SIEM in Azure.
Be familiar with the incident response phases (NIST framework).
Know that Defender XDR provides unified detection across domains.
Key Values and Defaults
Sentinel data retention: 90 days free, up to 2 years with pay-as-you-go.
Alert severity levels: Low, Medium, High, Critical.
Incident status: New, Active, Closed.
Playbooks use Azure Logic Apps, which have their own pricing.
Commands and Verification
While SC-900 does not require CLI commands, understanding how to check SOC status via Azure portal is useful:
In Sentinel, under Incidents, view active incidents.
Under Analytics, review enabled rules.
Under Workbooks, open the SOC Overview workbook.
Interaction with Related Technologies
Azure Policy: Enforces compliance rules that generate alerts in Sentinel.
Azure AD Identity Protection: Provides risk events (e.g., leaked credentials) that feed into Sentinel.
Microsoft 365 Defender: Shares alerts with Sentinel via connector.
Summary
The SOC model is foundational to modern cybersecurity operations. Microsoft provides a comprehensive suite of tools—Sentinel, Defender XDR, and Azure AD Identity Protection—to enable effective monitoring, detection, and response. For the SC-900 exam, focus on understanding the roles, functions, and how Microsoft solutions map to SOC capabilities.
Data Ingestion from Sources
The SOC collects logs and telemetry from various sources: endpoints (via Microsoft Defender for Endpoint), cloud apps (Office 365 audit logs), identities (Azure AD sign-in logs), and network devices. Microsoft Sentinel uses data connectors to ingest these logs. For example, a Windows Event Log connector sends security events to a Log Analytics workspace. Data is normalized into a common schema (e.g., CommonSecurityLog) for analysis. The ingestion rate is measured in GB/day, and Sentinel can handle terabytes per day.
Alert Generation by Analytics Rules
Analytics rules in Sentinel define conditions that trigger alerts. For instance, a rule might fire when more than 10 failed logins occur within 5 minutes from a single IP. Rules can be scheduled (run every N minutes) or real-time (event-triggered). Each alert has a severity (Low/Medium/High/Critical) and maps to MITRE ATT&CK techniques. Sentinel includes hundreds of built-in rules (e.g., 'Suspicious sign-in from unfamiliar location').
Incident Creation and Triage
Multiple alerts related to the same attack are grouped into an incident by Sentinel's correlation engine. For example, a brute-force alert plus a successful login from an unusual country become one incident. The incident is assigned a status (New) and a severity (based on highest alert severity). Tier 1 analysts triage the incident: they check the timeline, verify if the activity is malicious, and either close (false positive) or escalate (change status to Active).
Automated Response via Playbooks
Playbooks are automated workflows triggered by incidents or alerts. For example, a playbook can automatically disable a compromised user account in Azure AD, block the attacker's IP on the firewall, and send a notification to the SOC team via Teams. Playbooks use Azure Logic Apps, which integrate with hundreds of connectors. They can be triggered manually or automatically based on conditions (e.g., severity High).
Investigation and Threat Hunting
Tier 2/3 analysts perform deep investigation using tools like Sentinel's Investigation Graph (visualizes relationships between entities—users, IPs, devices) and Advanced Hunting in Defender XDR (KQL queries). They search for lateral movement, persistence mechanisms, and data exfiltration. Threat hunting is proactive: analysts hypothesize about potential attacks (e.g., 'Are there any users with multiple failed logins followed by successful login from a Tor exit node?') and query historical data.
Containment, Eradication, and Recovery
Once the incident is confirmed, the SOC takes containment actions: isolating endpoints via Defender for Endpoint (block device from network), resetting user passwords, revoking session tokens, or blocking IPs on Azure Firewall. Eradication removes the root cause—e.g., uninstalling malware, patching vulnerabilities. Recovery involves restoring systems from clean backups and verifying integrity. All actions are logged for audit.
Post-Incident Review and Improvement
After closing the incident, the SOC conducts a post-mortem meeting to discuss what went well and what can be improved. They update detection rules to catch similar attacks faster, refine playbooks, and adjust SLAs. Metrics like MTTD and MTTR are reviewed. Findings are documented and shared with stakeholders. This step ensures continuous improvement of the SOC's effectiveness.
Scenario 1: Ransomware Attack at a Healthcare Provider
A hospital uses Microsoft Sentinel as its SIEM, with data connectors for Windows Event Logs, Azure AD, and Microsoft Defender for Endpoint. An analytics rule detects multiple endpoints exhibiting behavior consistent with ransomware: rapid file encryption events and connections to known malicious IPs. Sentinel automatically creates a high-severity incident and triggers a playbook that isolates all affected endpoints via Defender for Endpoint, blocks the malicious IPs on the firewall, and disables the compromised user accounts. The SOC team investigates the root cause—a phishing email that delivered the ransomware. They use threat hunting to check for lateral movement and find no other affected systems. After containment, they restore data from backups and reset all user passwords. Post-incident, they update the analytics rule to detect similar phishing patterns and conduct user training. The hospital met its MTTR SLA of 1 hour.
Scenario 2: Insider Threat at a Financial Institution
A bank uses Azure AD Identity Protection and Sentinel to monitor for risky sign-ins. An alert fires when an employee's account signs in from a new location and then accesses sensitive financial data outside of business hours. Tier 1 analyst triages and escalates to Tier 2. The investigation reveals the employee's credentials were used by an external attacker who bypassed MFA via a phishing attack. The playbook automatically disables the account and revokes session tokens. The SOC uses Defender for Cloud Apps to check for data exfiltration and finds no large downloads. The incident is contained within 30 minutes. Post-incident, the bank enforces conditional access policies to block sign-ins from unfamiliar locations and implements stronger MFA methods.
Common Pitfalls
Alert Fatigue: Too many false positives cause analysts to ignore alerts. Mitigation: fine-tune analytics rules, use suppression rules.
Poor Data Quality: Incomplete or misconfigured logging leads to missed detections. Ensure all critical sources are connected.
Slow Playbooks: Complex playbooks can delay response. Test playbooks regularly and optimize Logic App steps.
Lack of Threat Intelligence: Without up-to-date IOCs, the SOC may miss known threats. Integrate threat intelligence feeds.
What SC-900 Tests
SC-900 objective 1.1 (Describe security and compliance concepts) includes SOC and incident response. The exam expects you to:
Understand the purpose of a SOC and its core functions (monitor, detect, respond).
Identify the roles in a SOC (tiered analysts, SOC manager).
Know the incident response phases (NIST framework).
Understand how Microsoft Sentinel and Defender XDR support SOC operations.
Differentiate between SIEM and SOAR.
Common Wrong Answers
"SOC is only for large enterprises" — Wrong. SOC can be virtual or outsourced (MSSP).
"SIEM and SOAR are the same" — Wrong. SIEM aggregates and analyzes logs; SOAR automates responses.
"Incident response starts with containment" — Wrong. It starts with preparation.
"Microsoft Sentinel is a SIEM only" — Wrong. It also has SOAR capabilities.
"Defender XDR replaces the SOC" — Wrong. It augments but does not replace human analysts.
Specific Exam Values
NIST incident response phases: Preparation, Detection & Analysis, Containment, Eradication, Recovery, Post-Incident Activity.
Sentinel data retention: free 90 days.
MITRE ATT&CK framework is commonly referenced.
SLAs: MTTD and MTTR are key metrics.
Playbooks use Azure Logic Apps.
Edge Cases
False positives: Exam may ask how to handle them (tune rules, suppress).
Automation: Know that not all incidents can be automated; human judgment needed.
Cloud vs. on-prem: SOC can monitor both; Sentinel is cloud-native but can ingest on-prem logs.
Eliminating Wrong Answers
If an answer mentions 'prevention' as a SOC function, it's wrong—SOC focuses on detection and response.
If an answer says 'SIEM replaces analysts', it's wrong—SIEM assists analysts.
If an answer says 'incident response phase order is Detection, Containment, Recovery', it's missing Preparation and Post-Incident.
SOC core functions: Monitor, Detect, Respond.
SOC tiers: Tier 1 (triage), Tier 2 (investigation), Tier 3 (advanced/threat hunting).
NIST incident response phases: Preparation, Detection & Analysis, Containment, Eradication, Recovery, Post-Incident Activity.
Microsoft Sentinel is a cloud-native SIEM with SOAR capabilities.
Playbooks in Sentinel use Azure Logic Apps for automation.
Key metrics: MTTD (Mean Time to Detect) and MTTR (Mean Time to Respond).
Defender XDR provides unified detection across endpoints, email, identities, and apps.
Alert severity levels: Low, Medium, High, Critical.
Sentinel retains data for 90 days free (pay-as-you-go for longer).
False positives are reduced by tuning analytics rules and using suppression.
These come up on the exam all the time. Here's how to tell them apart.
SIEM (Microsoft Sentinel)
Collects and aggregates logs from multiple sources
Correlates events to generate alerts
Provides dashboards and workbooks for visualization
Stores data for historical analysis
Focuses on detection and monitoring
SOAR (Playbooks in Sentinel)
Automates response actions based on alerts
Uses playbooks to execute workflows
Integrates with external systems (ticketing, firewalls)
Reduces manual effort and response time
Focuses on remediation and orchestration
Mistake
A SOC is only needed for large enterprises.
Correct
Organizations of any size can benefit from a SOC. Small businesses often use managed security service providers (MSSPs) or virtual SOCs.
Mistake
SIEM and SOAR are interchangeable terms.
Correct
SIEM (Security Information and Event Management) collects and analyzes logs to generate alerts. SOAR (Security Orchestration, Automation, and Response) automates response actions. They are complementary.
Mistake
Incident response begins with containment.
Correct
The NIST framework starts with Preparation (planning, training, tools) before any incident occurs. Containment is the third phase.
Mistake
Microsoft Sentinel is purely a SIEM tool.
Correct
Sentinel also includes SOAR capabilities through playbooks (Azure Logic Apps) and threat intelligence integration.
Mistake
Automation in SOC eliminates the need for human analysts.
Correct
Automation handles repetitive tasks but human analysts are still needed for complex investigations, threat hunting, and decision-making.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A SOC is a team (people, processes, technology) that monitors and responds to security incidents. A SIEM (like Microsoft Sentinel) is a technology that collects and analyzes logs to generate alerts. The SOC uses the SIEM as a tool. The exam may test that SIEM is a component of SOC operations.
The NIST incident response framework (SP 800-61) includes four phases: 1) Preparation, 2) Detection and Analysis, 3) Containment, Eradication, and Recovery, and 4) Post-Incident Activity. For the exam, remember the order and that Preparation is first.
Sentinel provides centralized log ingestion, analytics rules for threat detection, workbooks for visualization, and playbooks for automated response. It integrates with Microsoft 365 and Azure services. The exam expects you to know Sentinel is the primary SIEM/SOAR in Azure.
Tier 1 analysts are responsible for triaging incoming alerts, validating incidents, and escalating to Tier 2 if needed. They filter false positives and handle low-severity issues. They do not perform deep investigation or threat hunting.
MTTD (Mean Time to Detect) is the average time from when an incident begins to when it is detected. MTTR (Mean Time to Respond) is the average time from detection to containment/remediation. Both are key SOC performance metrics. Lower values are better.
No. Automation can handle many tasks (alert triage, simple responses), but complex investigations, threat hunting, and strategic decisions require human expertise. The exam may test that human analysts are essential.
MITRE ATT&CK is a knowledge base of attacker tactics and techniques. SOC analysts use it to understand attack patterns, map alerts to techniques, and develop detection rules. Sentinel includes built-in mappings to MITRE ATT&CK.
You've just covered Security Operations Model and SOC Functions — now see how well it sticks with free SC-900 practice questions. Full explanations included, no account needed.
Done with this chapter?