Microsoft Sentinel

Microsoft Sentinel is a scalable, cloud-native SIEM and SOAR solution that provides intelligent security analytics and threat intelligence across an enterprise. Unlike traditional on-premises SIEMs like Splunk or ArcSight, Sentinel is built on Azure and leverages the cloud's elasticity to ingest massive amounts of data without requiring upfront hardware or capacity planning. It is a PaaS (Platform as a Service) offering, meaning Microsoft manages the underlying infrastructure.

Organizations face an ever-increasing volume of security alerts from various sources: firewalls, endpoints, identity systems, cloud applications, and more. Traditional SIEMs require significant capital expenditure, complex tuning, and manual correlation. Sentinel addresses these challenges by providing: - Scalability: Ingest terabytes of data per day without capacity constraints. - Cloud-native architecture: Built on Azure Monitor and Log Analytics, leveraging existing investments. - Advanced analytics: Built-in machine learning and user and entity behavior analytics (UEBA). - Automation: SOAR capabilities with playbooks to automate incident response. - Integration: Native connectors for Microsoft 365 services (Azure AD, Microsoft 365 Defender, Office 365) and hundreds of third-party sources.

Sentinel's architecture consists of several key components that work together:

1. Data Ingestion: Data sources connect via connectors. Connectors can be: - Azure-native connectors: For Azure resources (e.g., Azure Activity Log, Azure AD logs) – these require minimal configuration. - Common Event Format (CEF): Syslog-based format for many security appliances (e.g., Palo Alto, Cisco ASA). - Syslog: Direct syslog ingestion, often used for Linux-based sources. - REST API connectors: For cloud services (e.g., AWS CloudTrail, Salesforce). - Microsoft 365 connectors: For Exchange Online, SharePoint, Teams, etc. - Agents: The Log Analytics agent (Windows/Linux) or the newer Azure Monitor Agent (AMA) can forward logs from VMs.

Data is sent to a Log Analytics workspace, which acts as the central repository. Each workspace is associated with an Azure subscription and region. Sentinel is enabled on top of a Log Analytics workspace, transforming it into a SIEM.

3. Threat Detection: Sentinel uses analytics rules to detect threats. There are several types: - Scheduled query rules: Run a Kusto Query Language (KQL) query at regular intervals (e.g., every 5 minutes) and generate an alert if the query returns results. This is the most common type. - Near-real-time (NRT) rules: Run every minute for low-latency detection. - Microsoft Security rules: Built-in rules that cover common attack patterns (e.g., ransomware, brute force). - Anomaly detection rules: Use machine learning to detect unusual behavior (e.g., abnormal login times, unusual data exfiltration). - Fusion rules: Correlate multiple alerts from different sources to detect multi-stage attacks (e.g., a phishing email followed by credential theft). - ML Behavior Analytics: UEBA profiles entities (users, devices, IPs) and detects deviations from baseline.

Each rule has a severity (Informational, Low, Medium, High) and can be configured to automatically create incidents.

Sentinel is managed via the Azure portal, Azure CLI, PowerShell, or REST API. There is no direct command-line for Sentinel itself, but you can manage resources:

Azure CLI example to list Sentinel incidents:

az sentinel incident list --resource-group <rg> --workspace-name <workspace>

PowerShell to enable Sentinel on a workspace:

New-AzSentinelOnboardingState -ResourceGroupName <rg> -WorkspaceName <workspace>

KQL query example for failed logins:

SigninLogs
| where ResultType == "50057"
| summarize Count = count() by UserPrincipalName, IPAddress
| where Count > 10

Sentinel pricing is based on data ingestion volume (per GB) and includes a free tier of 5 GB/day for the first 31 days. Additional costs apply for retention, long-term storage, and Logic Apps executions.

A bank with 10,000 employees uses Sentinel to centralize logs from on-premises firewalls, Azure workloads, Microsoft 365, and endpoints. They ingest approximately 2 TB of logs daily. The SOC team uses Sentinel's built-in analytics rules (e.g., 'Brute force attack against Azure AD') and custom rules for suspicious wire transfers. They have playbooks that automatically disable a user's account if Sentinel detects a potential account compromise. A common misconfiguration is not tuning the analytics rules, leading to alert fatigue. For example, a rule that alerts on failed logins without filtering out known test accounts generates thousands of false positives. The solution is to use KQL to exclude known IPs or users. Performance is generally good, but complex KQL queries with large lookback periods (e.g., 14 days) can cause delays. They mitigate by using materialized views or summarization tables.

A retailer uses AWS, GCP, and Azure. They use Sentinel as the single pane of glass by deploying connectors for AWS CloudTrail and GCP Audit Logs via custom API connectors. They also ingest data from their SaaS applications (Salesforce, Workday). A key challenge is log format normalization: AWS logs arrive in JSON, while syslog from on-premises firewalls is in CEF. Sentinel handles this via the Log Analytics agent and built-in parsers. They use UEBA to detect insider threats, such as an employee accessing HR data after hours. A misconfiguration they encountered was not enabling the 'User and Entity Behavior Analytics' data connector, which is required for UEBA. After enabling, they had to wait 14 days for baseline profiling. They also use threat intelligence feeds from Microsoft and a third-party provider to block known malicious IPs at the firewall via a playbook.

An MSSP manages Sentinel for 50 clients. They use Azure Lighthouse to manage multiple workspaces from a single portal. Each client has its own Log Analytics workspace and Sentinel instance. They deploy a centralized 'SOC workspace' that collects alerts from all client workspaces using cross-workspace queries. A common issue is data egress costs: querying across workspaces in different regions incurs network charges. They mitigate by collocating workspaces in the same region. They also use automation rules to route high-severity incidents to the SOC team's Teams channel. A pitfall is that playbooks run in the context of the workspace's subscription, so they need appropriate RBAC permissions across multiple tenants. They use managed identities and service principals to handle this.