Microsoft Sentinel

Microsoft Sentinel is Microsoft's cloud-native SIEM for SOC teams on Azure, with KQL hunting, UEBA and a security data lake, billed per gigabyte ingested.

Microsoft Sentinel pulls security logs from across an organization into one service, finds attacks in them and drives the response. Microsoft builds and runs it as a SIEM on Azure, where data lands in a Log Analytics workspace and in the Microsoft Sentinel data lake. Analysts can work in the Microsoft Defender portal beside Defender XDR, which becomes its only home when Azure portal support ends on March 31, 2027. Data connectors and content hub solutions bring in logs from Microsoft services out of the box. Syslog, CEF and a REST API cover other sources. The Advanced Security Information Model (ASIM) maps those events to shared schemas through KQL parsers that analysts write and test on existing data. Analytics rule templates, Fusion multistage detection and matching analytics against threat intelligence turn the data into alerts. User and Entity Behavior Analytics (UEBA) learns normal behavior and surfaces anomalies. Alerts become incidents that analysts assign, investigate and close, while automation rules and playbooks on Azure Logic Apps handle the response. Sentinel is built for security operations centers that already run on Azure and Microsoft 365. Teams using Defender XDR get detection, investigation and response in one portal instead of two consoles. Organizations with large daily log volumes can keep active data in the analytics tier for detection and move older data to the data lake tier. Detection engineers who write rules and hunts in KQL get the most from it. Regulated businesses can add content hub solutions such as the Microsoft PCI DSS Compliance workbook, and SAP customers can add the solution for SAP applications. A shift can start in the incident queue, where connectors for Microsoft Entra ID and Defender XDR bring identity and endpoint signals into each case. From there an analyst pivots into KQL to hunt across past activity, checks the MITRE ATT&CK coverage view for gaps in the active rules, and hands repeat steps to a playbook. Older history stays in the data lake, where Jupyter notebooks and KQL queries run over it. Data federation through Microsoft Fabric lets the same team query Azure Databricks or AWS S3 data where it sits, so an investigation can draw on that context without first copying it in.