· What is Microsoft Sentinel? · Microsoft Sentinel Overview Page ∘ Roles · Log Analytics · Kusto Query Language (KQL) ∘ Sample Case · Threat Management ∘ What is an incident? ∘ How does it work? ∘ Workbooks · Threat Hunting · NoteBooks · Threat Intelligence · MITRE ATT&CK · Analytics · Rule Types · Hire me to write for you! · Follow for More Content! · Leave a suggestion for future topics!

What is Microsoft Sentinel?

Microsoft sentinel is a cloud-native security information and event manager (SIEM) that uses Artificial Intelligence to analyze volumes of data across your organization to generate alerts and create automated responses. It provides four main pieces of functionality as outlined in the diagram below:

In this article we'll discuss microsoft sentinels most prominent features:

Microsoft Sentinel Overview Page

Microsoft Sentinel Overview page gives you a glance at the security operations status for your environment . At the top, you will see the trends of events, alerts, and incidents. Next to the trends, you will see the proportion of incidents by status. The middle shows the events and alerts on a time graph. At the bottom, there is a map with potentially malicious event sources and destinations. Then, on the right, you will see a summary of recent incidents and the anomalies found from data sources.

Now, take a look at the navigation menu on the left, which is divided into the following four categories:

General: Contains general information such as the overview dashboard, events logs, and security news and guides published by Microsoft.

Threat management: Holds the most valuable features and data for analysts — incident management; investigation and analysis tools such as hunting queries, workbooks, notebooks; entity behavior baselining; threat intelligence.

Content management: This section contains valuable features for engineers, such as packages of workbooks, queries, playbooks, and automation rules.

Configuration: This section is perhaps the focus of engineers. You can manage data sources, detection rules, automation, and watchlists here.

Roles

Microsoft Sentinel uses the Azure role-based access control (RBAC) model. Role-based security defines roles (such as analysts or engineers) for various job functions. Each person or agent is assigned one or more roles. Permissions to complete specific tasks are assigned to roles. For example, an analyst role may have the permission to manage incidents, while an engineering role may have the permission to configure the security systems.

It is possible to create your roles based on the requirements of your organization. However, there are four different roles provided out of the box for Microsoft Sentinel:

Microsoft Sentinel Reader: This role can only view data, incidents, workbooks, and other Microsoft Sentinel resources. It does not come with any editing rights. This is suitable for someone who needs to view the SOC status or follow incidents but does not actively participate in the security operations.

Microsoft Sentinel Responder: In addition to the reader rights, this role can also manage incidents. A security analyst typically needs to triage alerts, analyze incidents, and hunt for threats, among many other tasks. This would best map to the Microsoft Sentinel Responder role.

Microsoft Sentinel Contributor: This role can do everything the Responder can and create and edit the Microsoft Sentinel resources. A security engineer is someone who builds the SIEM/SOAR and typically needs to create and edit the tools necessary for the analyst's work. This role would best map to the Microsoft Sentinel Contributor role.

Microsoft Sentinel Automation Contributor: This role can do everything the Contributor can and add playbooks and automation rules. This role is not meant for user accounts.

Log Analytics

Monitoring and analyzing logs is a frequent task in security operations. For this very purpose, Microsoft Sentinel includes Log Analytics, a tool to edit and run queries on collected data and interactively analyze the results. The queries are written in Kusto Query Language (KQL).

In this module, you will learn about the Log Analytics tool and gain some experience running KQL queries.

Kusto Query Language (KQL)

Kusto Query Language (KQL) is used by Microsoft Sentinel for data analysis. It can only be used to query data — it cannot be used to create, edit, or remove data. KQL takes inspiration from the Structured Query Language (SQL). Data is organized in databases, tables, and columns. You can write queries to read data.

Queries consist of statements separated by semicolons. There are two types of statements:

Let statements are used for defining variables used in the later statements.

Tabular expression statements are used for the queries describing the data you want from the tables.

Queries can be piped together with the | character. You first specify the table you want data from, then you filter or apply functions on the data in zero or more steps. Each pipe takes input from the previous step and outputs the resulting data to the next pipe.

