Chapter 3. Analytics
The power of Azure Sentinel comes from the ability to detect, investigate, and remediate threats. To do this, you must ingest data in the form of alerts from security providers, such as Microsoft solutions or third-party solutions. The alerts must be in the form of raw logs from services and endpoints that you need to monitor.
Analytics in Azure Sentinel allow you to define detection rules across ingested data and create cases for investigation by security analysts. Some of those rules might be simple and create a case for an alert that comes from a connected solution. Others might be more complex and join data from various sources to determine whether a threat exists. For example, you might look for an unregistered DHCP server using a rule that looks for network traffic sent on UDP port 67 to an IP address that is not in another data set that contains DHCP-registered server IP addresses.
As you create analytic rules, it will be important to understand how many incidents each rule will generate in your environment. This will help prevent your analysts from becoming alert fatigued. In this chapter, you will learn about the components that make up an analytic rule, how to create an analytic rule, and how to validate it.
Why use analytics for security?
When the WannaCrypt ransomware outbreak happened in 2017, security researchers were able to investigate how that worm exploited the vulnerability CVE-2017-0145, and they discovered a series of patterns used by this worm. By reverse engineering the worm’s behavior, they were able to identify how the worm made changes to the target system. Based on those artifacts, they were able to establish a list of those changes and document them as indicators of compromise (IOC). This list includes changes in the registry and the file system.
Note
To learn more about how Microsoft Security Researchers identified the indicators of compromised for WannaCry, see https://aka.ms/asbook/wannacryioc.
The use of analytics can be extremely beneficial for creating custom alerts that will trigger indicators of compromise that are found in the system. This is a powerful way to identify systems that were compromised without warning from other security controls (such as antimalware that relies on signatures). While this is considered a reactive work, because the system was already compromised, you can also use analytics to identify whether a system is under attack. You can do this by creating alerts that use indicators of attack (IOA). By using analytics to create alerts based on an IOA, you can identify a potential attack in execution; for example, you can identify an attempt to elevate privileges to execute a built-in Windows tool, such as PowerShell, to download a piece of malware from a compromised site.
Also, the use of analytics can be useful to trigger alerts based on techniques that are used by known malicious actors. For example, WannaCry used the tool attrib to perform file permission modification. You can investigate more details about the use of attrib, and you can create alerts based on custom queries that will trigger once that technique is used.
Tip
You can use the MITRE ATT&CK web site to learn more about the tools and techniques used by different kinds of malware; to see the techniques used by WannaCry, see https://attack.mitre.org/software/S0366/. MITRE ATT&CK is a globally accessible knowledge base of adversary tactics and techniques based on real-world observations. The ATT&CK knowledge base is used as a foundation for the development of specific threat models and methodologies in the private sector, in government, and in the cybersecurity product and service community.
Understanding analytic rules
In Azure Sentinel, the rules users create are called analytic rules. A rule is comprised of several parts that define how the rule should trigger and how the incident should be handled. To access the Analytics dashboard, follow these steps:
Open the Azure Portal and sign in as a user who has Azure Sentinel contributor privileges.
In the search pane, type Azure Sentinel and click the Azure Sentinel icon when it appears.
Select the workspace on which Azure Sentinel is enabled.
In the left navigation pane, click Analytics. The Azure Sentinel – Analytics blade appears, as shown in Figure 3-1.
FIGURE 3-1 Azure Sentinel Analytics blade There are several components in the Analytics blade. In the top pane, as shown in Figure 3-2, click +Create to create an analytic.
FIGURE 3-2 Top pane of the Analytics blade The middle pane shows the number of active analytic rules you have created or enabled. It also shows a breakdown of the analytic rules by severity (High, Medium, Low, and Informational). See Figure 3-3.
FIGURE 3-3 Middle pane of the Analytics blade The bottom pane shows two tables. As you can see in Figure 3-4, one table shows the Active Rules, and the other shows Rule Templates.
FIGURE 3-4 Bottom pane of the Analytics blade As you can see in Figure 3-5, the Active Rules tab has rules that have been enabled or created in your Azure Sentinel workspace. The table shows the name of each analytic rule and allows you to filter analytics by using the filter bar. The Name column shows the rule name was provided when the rule was created. The Rule Type column shows the type of analytic, Fusion, Microsoft Security, ML Behavior Analytics, or Scheduled. The Status column shows whether the analytic rule is Enabled or Disabled. The Tactics column shows which MITRE Tactics the rule helped detect. The Last Modified column shows the date and time the rule was last modified. You can search by any part of the rule name. You can filter the rules by Severity, Type, Status, and/or Tactics.
FIGURE 3-5 Bottom pane of the Analytics blade Click the Rule Templates tab to see the list of templates available, as shown in Figure 3-6. The tab shows the available templates. Some of these templates are detections created by Microsoft, some are rules for Microsoft solutions, and some are community-based templates. We will cover the types of rule templates later in this chapter. The Name column shows the rule name that was provided when the rule was created. The Rule Type column shows the type of analytic: Fusion, Microsoft Security, ML Behavior Analytics, or Scheduled. The Required Data Sources column shows which data sources are needed for the analytic rule. The Tactics column shows which MITRE Tactics the rule helped detect. You can search by any part of the rule name. You can filter the rules by Severity, Type, Status and/or Tactics.
FIGURE 3-6 Bottom pane of the Analytics blade The ellipsis column (…) provides a quick context menu that offers the following options: Edit, Disable, Clone, and Delete. Also, you can right-click the analytic to see the context menu, as shown in Figure 3-7.
FIGURE 3-7 Context menu of the Analytics blade
Configuring analytic rules
If you are familiar with Azure Security Center, you know that the security alerts are built in; in other words, you don’t need to create rules in order to receive alerts. Azure Sentinel enables you to customize your own analytic rules based on your needs. These analytic rules will be the ones that will triggers alerts. Now that you are familiar with the Analytics blade, let’s create your first analytic rule.
Open the Azure Portal and sign in as a user who has Azure Sentinel contributor privileges.
In the search pane, type Azure Sentinel and click the Azure Sentinel icon when it appears.
Select the workspace on which Azure Sentinel has been enabled.
In the left navigation pane, click Analytics.
Click the Create button and select Scheduled query rule, as shown in Figure 3-8.
FIGURE 3-8 Create button The first part of the rule creation wizard is the General section, as shown in Figure 3-9. The Name field is simply the name of the detection rule and the display name of the case that will be generated if triggered. It is important to use a descriptive name that will allow your security analysts to understand what the alert is about. You can further describe what the case is about by using the Description field to provide more detail for your security analysts. The Tactics drop-down menu allows you to select the MITRE tactic(s) that the rule helps detect. The Severity drop-down menu offers four options: High, Medium, Low, and Informational. You can use this setting to override the alert severity for a connected data source that sends alerts; also, you can use this setting to set the severity for a created analytic. Severity should be used to help your security analysts prioritize and triage their responses and the cases that are created. Lastly, you can set the Status to either Enabled or Disabled.
FIGURE 3-9 General section of Analytic rule wizard The Logic section is shown in Figure 3-10. The Set Rule Logic field is where you define what query you want to run against the Azure Sentinel workspace that will trigger and create an incident. Azure Sentinel stores the data in a Log Analytics workspace. To query the data in the workspace, you will use Kusto Query Language (KQL). Your query can be simple like WireData | where RemotePortNumer == 443, which will alert you when any computer connects outbound from port 443. For this sample query, you need to enable the Wire Data solution on the workspace. Your query can also be very complex, as shown in the example below:
AzureActivity | where OperationName == "Create or Update Virtual Machine" or OperationName == "Create Deployment" | where ActivityStatus == "Succeeded" | make-series dcount(ResourceId) default=0 on EventSubmissionTimestamp in range(ago(7d), now(), 1d) by Caller
The intent of this query is to trigger an alert on when an anomalous number of resources is created in Azure Activity Log.
FIGURE 3-10 Logic section Tip
For assistance with the query language, see the Query Language Reference at https://docs.microsoft.com/en-us/azure/kusto/query/.
As you enter the query into the Rule Query box, the Results Preview graphic on the right will update in real time as you write it. The graphic will show you how many results are returned from the query in a blue line. When you add the Alert threshold, the threshold will create a red line on the graphic. This is important because it allows you to see the query based on your data, as well as the threshold for how many incidents you can expect to be created as a result. Each time the red line passes above the blue line, an incident will be triggered. Figure 3-11 shows an example of the results line at the top (appears blue on screen) and the threshold line at the bottom (appears red on screen).
FIGURE 3-11 Alert simulation graphic In the Entity Mapping section, you can define the entities that are returned as part of the data that was queried in the Query Rule. Entities are important because they allow you to select which field from the data returned represents a user, host, or IP address. This information might be different column names across data sets, and the mapping allows you to normalize the data into entities. Entities are very important for incidents and investigation, which will be covered later in this book. Figure 3-12 shows the Entity Mapping section.
FIGURE 3-12 Entity Mapping section Not all alert rules will have all entity types. For example, an alert rule based on firewall log data might only contain IP address entities. Mapping more entities when creating a rule will be useful when responding to incidents. Doing so will help the analysts understand which user or computer was involved or which IP address was used by the source machine.
The Query Scheduling section is where you set how often to trigger the query and how far back in the data to query against. The Run query every field defines how often you want to evaluate the query against your data. You might have a rule that runs every 5 minutes or once every 24 hours. The Lookup data from the last should be less than or equal to the Run query every setting. This is required because you don’t want to query 1 hour of data every 5 minutes. If you did this, the trigger would create multiple incidents of the same alert. Both options can be between 5 minutes and 14 days. There is also an option to Stop running the Query after the alert is generated option. You can set this to On or Off. This option allows some basic suppression of the rule to prevent creating additional incidents if the rule is triggered again for the time you want it suppressed. If you select On, a new field appears called Stop Running Query For. You can set this to anywhere between 5 minutes and 24 hours. The Query Scheduling section is shown in Figure 3-13.
FIGURE 3-13 Query scheduling section The Alert threshold section is where you set the number of results required for the rule to generate an incident. The Generate alert when the number of query results trigger supports the following operators: Is Greater Than, Is Fewer Than, Is Equal To, or Is Not Equal To. Then you define the number for the threshold. Figure 3-14 shows the Alert threshold section.
FIGURE 3-14 Alert threshold section To tie steps 10 and 11 together, you might want to trigger an alert for a user who exceeds 5 failed logins in a 15-minute window. You would configure the Run Query Every setting to 5 minutes. Then you would set the Lookup Data From The Last setting to 15 minutes. Lastly, set the Generate alert when number of query results to Is Greater Than 5. This would run the query rule every 5 minutes and look at the last 15 minutes of data. If the failed logins crossed 5, it would generate an incident.
The Automated Response section allows you to select a playbook to run when the alert is triggered. This allows you automate the response to incidents. This automation could be to run a query to gather more data to enrich a case, automatically respond by disabling an account, or even open a ticket in a third-party ticketing system. For a playbook to be listed, it must use the Azure Sentinel Alert trigger. Triggers will be explained in a later chapter. Figure 3-15 shows the Realtime Automation section.
FIGURE 3-15 Realtime Automation section Although this book will not cover Azure Logic Apps in depth, Chapter 7, “Automation with Playbooks,” will cover more details about how to create a Playbook.
Note
See more about Azure Logic Apps at https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-overview.
The Review and create section, as shown in Figure 3-16, allows you to review the settings you have configured in the wizard before creating new rules.
FIGURE 3-16 Review and create section
Types of analytic rules
There are three types of analytic rules that are pre-built in Azure Sentinel: alerts for Microsoft solutions and Community alerts. The following sections go into more detail on both.
Microsoft black box rules
Microsoft black box rules are built-in rules that you can not edit; also, you cannot see the rule settings for Microsoft black box rules. There are detections that Microsoft has built for you to enable, but the detection logic is not shared with you.
Microsoft solutions
In Azure Sentinel, analytic rules for Microsoft solutions are easy to create. This allows you to create an incident in Azure Sentinel from any existing security alert that comes from these solutions. You will not need to create individual analytic rules for Microsoft solution alerts.
These rule templates will create an incident whenever an alert is generated by the source Microsoft solutions. When you click Create Rule, you have the option to filter by severity and/or text in the alert name. For example, this will give you the option to only create incidents for high-severity alerts from Azure Security Center. Or you might choose to create an incident if the alert contains a “pass” from Azure Advanced Threat Protection. Figure 3-17 shows the table of built-in Microsoft rules.
Community
In the Azure Sentinel Community, Microsoft contributes sample rules created by various Microsoft Security teams. Customers can contribute sample rules as well. Typically, these rules are additional detections that are built on data sets, such as Windows Events, that are not already part of a Microsoft Security solution. Azure Sentinel will automatically sync the GitHub community detections that Microsoft has chosen, which will allow you to enable the rule and apply it to your environment.
Creating analytic rules
Now that you know all the components of an analytic rule, let’s create one and see how this analytic will trigger an incident. Follow these steps to configure your first useful analytic rule in Azure Sentinel.
Open the Azure Portal and sign in as a user who has Azure Sentinel contributor privileges.
In the search pane, type Azure Sentinel and click the Azure Sentinel icon when it appears.
Select the workspace on which Azure Sentinel is enabled.
In the left navigation pane, click Analytics.
Click Create, then click Scheduled query rule in the top pane, as shown in Figure 3-19.
FIGURE 3-19 Scheduled query rule In the General section, enter Azure VM Deletion for the Name. In the Description field, enter A simple detection to alert when someone deletes and Azure Virtual Machine. Set the Tactic to Impact. Set the Severity to Informational. Leave Status as Enabled. Click the Next: Set Rule Logic button. See Figure 3-20 for an example.
FIGURE 3-20 General section of the Analytic Rule Creation wizard Enter the following query in Set Alert Query.
AzureActivity | where OperationName == "Delete Virtual Machine” | where ActivityStatus == “Accepted”
In the Entity Mapping section, click the Property drop-down menu next to Account. Notice the Property drop-down menu enumerates all columns returned from your query, which eases the selection of columns representing each entity. Select Caller and click Add. Notice this adds | extend AccountCustomEntity = Caller to the end of the query. See Figure 3-21.
FIGURE 3-21 Alert Suppression section Tip
You can map entities in the query without clicking the Property drop-down menus. Just add | extend <entitytype>CustomEntity = <Property> to the alert query.
Click the Property drop-down next to IP Address. Select CallerIpAddress and click Add.
In the Query Scheduling section, enter 5 in the Run Query Every field and select Minutes. Enter 5 for the Lookup Data From The Last and select Minutes.
In the Alert threshold section, enter Is Greater Than 0 for the Threshold.
Click Next: Automated Response.
In the Automated Response section of the wizard, click Next: Review. We will not assign a playbook at this time.
Figure 3-22 shows the example analytic rule review page. Click Create.
FIGURE 3-22 Review and create section
You will now be back in the Analytics blade. Figure 3-23 shows the analytic you just created.
Validating analytic rules
Now that you have created your first analytics, let’s walk through validating it. Follow these steps to validate your first analytic in Azure Sentinel:
Open the Azure Portal and sign in as a user who has Azure Sentinel Contributor privileges.
In the search pane, type Resource Groups and click the icon when it appears.
Click the Resource Group you created in Chapter 2.
Select the desired virtual machine.
Click Delete in the top bar.
In the Delete Resources blade, type yes to confirm deletion.
Click Delete.
It will take some time for the Analytic to trigger because Azure Activity must first write the logs.
Note
To learn more about log data ingestion time, see https://docs.microsoft.com/en-us/azure/azure-monitor/platform/data-ingestion-time#azure-activity-logs-diagnostic-logs-and-metrics.
In the search pane, type Azure Sentinel and click the Azure Sentinel icon when it appears.
Select the workspace on which Azure Sentinel is enabled.
Click Cases.
You will see a that an a Incident has been created (see Figure 3-23).
Note
Incidents are covered in more depth in Chapter 4.