Start with the big picture: what the service does, where it lives, and the two famous abbreviations that describe it.

Microsoft Sentinel is a cloud service that collects security-related records from across an organization, looks for signs of attack, and helps people and software respond. It is described as a cloud-native SIEM and SOAR. Let us unpack both words.

SIEM stands for Security Information and Event Management. A log is a simple written record that a computer or program makes when something happens, such as “user Asha signed in at 9:02 from Mumbai.” A SIEM is a system that gathers logs from many places into one store, searches across them, and raises an alert, which is a warning that something looks wrong. SOAR stands for Security Orchestration, Automation, and Response. It means using prepared, automatic steps to react to a warning, such as disabling a stolen account or sending a message to the right person. Cloud-native means the service was built to run in the cloud from the start. There are no servers for you to buy, install, or patch, and it grows and shrinks with your data.

Sentinel is part of Microsoft’s security family. It sits on top of Azure Monitor Log Analytics, the Azure service that stores and queries huge volumes of logs. It reads data not only from Azure but also from Microsoft 365, other clouds such as AWS and Google Cloud, on-premises servers, firewalls, and hundreds of third-party products. Microsoft has also been bringing Sentinel together with its Defender security portal, so that one screen shows both alerts from Defender tools and cases from Sentinel. The exact portal experience keeps changing, so check Microsoft’s current documentation.

Where the service came from

Microsoft launched Sentinel in 2019 under the name Azure Sentinel and renamed it Microsoft Sentinel in 2021. Older SIEM products were large appliances or software that companies installed in their own data centers. They were costly, slow to scale, and needed a team just to keep them running. Sentinel was designed to remove that burden: you switch it on over a Log Analytics workspace, connect data sources, and start detecting. It also reflects a wider shift in security, away from only guarding the edge of a network and toward watching identities, devices, and cloud services everywhere.

Before learning the parts, understand the pain. Security teams do not lack data. They drown in it.

A Security Operations Center, shortened to SOC, is the team (and sometimes the room) that watches an organization’s systems for attacks. A medium-sized company can generate billions of log records a month. Attackers know this and hide in the noise. Research reports from the security industry have repeatedly found that attackers can stay inside a network for weeks or months before being noticed, so speed of detection matters a great deal.

Without a central system, four problems appear again and again.

Sentinel answers each one. It brings the evidence into one searchable store. It groups related alerts into a single incident, which is a case file for one possible attack, so people see one story instead of fifty fragments. It lets teams build automatic responses. And because it is a cloud service, there is nothing to install.

Learn these words once and the rest of the guide reads easily.

Sentinel is not one box. It is a set of cooperating layers sitting on shared Azure building blocks.

The bottom layer is the Log Analytics workspace. Think of it as a very large, very fast filing cabinet for log records, with a powerful search engine attached. Sentinel does not keep a separate copy of your data. It adds security features on top of the workspace. When you “enable Sentinel,” you are switching on those features for an existing or new workspace.

Above the workspace sit the ingestion layer (data connectors and agents that bring data in), the detection layer (analytics rules, threat intelligence matching, and machine learning), the investigation layer (incidents, entity pages, investigation graph, hunting, and notebooks), and the response layer (automation rules and playbooks). Workbooks and the content hub cut across all layers.

flowchart TB
    SRC["Data sources - Azure, Microsoft 365, other clouds, firewalls, servers"] --> CON["Data connectors and agents"]
    CON --> WS[("Log Analytics workspace")]
    TI["Threat intelligence"] --> WS
    WS --> DET["Detection - analytics rules, ML, UEBA"]
    DET --> ALR["Alerts"]
    ALR --> INC["Incidents"]
    INC --> INV["Investigation - entities, graph, hunting"]
    INC --> AUT["Response - automation rules and playbooks"]
    WS --> WB["Workbooks and reports"]
    

The figure reads from top to bottom. Sources feed connectors. Connectors fill the workspace. Detections search the workspace and make alerts. Alerts become incidents. Incidents are then handled by people through investigation tools and by software through automation. Workbooks read the same workspace to draw charts.

The supporting Azure services

Everything in Sentinel is, at heart, a search over tables. Understanding this makes the rest feel simple.

