A Guide to Azure Sentinel

Microsoft Azure Sentinel is a cloud-based SIEM that applies advanced techniques to help system managers track their infrastructure’s security status. Here, we present a brief guide to setting it up and using it. Additionally, Sentinel is currently in preview, and any of these steps could change in the final version. Some features may be incomplete or have issues.

Onboarding

To get started, you need an Azure account and a Log Analytics workspace. You can create a new workspace if you don’t have one. Your account needs to have contributor permission for the subscription in question, as well as a contributor or viewer permission for the workspace’s resource group.

In the Azure portal, select the subscription you will be working with, search for Azure Sentinel, and add it to the workspace. You will see an overview on your screen. The basic steps to having a working instance are:

Setting up data sources

Creating threat detection rules and alerts

Adding task automation

Now you can connect the data sources. Open “Data connectors” on the main Azure screen, and you’ll see a list of available data sources. Select one or more of these. Azure Active Directory is a good place to start. Some data sources are one-click installations; others ask for additional input. When you select Active Directory, you’re asked to select the logs to use as sources.

Appropriate permissions may be required to add a data source. If it is external, permissions outside your Azure subscription may be required.

When you add a data source, Sentinel will recommend dashboards to install so that you can get useful information on it.

Initially there will be no data to view. If the workspace is active, data will start accumulating soon.

Getting Visibility into Threats

To start exploring your infrastructure, wait for some activity to happen and then go back to the main dashboard. Click on the workspace you’re monitoring, and you’ll see its dashboard.

At the top, you’ll view a count of events, alerts, and cases. “Events” in general are harmless; you won’t see any alerts or cases yet since you haven’t set them up. Below that, you’ll see a list of sources. Click on one of them to see its dashboard. You’ll be able to see details on the events which have accumulated.

The main pane of the Azure dashboard shows events over time, as well as showing the geolocation of suspicious event on a map. The map highlights events involving known malicious sources; inbound traffic is marked in orange and outbound traffic in red.

The “data source anomalies” tile will show suspicious events if any have been detected. You can click on one of the data sources to get more information.

Install dashboards for data sources which you want to monitor. Each one will show information tailored to the source. Therefore, viewing the dashboard gives you an overview and lets you examine potential threats more closely.

You can customize Sentinel by creating new dashboards. In fact, the included examples provide useful starting points.

Threat Detection

So far you can get an overview of events but no notification of threats. The second step is to create some detection rules. To do this, select “Analytics” under Sentinel in the portal, then click on “Add.” Give the new rule a name and select a severity level (high, medium, low, or informational).

Afterwards, you need to create a query, using Log Analytics’ Kusto query language. (The name is pronounced like “Cousteau,” possibly a wordplay on taking a “deep dive” into the data.) Paste it into the “Set alert rule” field. You need to set up the following:

Entity mapping from query columns to Sentinel fields

Conditions for triggering the alert, including a threshold for the number of occurrences

Frequency at which the query will run

The data period it runs on

Criteria for suppressing duplicate alerts (optional)

Creating a query displays a simulation of it to help you decide if its parameters are reasonable. Thus, clicking the Create button, you create a case containing the alert. A case is a collection of events which are all related to the same issue.

All the alerts you have created are available to view and update on the Analytics page. In fact, this is where you can edit, disable, delete, or clone rules. The Cases page lists the alerts which have been triggered, organized by case.

Responding to Threats With Automated Playbooks

The third of the basic steps is setting up automated responses. When events trigger a Sentinel alert, you may want a response to happen immediately. Perhaps it should open a support ticket and send an SMS message. Playbooks are the way an administrator sets up automated actions in response to an alert. They can also be run manually. A playbook indicates a sequence of automated actions to take when it runs.

Playbooks are Azure Logic Apps, and writing them requires some familiarity with that system. While Sentinel is free during the preview period, using Logic Apps may incur charges. The Logic App Designer enables creating a playbook from a template, so it isn’t necessary to know all the details of the syntax.

When creating a playbook, you can set it to run “when a response to an Azure Sentinel alert is triggered.” The playbook will include the actions to take. It can specify conditionals, switching statements, and loops if necessary.

In some cases, it’s appropriate to view the cases and then run a playbook manually after evaluating them. From the Cases page, select and view a case with full details. In the Alerts tab, click on a selected alert, click “View Playbooks,” and select the playbook to run on the alert.

Threat Hunting

Azure Sentinel

Sometimes it isn’t enough to wait for alerts. Indeed, an administrator has an idea that something is wrong and needs to investigate it. Sentinel includes a powerful set of tools for hunting down threats. It has a set of built-in queries, and you can create modified versions or write your own in the Kusto query language.

A GitHub repository contains many more queries from Microsoft and the community. Thus, these may be usable as they are, or they can be adapted to specific needs.

The “Hunting” page in the Sentinel portal is the starting point. It displays all the available queries, with a description for each one. Filtering the list helps to locate any relevant queries. You can mark any of them as favorites; whenever you open the Hunting page, all the queries listed in favorites will run.

You can run a query within the Hunting page. A summary of the results will appear in the query details pane. Opening the query in Log Analytics provides more detailed information. Any rows in the result that are particularly significant can be bookmarked. They become available in the “Bookmarks” tab of the Hunting page for later review.

Automated Hunting With Notebooks

Investigators can use Jupyter interactive notebooks to automate the hunting process. The feature uses Azure Notebooks, which is also currently in preview. Jupyter itself is a well-established technology. Azure Notebooks simplify their use, pre-loading any dependencies so the notebook can just run.

Several built-in notebooks are available for various hunting strategies, and administrators can create their own or modify the available ones. The “Notebooks” page lists the available notebooks. Notebooks, unlike playlists, are highly interactive. Each one provides a workflow for a particular use case.

Jupyter is well-suited for data analysis and supports the display of data as text or in graphic form. Therefore, a notebook can be very useful in examining trends and anomalies in events.

Managing Data During Hunting

The “Bookmarks” feature mentioned under threat hunting is valuable for managing threat data. On the Hunting page, you can click on the Bookmarks tab and view the current list. First, searching or filtering will help to locate one which is relevant to the current situation. Next, selecting a bookmark will show its details to the right. Finally, the notes and tags can be edited there.

You can view the bookmark in Log Analytics for more information. There it’s possible to combine the bookmark with other data sources to gain more insight. You can run any Log Analytics query on a bookmark. Viewing the bookmark history shows all updates that have been made to it, including who made them and when. Another way of viewing them is through bookmark logs, presenting them as raw data.

The next step is to select a bookmark and run “Investigate” on it. The investigation brings up an interactive graph showing relevant entities, and the investigator can drill down into any of them. Indeed, investigators can add comments and tags to a bookmark and share it with other investigators.