Published: Sep 13, 2023
Microsoft 365 Defender, Identity Protection, and Microsoft Sentinel generate an avalanche of security incidents that require attention. In this article, I will give you an overview of what tools are at your disposal, what incidents are useful, and how to make Microsoft Sentinel reduce alerts.
Today’s security systems aren’t perfect. They generate many false-positive alerts, which need to be investigated to verify whether they are indeed malicious. Some incidents are more useful than others, which will make your life hard.
If you are just starting out, getting your bearings is difficult. There are so many different portals and screens. The most important thing to know is how to see an overview of all open security incidents within your environment. There are two options for that, Microsoft 365 Defender and Microsoft Sentinel.
Microsoft 365 Defender is the XDR (Extended Detection and Response) tool from Microsoft that monitors the following elements in your environment:
In the Microsoft 365 Defender portal, you can navigate to the Incidents blade to see all active security incidents in your environment.
While using Microsoft 365 Defender, you are limited to the incidents and data sources Microsoft provides. If you want to take it further, you need to deploy Microsoft Sentinel.
Microsoft Sentinel is a cloud-based SIEM product (Security Information and Event Management) from Microsoft. It is built on top of Microsoft Azure.
In the SIEM, you can add custom data sources such as ERP systems, network logs, and much more. Microsoft Sentinel is a completely open system, meaning it is possible to tweak all detections and build custom integrations.
Choosing between Sentinel and Defender is important as you need to choose what you are going to use as your single pane of glass.
Defender offers simplicity for smaller organizations that don’t have a large security team. Microsoft Sentinel adds more complexity but allows for more customization, data sources, and custom integrations, which is great for larger organizations with bigger teams.
Not all incidents are equal; some are more useful than others. And it is important to get your priorities straight. There are only 24 hours in a day, and investigating every single alert is impossible. So, it is important to prioritize some of the default alerts above others.
A great example is the ‘Unfamiliar sign-in’ alert, which is generated when a user makes a suspicious sign-in from a previously unknown device or location. While it sounds great in theory, the alert generates false positives when users are traveling or using a VPN service. This type of incident is not as useful as incidents generated by Microsoft Defender for Endpoint, the AV and EDR product.
Microsoft Defender for Endpoint incidents have a much higher fidelity meaning they should receive a higher priority. These types of incidents will indicate malicious activity on endpoints (laptops, desktops, and mobile devices) and servers.
Almost all incidents will generate false positives at one point or another. It is important to tweak them as much as possible at that time. Most built-in detections allow you to add exclusions to ensure you don’t receive the same incident repeatedly. Your security tooling should be evolving continuously to avoid such false positives. By doing this work, you avoid repetitive investigations.
To minimize the mean time to response (the amount of time it takes before an action is taken on an incident, like resetting a password), automation is key. Automation helps us in two different scenarios: enrichment and automated actions.
Enrichment is the process of adding as much context to the incident as possible, including:
By doing enrichment, a Security Operations Center (SOC) analyst has all of the information in one place and is able to grasp the full scope of the incident quickly.
Automated actions aim to minimize the time it takes to execute remediation actions. Examples of these actions are resetting a user’s password or isolating a host. By automating actions, we ensure they happen in a predefined flow, and they can be automated to remove the dependency on a SOC analyst.
While both Microsoft 365 Defender and Microsoft Sentinel offer a lot of built-in detections, both products allow you to add custom rules.
Adding custom rules is important to monitor specific threats in your environment. A system such as Defender for Endpoint is shared across thousands of customers. If a new detection is added, Microsoft needs to validate it across all of them.
We have the advantage that detection should only fit our own environment. By creating a custom detection rule, we can create our own exclusions and exclude expected behavior.
Let’s take the example of an administrator disabling 50 user accounts at once. This is suspicious activity that we want to monitor. However, a background process might exist in your environment which cleans up inactive accounts. This means the incident will generate a lot of false positives.
By building the use case ourselves, we can add our own exclusions to ensure we only receive incidents we want to see.
Building custom detections in both products is done in KQL. KQL stands for Kusto Query Language, and it is a query language often compared to SQL. KQL allows you to retrieve data from the enormous datasets that Defender and Sentinel gather.
KQL is an important language to master as it can execute statistical functions on your data to identify outliers. While most of the data found in KQL is also available in the portal, getting the data using KQL will be much faster once you learn the language.
Microsoft 365 Defender and Microsoft Sentinel are products with a steep learning curve. They are both complex and capable but take a while to master. If you are serious about security, it is important to spend time in the stack and learn the incidents that are being generated.
Incidents should be thoroughly investigated, and their output should be used to improve detection. By continuously improving detections, you decrease the time it takes to identify malicious behavior.