Azure Sentinel Analytics (Alerting)

Page Contents

Overview

The Azure Sentinel SIEM allows Security Operations team to detect active threats on the network by creating analytics rules (alerting rules). These rules can be deployed using the Azure Portal or alternatively can be deployed through the Sentinel API using a tool like Terraform to manage your infrastructure as code.

Rules are deployed using the KQL language as with everything in a log analytics workspace and allow you create alerts and incidents. The key difference between alerts and incidents is that 1 incident can contain lots of alerts if you choose to group alerts based on asset in the analytic rule.

Configuring Analytic Rules

While configuring the analytic rule there are many alterations that can be made and tweaked which are;

Rule Name – The analytic rule name.
Severity – Severity of the alert in High, Medium, Low and Informational.
Description – A description of what the query is looking for.
Query Frequency – How often the query should run.
Query Period – Determine the time period of data that should be queried.
Trigger Threshold – The baseline number of query results that are generated.
Trigger Operator – Directly used with ‘trigger threshold’ this option sets to when incidents should be generated. Possible options are; Equal, GreaterThan, LessThan and NotEqual.
Tactics – Directly correlated to the MITRE framework these tactics should align to the stage of an attack. Possible options are; Collection, CommandAndControl, CredentialAccess, DefenseEvasion, Discovery, Execution, Exfiltration, Impact, InitialAccess, LateralMovement, Persistence and PrivilegeEscalation.
Query – The query that will be run to detect potentially malicious activity.
Entity Mapping – The entities in an alert that should be used to group multiple alerts into an incident and will improve further analysis. Possible options are; User account (Account), HostIP address (IP), Malware, File Process, Cloud application (CloudApplication), Domain name (DNS), Azure resource, File (FileHash), Registry key, Registry value, Security group, URL, IoT device, Mailbox, Mail cluster, Mail message and Submission mail.
Suppression Duration – Rules can be suppressed for a configurable amount of time once an alert has been generated.
Suppression Enabled – This setting configures where suppression is enabled or disabled.
Playbooks – Playbooks can be configured to an analytic rules in order to perform automated tasks on your behalf.
Alert Grouping – Alert grouping can be enabled or disabled and allows for multiple alerts to be group into a single case that requires investigations.
Create Incidents – The creation of incidents can be enabled or disabled. (Note that an analytic rule can be disabled as a whole as disabling this setting will mean alerts are stilled generated but incidents wont be).

Alerting Rule Templates

Templates analytic rules can be used straight from the Azure portal under the ‘Rule template’ tab. These templates can be easily enabled through the portal and configured to match your environment or a customers environment to reduce false positives or take actions on your behalf. For more template rules you can visit the Azure Sentinel GitHub which is a community repository for all things Sentinel.

Screenshot of the Azure Sentinel portal on the analytics tab.

Fusion Rules

You might of heard of Azure Sentinel and Fusion technology in the same sentence before. This is because Azure Sentinel comes built in with a Fusion technology rule, as per shown above. Fusion is a machine learning technology that allows Security experts to detect multistage attacks that would have previously been extremely difficult to detect. It does this by setting a baseline of normal events in your environment and then outlines anomalous and suspicious behaviours that are observed at different stages in the attack kill chain. By design, these incidents are low-volume, high-fidelity, and high-severity.

Currently there are over 70 different anomalous behaviours that Fusion is looking across multiple data connectors. Some of the main data connectors required for fusion to work are as follows; Azure Active Directory Identity Protection, Microsoft Defender for Endpoint, Microsoft Cloud App Security, Azure Defender (Azure Security Centre)and Palo Alto Networks.

For more information on Fusion check out Microsoft multistage attack detection documentation.

For more detail on Azure Sentinel check out the other blog pages below and the Sentinel GitHub repository which contains a list of analytics rules including many currently not implemented in Azure Sentinel.

Azure Sentinel Overview

Azure Sentinel Log Ingestion

Azure Sentinel Analytic Rules Github

Azure Sentinel Threat Hunting