Inside a Log Analytics workspace, data is organized in tables. Each table holds one kind of record. There is a table for Microsoft Entra sign-ins, one for Windows security events, one for Azure activity (who created or deleted which resource), one for firewall traffic, and so on. A table has columns, which are the labeled facts in each record, such as time, user name, address, and result. Each record is a row. Some tables are created by Microsoft connectors. Others are custom tables you create for your own applications. Common security tables include SecurityEvent for Windows, SigninLogs for sign-ins, AzureActivity for the control plane, CommonSecurityLog for network devices that send standard-format messages, and SecurityAlert and SecurityIncident for Sentinel’s own output.

KQL, the Kusto Query Language, is how you ask questions. A KQL query reads like a pipeline of steps joined by a vertical bar: start with a table, filter rows, pick columns, count or group, sort, and show. Because each step feeds the next, even long questions stay readable. Analysts use KQL to write detection rules, to hunt, to build workbook charts, and to investigate an incident. You do not need to master it to understand Sentinel, but knowing what it does is essential: a detection rule is just a KQL query that is run on a schedule, and an alert is created when the query returns rows.

Tiers of log storage

Not all data deserves the same price. Sentinel and Log Analytics offer different plans for tables. The Analytics tier is the full-power plan: fast queries, usable for alerts and rules, and the highest cost per gigabyte. Lower-cost plans, often called Basic and Auxiliary logs, are for high-volume, lower-value data, such as detailed network flow records. They cost less to take in but have limits on how you can query them and what features they support. Microsoft has also been developing a data lake option for long-term, low-cost storage of security data. The details of these plans change, so check current documentation before designing.

A watchtower is useless if it cannot see. Connectors are its eyes.

A data connector is a configured link that moves logs from a source into your workspace. Sentinel offers many ready-made connectors, and they come in a few styles.

A data collection rule, abbreviated DCR, is a set of instructions that says which data to collect, how to filter or reshape it on the way, and where to send it. A DCR can drop unwanted fields or whole records before they are billed, which makes it one of the most valuable cost-control tools. Azure resources send their logs through diagnostic settings, switches on each resource that choose which log categories go to which destination. At scale, Azure Policy can switch these on automatically for every new resource.

Beyond raw connectors, Sentinel has a content hub, a catalog of packaged solutions. A solution bundles connectors with matching detection rules, workbooks, hunting queries, and playbooks for one product or scenario. Installing the solution for a product gives you a working starter kit in minutes.

Detection is the brain of Sentinel. It turns piles of records into a short list of things worth a human’s attention.

An analytics rule is the main tool. Several types exist.

Every scheduled rule has the same ingredients: the query that defines suspicious activity; a schedule and lookback window that say how often to run and how far back to look; a threshold, such as “alert when more than ten failed sign-ins”; entity mapping, which tells Sentinel which columns hold users, addresses, or devices; MITRE ATT&CK tagging that labels the technique; and alert grouping settings that decide how alerts become incidents. Rules are written, tested, and tuned. A rule that fires too often wastes time. A rule that never fires may be broken or may be too narrow.

UEBA: learning normal behavior

UEBA, User and Entity Behavior Analytics, builds a profile of how each user and device normally behaves: usual locations, usual working hours, usual systems. It then scores unusual activity, such as a finance clerk suddenly downloading thousands of files at midnight. UEBA adds context to incidents and helps rank which ones matter most.

flowchart LR
    L["Logs in tables"] --> R1["Scheduled and NRT rules"]
    L --> R2["Anomaly and UEBA models"]
    L --> R3["Threat intelligence matching"]
    P["Alerts from Defender products"] --> R4["Microsoft security rules"]
    R1 --> A["Alerts"]
    R2 --> A
    R3 --> A
    R4 --> A
    A --> F["Fusion correlation"]
    F --> I["Incidents"]
    A --> I
    

An incident is the unit of work for a security analyst. Learn what it holds and how it is built.

