Cloud Threat Detection: SIEM, SOAR and Security Monitoring Architecture

The Invisible Breach: Why Detection Is the Critical Gap

The average time to detect a cloud breach is 197 days. During those 197 days, the attacker moves laterally through the environment, escalates privileges, exfiltrates data, and establishes persistence — all while the security team sees green dashboards because their monitoring doesn't cover the cloud attack surface. The breach is discovered when: a customer reports their data on the dark web, a regulatory body notifies the organization, or an analyst notices an anomalous cloud bill. By then, the damage is done.

Detection is the critical gap because prevention isn't perfect. Firewalls, MFA, encryption, and segmentation reduce the attack surface — but determined attackers find ways through. When prevention fails, detection determines whether the breach is contained in hours (before significant damage) or discovered in months (after catastrophic data loss). The investment in detection infrastructure — SIEM, threat analytics, automated response — determines the organization's resilience when (not if) a security incident occurs.

Cloud Threat Detection Architecture

Microsoft Sentinel: Cloud-Native SIEM

Microsoft Sentinel is a cloud-native SIEM that collects, analyzes, and responds to security data across the enterprise — Azure resources, Microsoft 365, on-premises systems, and third-party security tools. Unlike on-premises SIEM (Splunk, QRadar) that requires sizing, maintaining, and scaling hardware, Sentinel scales automatically with data volume — you pay for data ingestion, not infrastructure capacity.

Data Connectors

Sentinel ingests security data from 200+ built-in connectors: Microsoft native (Azure Activity, Entra ID, Defender for Cloud, Microsoft 365, Defender XDR — zero-configuration, high-fidelity), third-party security (Palo Alto, Fortinet, CrowdStrike, Cisco — via CEF/Syslog or API), cloud platforms (AWS CloudTrail, GCP Audit Logs — for multi-cloud visibility), and custom sources (via Log Analytics agent, REST API, or Azure Functions — for proprietary applications). The coverage principle: every system that processes data, authenticates users, or communicates over the network should feed into Sentinel. Gaps in coverage are gaps in detection.

Kusto Query Language (KQL)

Detection rules in Sentinel are written in KQL — a powerful query language optimized for log analytics. Example detection: "alert when a user signs in from 2 different countries within 1 hour" (impossible travel detection), "alert when a service principal's permissions change outside of change windows" (privilege escalation), "alert when data export volume exceeds 10x the user's 30-day average" (data exfiltration). KQL combines the expressiveness of SQL with time-series analysis functions — making it possible to write detections that correlate events across time, across users, and across systems.

Detection Engineering: Rules, Analytics, and ML

Detection operates at three sophistication levels — each catching threats the previous level misses.

Level 1 — Scheduled rules: KQL queries that run on a schedule (every 5 minutes, every hour). Match known attack patterns: brute force login attempts, known malicious IPs, specific attack techniques from the MITRE ATT&CK framework. These catch: known threats, compliance violations, and policy deviations. Coverage: 60-70% of detectable threats.

Level 2 — ML-powered analytics: Sentinel's built-in ML models detect anomalies that rules can't express: unusual sign-in patterns (user who normally works 9-5 EST signs in at 3 AM from a new country), anomalous data access (user downloads 50x more files than their peer group average), and abnormal command execution (admin runs PowerShell commands they've never used before). ML analytics catch: unknown threats, insider threats, and slow-burn attacks that stay within individual rule thresholds. Coverage: additional 15-20%.

Level 3 — Threat intelligence correlation: Cross-reference internal security events with external threat intelligence feeds — known attacker IPs, domains, file hashes, and TTPs (Tactics, Techniques, and Procedures). An IP address that appears benign in isolation becomes suspicious when threat intelligence identifies it as part of a known attacker's infrastructure. Coverage: additional 5-10%.

SOAR: Automated Incident Response

SOAR (Security Orchestration, Automation, and Response) automates the response to detected threats — reducing response time from hours (human analyst triages, investigates, and responds) to seconds (playbook executes automatically on detection).

Response Playbooks

Sentinel playbooks (built on Azure Logic Apps) define automated response workflows triggered by detection alerts:

6 Detection Use Cases for Enterprise Cloud

Measuring Detection Effectiveness

Multi-Cloud Detection: Azure + AWS + GCP Under One SIEM

Many enterprises operate multi-cloud environments — primary workloads on Azure, specific services on AWS (S3, Lambda), and some teams using GCP. Microsoft Sentinel provides multi-cloud visibility through native connectors: AWS CloudTrail and GuardDuty logs ingest into Sentinel for cross-cloud correlation, GCP Audit Logs and Security Command Center findings feed into the same detection engine, and third-party SaaS security signals (Okta, CrowdStrike, Palo Alto) join the data set. The detection benefit: an attacker who compromises an AWS access key and uses it to access Azure resources is detected through cross-cloud correlation — the AWS key creation event and the Azure resource access are connected in a single investigation timeline. Single-cloud monitoring misses this pattern entirely.

SOC Operating Model: People + Technology

SIEM and SOAR are tools. The Security Operations Center (SOC) is the team that operates them. The SOC operating model for cloud environments: Tier 1 analysts review alerts triaged by automation (SOAR handles initial response; Tier 1 validates and investigates), Tier 2 analysts investigate complex incidents that Tier 1 escalates (multi-stage attacks, advanced persistent threats), Tier 3 / threat hunters proactively search for threats that detection rules haven't caught (hypothesis-driven investigation using KQL queries against historical data). For mid-size enterprises (500-5,000 employees), the SOC can be: fully in-house (3-8 security analysts), hybrid (1-2 in-house + managed detection service), or fully managed (MSSP operates the SIEM and responds to alerts). The model depends on: budget, internal security expertise, and the organization's risk tolerance for outsourcing security operations.

Detection Rule Lifecycle: Build, Tune, Retire

Detection rules aren't static. New attack techniques emerge (new rules needed), existing rules generate false positives (tuning needed), and old techniques become irrelevant (rules retired). The detection engineering lifecycle: deploy new rules in alert-only mode (generate alerts but don't trigger automated response) for 2 weeks, tune to reduce false positives based on the alert-only period, promote to active mode (triggers automated response), review effectiveness quarterly (rules that haven't triggered in 6 months may be retired), and update based on threat intelligence (new MITRE ATT&CK techniques get new detection rules). A healthy detection engine adds 5-10 rules per month, tunes 10-15, and retires 2-3 — continuously improving coverage while managing alert fatigue.

Threat Intelligence Integration

Threat intelligence feeds enrich detection by correlating internal security events with known external threats. Microsoft Sentinel integrates threat intelligence through: Microsoft Threat Intelligence (built-in — known malicious IPs, domains, file hashes from Microsoft's global visibility), STIX/TAXII feeds (industry-standard threat intelligence sharing — connect to ISAC feeds for your industry), and custom indicators (your security team's internal threat intelligence — IOCs from past incidents, industry alerts, vulnerability disclosures). Every network connection, DNS resolution, and file hash in your environment is compared against threat intelligence — transforming individual events from "a connection was made" into "a connection was made to a known command-and-control server." This context is what separates high-fidelity alerts from noise.

Go Deeper

Continue building your understanding with these related resources from our consulting practice.