SOC Architecture and SecOps Workflows
Design Security Operations Center architectures including SIEM, XDR, SOAR, and threat intelligence — covering operating models, tier structures, incident response, and threat hunting.
SOC Architecture and SecOps Workflows
Why SOC Architecture Matters for SC-100
The SC-100 exam tests your ability to design security operations — not just configure tools. You need to know when to recommend a hybrid SOC over a fully in-house model, how to structure analyst tiers for efficiency, and which Microsoft tools solve which problems. This module builds the foundation for the Defender XDR and Sentinel modules that follow.
The Four Pillars of SecOps Technology
Every modern SOC relies on four technology categories working together:
1. SIEM — Security Information and Event Management
SIEM collects logs from across your entire environment — firewalls, servers, applications, identity systems, cloud services — and correlates them to find threats. Think of it as the central nervous system of your SOC. Microsoft Sentinel is Microsoft’s cloud-native SIEM.
What SIEM does:
- Ingests logs from hundreds of data sources via connectors
- Applies analytics rules to detect suspicious patterns
- Correlates events across time and data sources
- Provides long-term log retention for investigations and compliance
- Powers hunting queries for proactive threat discovery
2. XDR — Extended Detection and Response
XDR takes a different approach than SIEM. Instead of collecting all logs and looking for patterns, XDR deeply understands specific product domains (endpoints, email, identity, cloud apps) and correlates signals across them. Microsoft Defender XDR is the XDR platform.
What XDR does:
- Provides deep visibility within each protected domain
- Automatically correlates alerts into unified incidents
- Offers automated investigation and response
- Can disrupt attacks in progress (attack disruption)
3. SOAR — Security Orchestration, Automation, and Response
SOAR automates the repetitive tasks that analysts do manually. When an incident is detected, SOAR playbooks can automatically enrich it with threat intelligence, isolate a compromised device, disable a user account, send notifications, and create tickets — all without human intervention.
What SOAR does:
- Runs automated playbooks triggered by incidents or alerts
- Orchestrates actions across multiple security tools
- Reduces Mean Time to Respond (MTTR) from hours to minutes
- Frees analysts to focus on complex investigations
In Microsoft’s stack, SOAR is delivered through Logic App playbooks integrated with Sentinel.
4. Threat Intelligence (TI)
Threat intelligence feeds provide context about known threats — malicious IP addresses, file hashes, domains, tactics, and techniques. TI enriches alerts so analysts know whether a detected activity matches a known threat actor or campaign.
What TI does:
- Enriches incidents with context about known threats
- Powers threat indicator matching in SIEM rules
- Informs hunting hypotheses based on current threat landscape
- Maps threats to MITRE ATT&CK framework
Microsoft Defender Threat Intelligence (MDTI) provides TI feeds that integrate with both Sentinel and Defender XDR.
| Capability | SIEM (Microsoft Sentinel) | XDR (Microsoft Defender XDR) |
|---|---|---|
| Data Scope | Broad — ingests logs from ANY source (cloud, on-prem, third-party, custom apps) | Deep but focused — endpoints, email, identity, cloud apps within Microsoft ecosystem |
| Detection Method | Analytics rules, ML models, and hunting queries across all ingested data | Built-in detection models tuned per product domain with cross-domain correlation |
| Investigation | KQL queries, workbooks, entity pages — analyst-driven | Unified incident view, automated investigation graphs, guided investigation |
| Response | SOAR playbooks via Logic Apps — highly customizable automation | Built-in automated response (AIR), attack disruption, one-click remediation |
| Best For | Organization-wide visibility, compliance, custom data sources, hunting | Rapid detection and response across Microsoft-protected assets, reducing analyst workload |
Architect’s insight: SIEM and XDR are complementary, not competing. Defender XDR handles the high-fidelity, fast-response scenarios across Microsoft products. Sentinel provides the broad visibility, custom detection, long-term retention, and SOAR automation across your entire environment. The unified Defender portal brings both together.
SOC Operating Models
One of the most strategic decisions you’ll make as a security architect is choosing the right SOC operating model. There’s no one-size-fits-all answer — it depends on budget, talent availability, data sensitivity, and regulatory requirements.
In-House SOC
The organization builds and operates its own SOC with internal staff. Full control over processes, data, and tooling. Requires significant investment in hiring, training, and 24/7 coverage (minimum 8-12 analysts for round-the-clock operations).
Best for: Large enterprises with sensitive data, strong security budgets, and the ability to recruit and retain talent. Organizations in regulated industries where data cannot leave the environment.
Managed Security Service Provider (MSSP)
A third-party provider operates SOC functions on your behalf. Provides 24/7 coverage without the hiring burden. You trade some control for cost efficiency and immediate capability.
Best for: Small-to-medium organizations that can’t justify a full SOC build. Organizations needing 24/7 coverage quickly. Microsoft offers Defender Experts for Hunting and Defender Experts for XDR as managed services.
Hybrid SOC
Combines internal and external capabilities. Typically the MSSP handles Tier 1 triage and initial response, while internal analysts handle Tier 2-3 investigation, hunting, and incident management. This is the most common model for mid-size organizations.
Best for: Organizations that want to retain control over sensitive investigations while outsourcing the high-volume, repetitive monitoring work.
Virtual SOC
Analysts work from distributed locations (not a physical room) using cloud-based tools. The team may be part-time security staff who have other IT responsibilities. No dedicated physical facility.
Best for: Geographically distributed organizations. Smaller organizations where dedicated security staff isn’t feasible. The rise of cloud-native SIEM (Sentinel) makes this model increasingly viable.
☁️ Rajan’s Hybrid SOC Design
Rajan Krishnamurthy is designing a SOC for a mid-size client — a healthcare company with 3,000 employees, a small IT team of 15, and two security-focused staff.
“With only two security people, we can’t staff 24/7 coverage,” Rajan explains to Deepak Malhotra, the client’s CTO. “But healthcare is a prime ransomware target, and HIPAA requires incident response capabilities. Here’s my recommendation.”
Rajan’s design:
- MSSP for Tier 1 — 24/7 monitoring, alert triage, and initial response for known threat patterns. The MSSP uses Sentinel and Defender XDR through Azure Lighthouse for multi-tenant management.
- In-house for Tier 2-3 — The two security staff focus on investigation, hunting, and incident management during business hours. They receive escalations from the MSSP.
- SOAR automation bridges the gap — Logic App playbooks auto-isolate compromised devices, disable accounts on high-confidence alerts, and enrich incidents with threat intelligence — even at 2 AM when internal staff is asleep.
- Defender Experts for Hunting — Microsoft’s managed hunting service supplements the small internal team with proactive threat hunting.
“The hybrid model gives you 24/7 eyes without the cost of a full SOC build,” Rajan tells Deepak. “And the SOAR playbooks mean critical threats get contained immediately — not hours later when someone checks their phone.”
Priya Anand, Rajan’s junior architect, asks: “What happens when the MSSP escalates something at 3 AM?”
“That’s where the SOAR playbooks are critical,” Rajan replies. “High-confidence detections trigger automatic containment. Medium-confidence escalations go to an on-call rotation with a 30-minute SLA. The MSSP provides the initial context so our on-call analyst isn’t starting from scratch.”
SOC Tier Structure
A well-designed SOC uses a tiered analyst structure. Each tier has distinct responsibilities, skills, and tools.
Tier 1 — Triage Analyst
Mission: Monitor alerts, perform initial triage, and either resolve or escalate.
- Reviews incoming alerts from SIEM and XDR
- Classifies alerts as true positive, false positive, or benign positive
- Performs initial enrichment (IP reputation, user context, asset criticality)
- Follows standard operating procedures (SOPs) for known alert types
- Escalates complex alerts to Tier 2
- Key metric: Mean Time to Triage (MTTT)
Tier 2 — Investigation Analyst
Mission: Deep investigation of escalated incidents to determine scope, impact, and root cause.
- Performs in-depth investigation using advanced queries (KQL in Sentinel)
- Correlates events across multiple data sources
- Determines incident scope — which users, devices, and data are affected
- Leads containment and eradication actions
- Documents findings and creates incident reports
- Key metric: Mean Time to Investigate (MTTI)
Tier 3 — Threat Hunter
Mission: Proactively search for threats that evade automated detection.
- Develops hunting hypotheses based on threat intelligence and environment knowledge
- Creates advanced KQL queries to find hidden adversary activity
- Builds new detection rules based on hunting findings
- Conducts adversary emulation and purple team exercises
- Mentors Tier 1 and Tier 2 analysts
- Key metric: New detections created, dwell time reduction
Tier 4 — SOC Engineering
Mission: Build and maintain the SOC technology platform.
- Develops and tunes SIEM analytics rules to reduce false positives
- Builds SOAR playbooks and automation workflows
- Manages data connectors and log ingestion pipeline
- Creates dashboards, workbooks, and reporting
- Integrates new security tools into the SOC workflow
- Key metric: Platform availability, detection coverage percentage
Exam tip: The SC-100 won’t ask you to configure a Tier 1 workflow. It will ask you to recommend the right tier structure and operating model for a given scenario — budget, team size, data sensitivity, and regulatory requirements all factor in.
Incident Response Lifecycle
The incident response lifecycle defines how your SOC handles security incidents from initial detection to post-incident learning. As an architect, you design these workflows and ensure they’re supported by tooling and automation.
Phase 1: Detection
Threats are identified through automated detections (SIEM rules, XDR alerts), threat hunting, external notifications (vendor alerts, law enforcement), or user reports. The quality of your detection engineering directly impacts everything downstream.
Phase 2: Triage
The Tier 1 analyst evaluates the alert — is it a true positive? What’s the severity? Which assets are affected? Triage determines whether the alert becomes an incident that requires investigation. SOAR can automate initial enrichment (user lookup, device posture, threat intel matching) to accelerate triage.
Phase 3: Investigation
Tier 2 analysts dig deeper. They trace the attack chain — how did the threat actor get in, what did they access, where did they move laterally? In Defender XDR, the incident graph shows the full attack story. In Sentinel, KQL queries correlate events across data sources.
Phase 4: Containment
Stop the bleeding. Isolate compromised devices, disable compromised accounts, block malicious IPs. Containment can be short-term (isolate device from network immediately) or long-term (apply firewall rules, remove persistence mechanisms). SOAR playbooks can execute containment actions in seconds.
Phase 5: Eradication
Remove the threat actor’s foothold. Delete malware, remove backdoor accounts, patch exploited vulnerabilities, reset compromised credentials. Eradication must be thorough — incomplete eradication means the attacker returns.
Phase 6: Recovery
Restore affected systems to normal operation. Restore from clean backups, rebuild compromised systems, verify integrity before returning to production. Monitor closely for re-infection.
Phase 7: Lessons Learned
The most undervalued phase. Conduct a post-incident review: What happened? How did we detect it? What worked? What didn’t? Update detection rules, playbooks, and procedures. Feed findings back into the security architecture.
Threat Hunting Approaches
Threat hunting is the proactive search for threats that bypass automated detection. As an architect, you design the hunting program and ensure analysts have the tools and data they need.
Hypothesis-Driven Hunting
Start with a hypothesis based on threat intelligence: “Given that threat actor APT29 is targeting our industry with supply chain attacks, let’s look for signs of compromised software update mechanisms.” The analyst then builds queries to validate or refute the hypothesis.
Strengths: Focused, intelligence-led, aligns resources to likely threats.
IOC-Driven Hunting
Search for specific Indicators of Compromise — known malicious IP addresses, file hashes, domains, or registry keys from threat intelligence feeds. If you find a match, investigate the surrounding activity.
Strengths: Concrete and measurable. Good for checking exposure to newly disclosed threats.
Anomaly-Driven Hunting
Look for deviations from baseline behavior — unusual login patterns, unexpected process execution, abnormal data transfers. This catches novel threats that don’t match known IOCs.
Strengths: Can detect previously unknown threats. Not dependent on external intelligence.
Evaluating SecOps Tooling
When recommending SecOps tools, evaluate against these criteria:
- Coverage: Does the tool provide visibility into the threat surfaces that matter for this organization?
- Integration: Does it integrate with existing tools, or does it create another silo?
- Automation: Can it reduce manual analyst workload through automated investigation and response?
- Scalability: Can it handle the organization’s data volume and growth?
- Cost model: Is the pricing predictable? (Sentinel charges per GB ingested — data volume directly impacts cost.)
- Skills required: Does the team have the expertise to operate it, or will they need training?
SC-100 Exam Strategy: SOC Architecture
Rajan is designing a SOC for a 3,000-employee healthcare company with two security staff and a limited budget. The organization handles PHI (Protected Health Information) and must comply with HIPAA. Which operating model should Rajan recommend?
A security architect is designing the detection strategy for a large enterprise. The organization uses Microsoft 365, Azure, and several third-party SaaS applications. They also have on-premises servers running custom applications. Which approach best provides comprehensive threat detection?
During an incident response, the SOC has confirmed that an attacker gained access through a phishing email, moved laterally to a file server, and exfiltrated data. The compromised user account has been disabled and the phishing email removed. What should happen NEXT?
🎬 Video coming soon
Next up: Defender XDR: Detection and Response at Scale — We’ll dive deep into how Microsoft Defender XDR correlates signals across the entire Microsoft ecosystem to detect and disrupt attacks automatically.