An alert is a single warning. An incident is a container that groups one or more alerts about the same suspected attack, along with the entities involved, evidence such as the raw events, comments from analysts, tasks to complete, a severity (informational, low, medium, high), a status (new, active, closed), and an owner. Grouping is controlled by the rule: alerts can be combined when they share entities, within a time window, or kept separate. Good grouping turns twenty noisy alerts into one readable case.

Every entity gets an entity page, a profile showing everything Sentinel knows about that user, device, or address: its timeline, related alerts, and behavior scores. The investigation graph draws the incident as a map of connected entities and alerts, and lets an analyst click outward to ask “what else did this account touch?”

Follow one sign-in record from a user’s keyboard to a closed incident.

Suppose an attacker tries a stolen password on an employee account. The identity service, Microsoft Entra ID, writes a sign-in record. A connector forwards this record to the workspace, usually within minutes. The record lands in the sign-in table. Every few minutes a scheduled rule queries recent rows, sees many failures followed by a success from a strange country, and creates an alert. Entity mapping tags the user and the address. The alert grouping logic opens a new incident or adds the alert to an open one for the same user. An automation rule fires on incident creation: it sets severity to high, assigns the identity team, and runs a playbook. The playbook posts a message in the team’s chat and asks for approval to disable the account. An analyst opens the incident, reviews the evidence, approves the action, and closes the case with notes.

sequenceDiagram
    participant U as Attacker
    participant E as Entra ID
    participant C as Connector
    participant W as Workspace
    participant R as Analytics rule
    participant A as Automation
    participant S as Analyst
    U->>E: Sign-in attempts with stolen password
    E->>C: Writes sign-in records
    C->>W: Forwards records into table
    R->>W: Scheduled query finds suspicious pattern
    R->>W: Creates alert and incident
    W->>A: Incident created trigger
    A->>S: Sets severity, assigns owner, posts chat message
    S->>A: Approves disabling the account
    A->>E: Disable account and revoke sessions
    S->>W: Closes incident with notes
    

Where time is lost

Each hop adds delay. Ingestion latency, meaning the gap between an event happening and appearing in the workspace, is usually minutes but varies by source. Scheduled rules add their schedule interval. Near-real-time rules shrink that. Playbooks add seconds. Knowing the delays helps you choose rule types: use NRT for the few detections where minutes matter, and scheduled rules for the rest.

Rules catch what you already know to look for. Hunting looks for what you do not know yet.

Threat hunting means searching for hidden attackers by asking questions, without waiting for an alert. A hunter starts with a hypothesis, a reasoned guess such as “an attacker may be using a trusted tool to move between servers.” The hunter then writes queries to test the guess, studies the results, and either finds a trace or rules the idea out. Good hunts that find something are turned into new analytics rules, so the knowledge becomes permanent.

Sentinel supports hunting with several tools. Hunting queries are saved searches, many supplied by Microsoft and the community, organized by MITRE ATT&CK tactic. The hunts feature lets a team manage a hunt as a project with a hypothesis, queries, results, and notes. Bookmarks let you save interesting rows you found and attach them to an incident as evidence. Livestream runs a query continuously and shows new matches as they arrive, which is useful while an attack is going on. Notebooks, based on Jupyter and Python, bring data science methods such as statistics and charts to security questions that are hard to express in a simple search.

Before reaching for a full workflow, use the lightweight tool built for daily housekeeping.

An automation rule is a simple instruction of the form: when something happens, if conditions match, then do actions. The trigger can be an incident being created, an incident being updated, or an alert being created. The conditions look at things such as severity, rule name, tags, or the entities involved. The actions can change an incident (set severity, status, owner, or tags), add a task list, or run a playbook. Rules are processed in an order you set, and one rule can stop later ones from running.

Automation rules handle the jobs that waste an analyst’s day: closing known harmless incidents, such as those from a test server; assigning each incident to the correct team; adding a standard checklist; or raising the severity when a VIP user is involved. They run inside Sentinel itself, so they are fast and cost nothing extra, unlike playbooks that use Logic Apps.

Playbooks are the SOAR muscle of Sentinel. They do the repeatable work so people can think.