You can see detailed results by clicking on the down arrow next to each event:

Sample Case

Let's look at how we would examine logs for a count of a particular event ID, in this case, Event ID 4624

To count the number of successful logons, you must parse the JSON in the Message field.

| extend m=parse_json(Message)

Then, use the summarize function on the EventID. The field also needs to be cast to string so KQL can parse it.

| summarize count() by EventID=tostring(m.EventID)

You can also filter only the relevant events to make things even more accessible.

| where EventID == '4624'

Altogether, the query is:

prerecorded_CL
| extend m=parse_json(Message)
| summarize count() by EventID=tostring(m.EventID)
| where EventID == '4624'

Threat Management

Microsoft Sentinel offers several tools for security operations. You will perform an essential incident investigation.

Finally, you will get an overview of the threat management features, including:

Incidents: Manage and respond to incidents in your organization.

Workbooks: Dive into incident investigation or hunting using interactive dashboards.

Hunting: Use provided or custom-made rules to kick-start your hunting investigations.

Notebooks: Use the power of Python to analyze your logs.

Entity behavior: Baseline your organization's activity to monitor for threats.

Threat intelligence: Organize and collect threat intelligence relevant to your organization.

MITRE ATT&CK: Understand your coverage of the MITRE ATT&CK framework.

What is an incident?

Microsoft Sentinel incidents are containers of threats in your organization — alerts, entities and any additional related evidence. An incident is created based on alerts that you have defined in the security analytics page. The properties related to the alerts, such as severity and status are set at the incident level.

How does it work?

Incidents are automatically created as a result of alerts triggered based on detections defined in 'Security analytics'. The incidents page provide a full view of all the context required for triage, investigation and response. For each incident, you can see the time it was generated and its status.

Now that you see the incidents, you are ready to investigate them. Clicking on an incident will open the preview blade with more information and controls. Here you can quickly manage the incident on a high level — change the owner, status, severity, add tags, etc.

Here you can also see the relevant information:

• Description of the incident
• Evidence collected automatically, such as alerts and events, and added manually, such as bookmarks.
• Incident creation and update times.
• Context of the incident can be seen under Entities. This may include things like usernames, IP addresses, and domain names.
• Relevant MITRE ATT&CK tactics and techniques.
• Other Microsoft Sentinel resources such as workbooks or alert rules.
• You can see incident comments as well as add your own.

Workbooks

Workbooks are collections of interactive visualizations where you can further investigate incidents or hunt for threats. You can use templates created by Microsoft, or third parties or create your own. It makes sense to customize these to your organization's needs in many cases.

You can navigate between My workbooks and Templates. The search bar is useful for finding interesting workbooks. For example, if you type in log4j, you will see the community-provided hunting workbook.

Threat Hunting

Go to Threat Management > Hunting. This page provides a collection of queries useful for hunting, grouped by the tactics they fall under. These queries are not as high fidelity as the queries used for rules. Therefore, they may create more false positives. They serve as a good starting point for your hunts or if more information is needed during an incident investigation.

At the top, you will see the status of hunting efforts. First, you will see the ratio of active queries to the total number of queries. Then the ratio of detections to the number of queries ran in the selected time range.

NoteBooks

Notebooks are Jupyter notebooks intended for more detailed investigation of incidents and hunting. Here you can write custom code to dive into the details and add narrative text and visualizations. In essence, notebooks give you more control than workbooks and require a higher level of expertise and time.

Notebooks can employ the full power of mathematical methods, such as machine learning or statistical analysis, on your organization's data. You should have a good idea of what you are looking for and set aside considerable time to get familiar with running the notebooks.

Entity Behavior

Entity behavior is a feature that baselines the regular activity in your organization and attempts to identify anomalies using mathematical and machine learning methods. An entity can refer to user accounts, hosts, or IP addresses. It takes time to learn the expected behavior in your network, but it pays dividends in high-fidelity, actionable intelligence focusing on the investigation.

Threat Intelligence

