az sentinel alert-rule list --resource-group <group> --workspace-name <workspace>
Security
SIEM and SOAR
Microsoft Sentinel
Microsoft Sentinel means Microsoft cloud SIEM and SOAR service for collecting security signals, detecting threats, investigating incidents, and automating response. Teams should manage it with clear ownership, monitoring, rollback evidence, and production change discipline.
Source: Microsoft Learn - What is Microsoft Sentinel SIEM? Reviewed 2026-05-16T06:00:22Z
- Exam trap
- Changing Microsoft Sentinel without checking dependent resources, owner approval, monitoring signals, and rollback steps first.
- Production check
- Confirm the resource name, subscription, region, scope, owner tag, and production environment before making any change.
Article details and learning context
- Aliases
- Sentinel, Azure Sentinel, Microsoft Sentinel SIEM
- Difficulty
- fundamentals
- CLI mappings
- 4
- Last verified
- 2026-05-16T06:00:22Z
- Review level
- launch-ready
- Article depth
- field-manual-complete
Learning paths
Learn
Security and Governance
Microsoft Sentinel
Understand the concept
In plain English
Microsoft Sentinel means Microsoft cloud SIEM and SOAR service for collecting security signals, detecting threats, investigating incidents, and automating response. In everyday Azure work, it appears when security teams centralize identity, endpoint, cloud, network, and application telemetry for investigation and response. The useful mental model is the security operations workspace where signals become incidents, investigations, and automated playbooks. Treat it as an operating decision, not a loose label: identify the owner, scope, dependent workload, monitoring signal, and rollback path before changing it in production.
Why it matters
Microsoft Sentinel matters because it brings many security signals into one operational workflow so analysts can detect and respond faster. A weak definition causes teams to change the wrong setting, misread symptoms, or accept defaults that do not fit the workload. The value is not just the feature itself; it is the evidence around it. A strong page explains who owns it, which resource or workflow depends on it, how operators verify health, and what must happen before a production change. That shared understanding makes audits, migrations, scale events, and incidents less chaotic. This keeps owners, operators, and reviewers aligned on the same production evidence.
Official wording and source
Microsoft Learn describes Microsoft Sentinel as a cloud-native security information and event management and security orchestration platform built on Azure Monitor and Log Analytics. Teams use it to detect, investigate, and respond to security threats. Operators should verify scope, permissions, monitoring, and rollback evidence.
Technical context
Technically, Microsoft Sentinel sits in the security operations and observability plane across Log Analytics workspaces, connectors, analytics rules, incidents, watchlists, workbooks, and automation. Azure represents it through workspace association, data connectors, analytics rules, incidents, hunting queries, watchlists, workbooks, playbooks, and automation rules. It usually depends on Log Analytics workspace, data connectors, ingestion settings, roles, automation identities, content hub solutions, and incident response processes. The important boundary is that Sentinel provides security operations workflows; it still depends on data quality, connector health, rule tuning, and response ownership.
Exam context
Compare with
Where it is used
Where you see it
- In the Azure portal, Microsoft Sentinel appears on Sentinel workspaces, incidents, data connectors, analytics rules, hunting queries, workbooks, and automation pages, where operators confirm state, ownership, and release evidence.
- In CLI, SDK, REST, or diagnostic output, Microsoft Sentinel appears as workspace details, analytics rule exports, data connector configuration, role assignments, and automation resource IDs, helping teams compare live state with design.
- In architecture, audit, or incident reviews, Microsoft Sentinel appears when teams discuss SOC operations, detection engineering, incident response, connector coverage, automation safety, and compliance evidence, then decide which evidence proves health.
Common situations
- Centralize security telemetry for investigation and response.
- Create analytics rules that turn signals into incidents.
- Automate repeatable response steps with playbooks.
- Track connector health and SOC coverage.
- Use Microsoft Sentinel during SOC readiness reviews to connect incidents, analytics rules, connectors, and workbooks to accountable owners.
Illustrative Azure scenarios
These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.
Scenario 01 SOC consolidation. Scenario, objectives, solution, measured impact, and takeaway.
Scenario
PineHarbor Financial monitored Azure, Microsoft 365, and endpoint alerts in separate tools, delaying incident triage.
Goals
- Centralize high-priority security signals.
- Reduce mean time to triage by 40%.
- Standardize incident severity rules.
- Automate repeatable containment steps.
Approach using Microsoft Sentinel
Security engineers onboarded key connectors into Microsoft Sentinel, tuned analytics rules, and built automation playbooks for known phishing and impossible-travel patterns. Incidents were routed by severity, workbooks tracked connector health, and CLI evidence exported analytics rules, workspace settings, and role assignments before the SOC launch. The team documented ownership, rollback criteria, monitoring evidence, and support handoff so the change could be reviewed during normal release governance. They added a runbook note that explained the expected healthy signal, the first diagnostic command, and the escalation path for production incidents. Change evidence was captured in JSON output and attached to the release ticket for audit review, incident learning, and future tuning decisions. Implementation notes included sample alerts, expected owner actions, and rollback criteria so production teams could operate the feature confidently after handoff.
Potential outcomes
- Mean time to triage dropped 52%.
- Duplicate alert queues were reduced by 46%.
- Automated containment handled 31% of repeatable phishing incidents.
- SOC managers gained one dashboard for cloud and endpoint incident status.
What to learn
Microsoft Sentinel is strongest when detection, investigation, and response workflows are engineered together.
Scenario 02 Hospital ransomware response. Scenario, objectives, solution, measured impact, and takeaway.
Scenario
Northstar Medical needed earlier warning for ransomware behavior across Entra sign-ins, servers, and backup systems.
Goals
- Correlate identity and server signals.
- Detect ransomware patterns faster.
- Protect playbook permissions.
- Produce incident evidence for regulators.
Approach using Microsoft Sentinel
The security team connected identity logs, endpoint signals, and infrastructure telemetry to Microsoft Sentinel. Analytics rules detected suspicious sign-ins, mass file changes, and disabled backup activity. Automation playbooks used managed identities with narrow permissions, and workbooks showed connector health and incident timelines for compliance review. The team documented ownership, rollback criteria, monitoring evidence, and support handoff so the change could be reviewed during normal release governance. They added a runbook note that explained the expected healthy signal, the first diagnostic command, and the escalation path for production incidents. Change evidence was captured in JSON output and attached to the release ticket for audit review, incident learning, and future tuning decisions. Implementation notes included sample alerts, expected owner actions, and rollback criteria so production teams could operate the feature confidently after handoff.
Potential outcomes
- Ransomware simulation detection time fell from 38 minutes to 7 minutes.
- Playbook permissions were narrowed to approved response actions.
- Incident evidence packages were generated within one business day.
- Security analysts reduced manual correlation work by 57%.
What to learn
Sentinel helps security teams connect signals that would otherwise stay trapped in separate systems.
Scenario 03 Manufacturing OT visibility. Scenario, objectives, solution, measured impact, and takeaway.
Scenario
ForgeLine Industries had cloud monitoring for Azure workloads but limited visibility into operational technology alerts from factories.
Goals
- Bring OT alerts into SOC workflow.
- Prioritize incidents by plant impact.
- Reduce analyst context switching.
- Track connector health across regions.
Approach using Microsoft Sentinel
The SOC onboarded supported OT and cloud connectors into Microsoft Sentinel, mapped watchlists for plant criticality, and created analytics rules for abnormal remote access. Workbooks separated high-impact plant incidents from low-risk noise. CLI output captured workspace, role, and rule configuration during quarterly operational reviews. The team documented ownership, rollback criteria, monitoring evidence, and support handoff so the change could be reviewed during normal release governance. They added a runbook note that explained the expected healthy signal, the first diagnostic command, and the escalation path for production incidents. Change evidence was captured in JSON output and attached to the release ticket for audit review, incident learning, and future tuning decisions. Implementation notes included sample alerts, expected owner actions, and rollback criteria so production teams could operate the feature confidently after handoff.
Potential outcomes
- Analyst context switching dropped 39%.
- High-impact plant incidents were prioritized within five minutes.
- Connector health gaps were visible before shift handoff.
- Remote access investigation time fell 44%.
What to learn
Microsoft Sentinel can become the shared security operations layer for cloud, identity, and industrial signals when data quality is managed.
Azure CLI
Azure CLI is useful for Microsoft Sentinel because it turns portal state into repeatable evidence. Operators can inspect scope, identity, configuration, metrics, dependencies, and related resources before approving a change. CLI output also supports automation, audit packages, rollback reviews, and incident handoffs.
Useful for
- Inventory Microsoft Sentinel across the relevant resource, workspace, account, group, endpoint, or scope before a production review.
- Inspect live Microsoft Sentinel state during troubleshooting, migration planning, access review, release validation, or rollback confirmation.
- Export JSON output so reviewers can compare actual configuration with architecture diagrams, source-controlled definitions, and approved runbooks.
- Run read-only commands first; use create, update, or delete commands only through an approved change path.
Before you run a command
- Confirm tenant, subscription, resource group, workspace, account, namespace, server, endpoint, or policy scope before running commands.
- Verify your role assignment allows the read, write, monitoring, data, or governance action you plan to perform.
- Choose JSON, table, or TSV output intentionally so the result can be reviewed, scripted, or attached as evidence.
- For production changes, confirm owner approval, maintenance window, rollback path, cost impact, and dependent workloads first.
What the output tells you
- Names, IDs, scopes, and regions confirm whether you are looking at the intended Microsoft Sentinel boundary, not a similarly named test asset.
- State, SKU, version, identity, network, metric, and configuration fields show whether live behavior matches the approved design.
- Errors, timestamps, and provisioning states help separate service configuration issues from application, data, identity, or caller problems.
- Saved output gives release, audit, and incident teams a shared record for comparison after the next change.
Mapped commands
Command group
az sentinel incident list --resource-group <group> --workspace-name <workspace>az monitor log-analytics workspace show --resource-group <group> --workspace-name <workspace>az role assignment list --scope <workspace-resource-id>Architecture context
Architecturally, Microsoft Sentinel belongs to the security operations and observability plane across Log Analytics workspaces, connectors, analytics rules, incidents, watchlists, workbooks, and automation. It connects to Log Analytics workspace, data connectors, ingestion settings, roles, automation identities, content hub solutions, and incident response processes. Treat it as a production boundary with explicit ownership, dependencies, monitoring, and rollback evidence. A diagram or runbook should show who can change it, what resources rely on it, and which outputs prove the intended configuration.
- Security
- Security for Microsoft Sentinel focuses on connector permissions, workspace access, automation playbook identities, watchlist data, incident handling, and privileged response actions. The main risk is treating it as harmless configuration while it may affect access, exposure, data handling, or automated response. Review who can read, create, update, delete, invoke, or bypass the related resource, and whether that permission is direct, inherited, or granted through a deployment pipeline. Prefer managed identity, least privilege, private access, encryption, monitored changes, and clear exception ownership wherever the Azure service supports those controls. Keep evidence in the change record. This keeps owners, operators, and reviewers aligned on the same production evidence.
- Cost
- Cost for Microsoft Sentinel is driven by Log Analytics ingestion, retention, analytics rule volume, automation runs, hunting activity, and noisy connector data. Some costs are direct, such as compute, storage, ingestion, action execution, capacity, or retained data. Other costs are indirect: failed retries, duplicated work, noisy alerts, unused resources, delayed migrations, or engineering time spent troubleshooting unclear ownership. FinOps reviews should identify who pays, which metric or SKU drives the bill, and whether a cheaper setting still meets security, reliability, compliance, and performance requirements. Do not cut cost by removing evidence or weakening controls silently. This keeps owners, operators, and reviewers aligned on the same production evidence.
- Reliability
- Reliability for Microsoft Sentinel depends on whether connectors ingest consistently, analytics rules fire correctly, automation runs safely, and incidents remain triageable during attacks. The concern is not only that the setting exists; it is whether the workload behaves predictably during deployment, scale, maintenance, dependency loss, retry, recovery, and operator error. Production teams should know which metric, log, activity record, or CLI output proves healthy behavior. They should also document what failure looks like, how to roll back, and which dependent services must be checked before the incident is closed. Good reliability practice makes the term operational, not decorative. This keeps owners, operators, and reviewers aligned on the same production evidence.
- Performance
- Performance for Microsoft Sentinel depends on query speed, ingestion delay, rule evaluation latency, incident load, workbook responsiveness, and analyst time to triage. The right signal may be request latency, queue depth, startup time, query duration, chart responsiveness, job runtime, throughput, alert delay, or operator time to isolate a bottleneck. Measure before and after important changes rather than assuming the setting improves speed. Keep enough metrics, logs, and command output to explain whether Azure configuration helped the workload, hid the problem, or simply moved the bottleneck to another component. This keeps owners, operators, and reviewers aligned on the same production evidence.
- Operations
- Operationally, Microsoft Sentinel requires monitoring connector health, tuning analytics rules, managing incidents, exporting evidence, and reviewing playbook execution. Operators should know which portal blade, CLI command, SDK property, metric, activity log, deployment output, or runbook step shows the live state. Avoid undocumented portal-only edits in production. Use scripts, tags, source-controlled definitions, diagnostics, and change records so support staff can compare actual configuration with the approved design during releases, audits, and incidents. After any change, capture evidence, confirm dependent workloads still behave correctly, and record the owner responsible for follow-up. This keeps owners, operators, and reviewers aligned on the same production evidence.
Common mistakes
- Changing Microsoft Sentinel without checking dependent resources, owner approval, monitoring signals, and rollback steps first.
- Assuming a portal label tells the whole story instead of validating live state through CLI, logs, diagnostics, or activity history.
- Granting broad permissions for convenience when a narrower role, managed identity, group assignment, or read-only path would work.
- Optimizing cost or speed while ignoring security, reliability, data exposure, recovery behavior, or user-facing impact.
Copied command