A playbook is a workflow built in Azure Logic Apps, a service where you connect ready-made blocks without writing much code. A playbook starts with a trigger, such as “when an incident is created,” then runs actions, which can use any of hundreds of connectors: send a message to Teams or Slack, create a ticket, look up an address in a reputation service, query Sentinel for more data, change a firewall, or disable an account in Entra ID. Playbooks can include conditions, loops, and a step that waits for a human to approve before a risky action.

A playbook needs permission to act. It uses a managed identity, an automatic Azure identity that carries no password, and you give that identity only the roles it needs, for example the right to read incidents and update them. Sentinel itself also needs permission to run playbooks in a given resource group.

flowchart TB
    T["Trigger - incident created"] --> E["Enrich - look up address reputation and user details"]
    E --> D{"Is it high risk?"}
    D -->|"No"| C["Add comment and tag, leave for analyst"]
    D -->|"Yes"| N["Notify security channel and ask for approval"]
    N --> AP{"Approved?"}
    AP -->|"Yes"| X["Disable account, revoke sessions, block address"]
    AP -->|"No"| H["Hand to analyst with notes"]
    X --> U["Update incident with actions taken"]
    

Common playbook jobs

Raw logs tell you what happened. Context tells you whether it matters.

Threat intelligence, shortened to TI, is knowledge about attackers: addresses they use, domains they register, and fingerprints of malicious files, called indicators of compromise or IoCs. Sentinel can import indicators from Microsoft’s own feeds, from industry sharing groups through a standard called STIX/TAXII, from commercial providers, or from your own list. Analytics rules then match your logs against these indicators and raise alerts when a device in your company talks to a known bad address. Indicators age quickly, so each one has an expiry and a confidence rating, and old ones should be retired.

A watchlist is your own reference table uploaded to Sentinel, often from a spreadsheet. Examples include a list of executives who deserve closer watch, the addresses of your known office networks, service accounts that are allowed to do unusual things, or terminated employees. Queries can join their log data with the watchlist, which adds business knowledge that no vendor can supply. For example, “alert on any sign-in by a terminated employee” is a simple join with a watchlist of leavers.

Charts for people, packages for speed, and source control for safety.

A workbook is an interactive report made of queries, charts, grids, and text. Sentinel includes many templates: overviews of incidents, sign-in patterns, a map of attack origins, and health of data connectors. Managers use workbooks to see trends. Analysts use them to explore data without writing queries. Workbooks are saved inside Azure and can be shared with role-based access.

The content hub is a store of ready-to-install packages. A standalone item is a single connector, rule, or workbook. A solution bundles many items for one product or goal, such as a solution for a particular firewall brand or for Microsoft 365 threats. Updates arrive through the hub, so you can keep detections fresh.

Because rules, playbooks, and workbooks are valuable, treat them like software. The repositories feature of Sentinel connects a workspace to a GitHub or Azure DevOps repository and deploys content from it automatically. Teams write rules as files, review changes through pull requests, test them in a staging workspace, and then deploy to production. This approach, often called detection as code or Sentinel as code, gives history, reviews, rollback, and consistency across many workspaces. Azure Resource Manager templates, Bicep, or Terraform can also create the workspace itself and its settings.

A security tool holds sensitive data and powerful controls. It must be guarded too.

Access in Azure is controlled by Azure role-based access control, or RBAC, which assigns roles to people and software at a chosen scope. Sentinel has its own built-in roles.

Protecting the data

Log data is encrypted at rest and in transit by default. Organizations can add customer-managed keys for extra control. Different logs can have different sensitivity, so you can use table-level RBAC and resource-context access to limit who sees which tables. Network access can be restricted with Azure Private Link, which keeps traffic on Microsoft’s private network. Use Conditional Access and multifactor authentication for every analyst, and consider Privileged Identity Management so that high roles are granted only for a limited time and with approval.

One workspace is simple. Real organizations often need more, for legal, structural, or business reasons.

A tenant is an organization’s dedicated instance of Microsoft Entra ID. Many companies have one tenant, but large groups and service providers handle several. Logs are stored in a specific Azure region, a geographic location of Microsoft data centers, which matters for laws that say data must stay inside a country or union. If different regions or business units need separate storage, you need more than one workspace.

