Microsoft Sentinel SIEM

Microsoft Sentinel is a scalable, cloud-native SIEM and SOAR solution that provides intelligent security analytics and threat intelligence across an enterprise. It replaces traditional on-premises SIEMs like Splunk or ArcSight by leveraging Azure's elastic infrastructure and built-in AI. Sentinel collects data from any source—Azure services, Microsoft 365, on-premises systems, and third-party security tools—and centralizes it in a Log Analytics workspace for analysis.

Sentinel operates on a four-pillar architecture: Collect, Detect, Investigate, and Respond.

#### Collect Data ingestion uses data connectors that pull logs into a Log Analytics workspace. There are over 100 built-in connectors for Microsoft sources (Azure Activity, Azure AD, Microsoft 365 Defender, Microsoft Defender for Cloud) and third-party sources (Syslog, CEF, AWS CloudTrail, etc.). Each connector maps data to specific tables (e.g., SigninLogs, SecurityEvent, CommonSecurityLog). Data can also be ingested via API or Azure Event Hubs.

#### Detect Detection is powered by analytics rules. These are Kusto Query Language (KQL) queries that run on a schedule (e.g., every 5 minutes) against the ingested data. When a query returns results that match a threshold (e.g., >5 failed logins from a single IP in 10 minutes), Sentinel creates an incident. Rules can be scheduled, Microsoft Security (built-in from Microsoft), or NRT (Near-Real-Time) for sub-minute latency.

#### Investigate Incidents are investigated using the incident management pane, which shows related alerts, entities (users, IPs, hosts), and a graphical investigation graph. Hunting queries allow proactive threat hunting using KQL, and livestream sessions let analysts monitor specific events in real time.

#### Respond Response is automated via playbooks built on Azure Logic Apps. Playbooks can trigger on incident creation or alert generation, performing actions like blocking a user, isolating a VM, or sending a Teams message. Automation rules allow simple condition-based actions without a full playbook.

Sentinel is primarily configured through the Azure portal, but you can use Azure CLI or PowerShell.

Enable Sentinel on a Log Analytics workspace:

az sentinel enable --workspace-name <workspace> --resource-group <rg>

List data connectors:

az sentinel data-connector list --workspace-name <workspace> --resource-group <rg>

Create a scheduled analytics rule:

az sentinel alert-rule create --workspace-name <workspace> --resource-group <rg> \
  --name "My Rule" --display-name "My Rule" --description "Detects X" \
  --query "SecurityEvent | where EventID == 4625" --query-frequency PT5M \
  --query-period PT1H --severity Medium --trigger-operator GreaterThan \
  --trigger-threshold 0

Verify data ingestion: Use the Log Analytics query Usage table:

Usage | where DataType == "SecurityEvent" | summarize sum(Quantity) by bin(TimeGenerated, 1h)

Scenario 1: Enterprise SOC for a Large Financial Institution

A bank with 50,000 employees uses Sentinel to centralize logs from Azure, on-premises Active Directory, and custom banking apps. They ingest ~5 TB of data per day across multiple Log Analytics workspaces (one per region). They use capacity reservation at 1 TB/day to reduce costs. Their SOC team of 20 analysts uses Sentinel's incident queue to triage ~500 incidents daily. They have 50 analytics rules, including custom rules for wire transfer anomalies. Automation rules trigger playbooks that block compromised accounts in Azure AD and send Slack notifications to the fraud team. A common misconfiguration: they initially set all analytics rules to create incidents for every single alert, overwhelming the SOC. They later tuned rules to group alerts by entity and increased thresholds.

Scenario 2: Managed Security Service Provider (MSSP)

An MSSP monitors security for 200 small-to-medium customers. They deploy Sentinel in a central Azure tenant and use Azure Lighthouse to manage each customer's Sentinel workspace from a single pane. They ingest ~100 GB/day per customer. They use built-in analytics rules from the Sentinel content hub to provide baseline detection. For each customer, they deploy a standard set of playbooks that isolate compromised VMs and notify the customer's IT team. Performance consideration: they need to ensure each workspace has sufficient retention and that cross-workspace queries (using workspace()) are optimized. Common pitfall: failing to properly scope automation rules to specific customers, causing playbooks to run on the wrong workspace.

Scenario 3: Retail Company with Cloud and SaaS

A retailer uses Microsoft 365, Azure, and AWS. They use Sentinel to ingest Office 365 audit logs, Azure AD sign-ins, and AWS CloudTrail logs via Event Hubs. They have a custom analytics rule that detects brute-force attacks by correlating failed sign-ins from multiple sources. They use Sentinel's UEBA (User and Entity Behavior Analytics) to detect insider threats, such as an employee downloading large amounts of data before resignation. When misconfigured, they saw high false positives from UEBA because they didn't exclude service accounts. They resolved it by creating watchlists of known safe accounts.