Go to Threat Management > Threat intelligence. Here you can systematize the indicators of compromise (IoCs) based on domain names, files, IP addresses, or URLs. You can connect internal and external sources to get intelligence automatically or add your own from your investigation or hunting findings.

You can set up threat intelligence sources to automatically collect relevant threat intelligence for your organization. It is also possible to manually add any threat intelligence you have gathered.

To automate the detection, you can create indicator-based analytic rules. These will trigger threat intelligence alerts, which will be displayed under the Threat intelligence page.

MITRE ATT&CK

Detection Rules

Detection rules are the underlying force behind the detection engine in Microsoft Sentinel. For investigation and hunting purposes, it is essential to understand how these rules work and how to view details for each of them. There are multiple types of detection rules, with each one useful for different detection mechanisms.

This module introduces detection rules and the different types available in Microsoft Sentinel.

Analytics

Now, go to Configuration > Analytics.

There are two tabs on the rule page — Active rules, which shows all the activated rules, and Rule templates, which show all the rules available. The rules may come with data connectors or solutions installed and may not be enabled by default.

Rule Types

There are several different types of detection rules, such as:

• Scheduled query rule
• Near-real-time (NRT) rule
• Fusion
• Microsoft Security
• ML Behavior Analytics
• Threat intelligence
• Anomaly

These all work with different mechanisms and are helpful for different scenarios. Below, you will learn about each of them in more detail.

The Scheduled query rule is the most basic analytic rule. Essentially, it is a KQL query run on the log data according to a defined schedule. You can specify how often the rule is run (frequency) and how far it scans the data back in time. Additionally, it is possible to specify whether to group multiple matches (events) under one alert or create an alert for each match. Furthermore, if you are confident in the fidelity of the rule, you can configure it to trigger an incident if an alert is created. The SOAR features allow playbooks to run if alerts are created. Playbooks are sets of instructions to be run once triggered, such as gathering additional information or performing specific tasks.

The Near-real-time (NRT) rule runs every minute on the events in the past minute. They are helpful if time is of the essence and you need to speed up threat detection. Other than frequency and look-back time, NRT rules function the same as scheduled query rules. However, they have some limitations. You can specify up to twenty NRT rules. The underlying KQL query can only use a single table. More complex features of KQL cannot be used, such as union or join. NRT rules create only one alert where all the matching events are grouped.

The Fusion rule makes use of a correlation engine (named Fusion) based on machine learning algorithms to provide detection of advanced multistage attacks. By default, it is enabled as an analytic rule called Advanced multistage attack detection. This rule cannot be manually created. As the detection is high-fidelity and high-severity, it skips the step of creating alerts, and a Fusion incident is created automatically on the Incidents page.

Microsoft Security rules create incidents based on alerts generated by different Microsoft security solutions (for example, Microsoft Defender). You can use the templates to create your own rules using similar logic. These rules do not use KQL for detection, nor do they need to be configured for frequency or look back. They will automatically trigger the security events from other security solutions.

ML Behavioral Analytics rules are based on proprietary machine learning algorithms. Therefore, you cannot see the logic. However, you can create and customize the behavior on alerts.

Threat intelligence rules make use of threat intelligence to detect threats. It is most helpful to connect threat intelligence sources to your SIEM. Then the rule can use the collected indicators of compromise to compare against the events ingested to find threats. The indicators used are domain name, email address, file hash, IP address, and URL. You can also configure the rule's schedule. Each match will generate an alert and an incident on the Incidents page.

Anomaly rules detect threats based on anomalies in the events. You can create and tune these rules by duplicating the existing anomaly templates. Anomaly rules are not enabled by default. Each of the rules has a training period, and until it has passed, it will not generate alerts.

Hire me to write for you!

I'm a freelance writer available for hire, if you would like me to create content like this for your website you can reach me at shimon@securitymadesimple.org.

Follow for More Content!

If you enjoyed this article and would like to get more content please follow me and I'll return the favor!

Leave a suggestion for future topics!

Also, feel free to comment on this article, ask questions, leave statements, or give suggestions for any other articles you would like me to write!