The simplest design is one workspace: lowest cost, easiest queries, best correlation. Reasons to split include data residency laws, separate ownership between divisions, different retention needs, or separate billing. Sentinel supports multi-workspace incident views and cross-workspace queries so analysts can still see the full picture. Workspace Manager helps publish content from a central workspace to many child workspaces. For service providers, Azure Lighthouse lets staff manage customers’ Sentinel instances from their own tenant with delegated, limited, and auditable access.

Who watches the watchman? You do, with a few built-in health features.

The most dangerous failure in a SIEM is silence. If a connector quietly stops, the dashboard looks calm while attackers are unobserved. Sentinel offers several ways to avoid this.

Useful team measures include mean time to detect (how long from the attack to the alert), mean time to respond (how long from the alert to containment), the share of incidents closed as false positives per rule, and the number of incidents per analyst. Set alerts on silence: for each important table, create a rule that raises an alert if no records arrive for a set number of minutes. Test the whole chain on a schedule, for example by running a harmless simulated attack and confirming that an incident appears.

Plan for the day something breaks, because something always does.

Sentinel is a managed service with high availability built in, but your design can still fail in many places: sources, connectors, rules, playbooks, and people. Plan for each.

Sentinel’s bill is mostly about how much data you send in. Understanding that one idea controls most of the cost.

Sentinel is billed mainly by data ingestion, the number of gigabytes you bring into the workspace per day. There are two common ways to pay. With pay-as-you-go, you are charged a fixed price for each gigabyte, with no commitment. With a commitment tier, you promise to ingest a set amount per day, for example 100 gigabytes, and receive a lower price per gigabyte in return. If you go over, the extra is charged at the same discounted rate. If you go under, you still pay for the commitment. Both Sentinel and Log Analytics charge, though they are often shown together as one combined price. Playbooks add the small cost of Logic Apps runs, and long-term storage and special query features have their own prices.

Some data is free or discounted. Certain Microsoft sources, such as Azure activity logs and some Microsoft 365 alert data, have been offered without ingestion charges, and some subscription plans include a free allowance. A new workspace has typically offered a free trial period, and the first period of retention is included. These offers change, so verify them on the official pricing page before planning your budget.

Fast, well-tuned rules are cheaper to run and quicker to alert.

Rules run constantly, so slow queries waste resources and may time out. A few habits make queries efficient. Filter by time first, because narrower time ranges mean less data to scan. Filter early on columns before doing anything heavy. Pick only the columns you need. Use exact matching where possible, since searching for a word across every column of every table is slow. Prefer joins on small sets, and put the smaller table on the left. Use summaries to reduce millions of rows into a few before further steps. Where the same expensive result is used by many rules, consider summary rules, a feature that stores pre-computed results in a separate table.

Tuning detection quality matters as much as speed. Track each rule’s precision, meaning the share of its alerts that are real, and its coverage across MITRE ATT&CK techniques. Exclude known harmless sources with watchlists. Raise thresholds if alerts are too many; lower them if real attacks slip through. Each time an analyst closes an incident as a false positive, the cause should feed back into the rule.

Teams that run Sentinel well share habits. Teams that struggle share traps.

A short checklist from experienced teams, followed by the slips that cost beginners the most.

Mistakes that cost the most

Security tools overlap. Knowing the neighbors helps you place Sentinel correctly.

These tools are often used together. A common combination is Defender tools on endpoints, email, and identities for rich native protection, with Sentinel as the central place to correlate them with firewall, network, other-cloud, and business application data. Features, names, and product boundaries change often, so always check each vendor’s current documentation before deciding.

Three stories show how the parts work together in daily practice.

A good architect knows where a tool shines and where it does not.

A simple decision guide

Microsoft Sentinel is Azure’s control room for security: it gathers signals, spots attacks, builds case files, and helps you respond.

We began with the mall at night: many doors, many sensors, one control room. We then met the parts: the workspace that stores data, the connectors that fill it, the rules and models that detect, the incidents that organize, the hunting tools that search for the unknown, and the automation that responds. We saw how one sign-in record travels to a closed case, how to protect and monitor the service itself, what makes the bill grow or shrink, which habits help, and which traps to avoid. A tool is only as good as the data it sees and the people who tune it.