Azure Sentinel provides a SIEM and SOAR solution allowing coordinated responses to security events aimed at SecOps teams.
- Automatically scales storage to meet requirements.
- Uses Microsoft Intelligent Security Graph as a source of signals, which has input from >= 600 Azure services.
- Applies anomaly detection to reduce false positives.
- Allows automated investigation and response.
- Visualisations through dashboards and surfacing through querying.
- Events are generated by operational events.
- Analytic rules process events to create rules.
- Alerts represent anomalies that require investigation.
- Incidents can be triggered based on properties of alerts.
- Playbooks can run in response to alerts or incidents to investigate or remediate.
- Can work off only a single Log Analytics workspace.
- Place the Sentinel resources in their own subscription to limit access to them.
- Use regional Sentinel workspaces to reduce transfer costs for data ingest.
- Use Azure Lighthouse to audit Sentinel instances.
Connectors ingest data from a range of sources:
They're grouped into a number of broad collection mechanisms:
- Native (or service to service) integrations are available for many Azure resources.
- Direct integrations can be configured at source, and push data to the workspace.
- API integrations allow the workspace to pull in data.
- Agent-based integrations run on infrastructure (e.g. Log Analytics agent, syslog, CEF, Windows agent)
Workbooks allow visualisation of Sentinel data, and can be given input parameters allowing reuse across a number of underlying resources. They can be created from scratch or copied from existing templates, then customised.
Analytic rules are defined in KQL. Results generated from these queries generate Sentinel alerts, which can in turn create incidents:
- Scheduled rules run on a fixed schedule, ingesting events raised within the configured lookup window.
- Microsoft Security rules use events from Microsoft sources, such as Security Centre.
- ML Behaviour Analytics
Rule alerts can be grouped to ensure they're appropriately deduplicated.
Incidents contain a series of alerts, and should indirectly contain all the data required to complete an investigation and remediation, if required. They have:
- An assignee.
- A status.
- A set of comments for status updates.
- A severity level, Informational, Low, Medium or High.
- Queries and bookmarks for investigation
The investigation view shows a graph of alerts in the context of their related entities entities, with timelines of events where appropriate.
Bookmarks reference source data, and can be associated with incidents.