Section 8.1 – Mitigate threats using Microsoft Defender for Cloud – Configure and respond to alerts and incidents in Microsoft Defender for Cloud

Already in the 8th section on my study guide and today we are looking alerts, automation workflows and remediations.

And because this is an huge section to cover, I will cut it in two different posts, my apologies for the ones that are actively studying, you just have to wait.

So let’s get going!

Validate alert configuration

Before you validate the alert configuration, you have understand what alerts are.

What are security alerts?

When threats are found in your Azure, hybrid, or multi-cloud settings, Defender for Cloud’s workload protection strategies will send out security warnings.

  • Advanced detections made possible by enabling Defender plans for particular resource types result in security alarms.
    Each warning contains information about the resources, problems, and corrective actions that are affected.
  • Defender for Cloud categorizes and ranks warnings according to their seriousness.
    Even if the resource that was associated with the warning was destroyed within that period, it will still be visible on the portal for 90 days. This is due to the possibility that the warning indicates a breach that should be looked into further inside your firm.
  • The CSV format can be used to export alerts.
  • Moreover, alerts may be broadcast directly to an ITSM or Security Orchestration Automated Response (SOAR) or Security Information and Event Management (SIEM) tool like Microsoft Sentinel.
  • To formalize security domain knowledge, Defender for Cloud uses the MITRE Attack Matrix to link warnings with their observed purpose.

And how the alerts are categorized

SeverityRecommended response
HighThere is a high probability that your resource is compromised. You should look into it right away. Defender for Cloud has high confidence in both the malicious intent and in the findings used to issue the alert. For example, an alert that detects the execution of a known malicious tool such as Mimikatz, a common tool used for credential theft.
MediumThis is probably a suspicious activity might indicate that a resource is compromised. Defender for Cloud’s confidence in the analytic or finding is medium and the confidence of the malicious intent is medium to high. These would usually be machine learning or anomaly-based detections, for example a sign-in attempt from an unusual location.
LowThis might be a benign positive or a blocked attack. Defender for Cloud isn’t confident enough that the intent is malicious and the activity might be innocent. For example, log clear is an action that might happen when an attacker tries to hide their tracks, but in many cases is a routine operation performed by admins. Defender for Cloud doesn’t usually tell you when attacks were blocked, unless it’s an interesting case that we suggest you look into.
InformationalAn incident is typically made up of a number of alerts, some of which might appear on their own to be only informational, but in the context of the other alerts might be worthy of a closer look.

Validating configuration

You can open the alerts page from https://portal.azure.com/#view/Microsoft_Azure_Security/SecurityMenuBlade/~/7 and once you do, you will land to the main page of those alerts.

And this page you change the status on the alert, in the following two places.

And the alerts above is with a severity level of High, which makes sense as it’s an Pre-attack based on MITRE.

Then we can see email notification for those alerts

Set up email notifications

To specify options for notification emails, use the Defender for Cloud Email Notifications settings page.

who should be informed – Emails can be sent for a subscription to specific people or to anybody with a particular Azure role.
what they should be informed of – Change the alert severity levels that Defender for Cloud should send out.

You can access email notification under Environment settings -> Email notifications

You can choose the Subscription roles described below to send the emails to.

For the test and your setup remember that:

  • approximately four emails per day for high-severity alerts
  • approximately two emails per day for medium-severity alerts
  • approximately one email per day for low-severity alerts

Which translates to:

  • High-severity notifications are limited to one email every 6 hours
  • Medium-severity alerts to one email every 12 hours
  • Low-severity alerts to one email every 24 hours.

Or with API and see more from Learn

Create and manage alert suppression rules

The quantity of warnings produced may be controlled via alert suppression rules. When various security incidents are discovered on your resources, Defender for Cloud automatically creates notifications. You could, however, choose not to get notifications for certain occurrences in some circumstances. To stop these warnings from being created in such circumstances, you may set an alert suppression rule.

Alert suppression guidelines are crucial for the following two reasons:

  • Alert suppression rules can assist to lower the noise Defender for Cloud generates. You may concentrate on the warnings that matter and take the required steps to address the security risks by filtering out the notifications that are unimportant to your firm.
  • Saving Time and Resources: You may spend less time and money on incident response tasks if there are fewer alerts to look into. You may prioritize the warnings that need urgent attention by suppressing the ones that don’t, which will allow you to react to major security issues more rapidly.

You can create those Suppression rules under the alerts and by choosing take action

And choosing, create a rule

You have following options that you have to define

  • Entities – The resources that the rule applies to. You can specify a single resource, multiple resources, or resources that contain a partial resource ID. If you don’t specify any resources, the rule applies to all resources in the subscription.
  • Name – A name for the rule. Rule names must begin with a letter or a number, be between 2 and 50 characters, and contain no symbols other than dashes (-) or underscores (_).
  • State – Enabled or disabled.
  • Reason – Select one of the built-in reasons or ‘other’ to specify your own reason in the comment.
  • Expiration date – An end date and time for the rule. Rules can run for up to six months.

Once done, you simulate what happens when you enable the rule. Remember that Suppression rules can only dismiss alerts that have been triggered at least once on the selected subscriptions.

Once done, you can see the rules under Suppression rules

And you can see the expiration and modification dates

And yes that API, almost all the aspects can be created or modified with APIs these days, if you are familiar with, use it, if you ain’t, learn it.

At first it can be a little bit weird but there are a lot of good material learn from.

Design and configure workflow automation in Microsoft Defender for Cloud

You might want to use automation because these reasons:

  • Boost productivity and efficiency: Security teams may concentrate on more crucial duties like threat detection and incident response by automating routine security processes.
  • Minimize the danger of human mistake, which can result in security incidents, by automating security processes.
  • Speed up: Automation can drastically shorten the time it takes to detect and address security concerns.

All the way down you can find Workflow automation. To access it you need to be Security admin role or Owner on the resource group and you must also have write permissions for the target resource

Because the automation is done with Logic apps, you also need:

  • Logic App Operator permissions are required or Logic App read/trigger access (this role can’t create or edit logic apps; only run existing ones)
  • Logic App Contributor permissions are required for Logic App creation and modification
  • If you want to use Logic App connectors, you may need other credentials to sign in to their respective services

Once you start creating the automation, note that some security recommendations include a list of security findings from vulnerability assessment solutions. These individual security findings are not included in the trigger.

You can choose from there Defender for Cloud data types

And all severity levels or some of them

And once you have all of it setup, you can create the Logic App rule and it will be displayed as enabled.

You can also create them with Bicep if you want

Or ff you want to add or edit the existing one, just click the Logic App name and build your own or use those templates that are available for you.

  • When a Microsoft Defender for Cloud Recommendation is created or triggered – If your logic app relies on a recommendation that gets deprecated or replaced, your automation will stop working and you’ll need to update the trigger. To track changes to recommendations, use the release notes.
  • When a Defender for Cloud Alert is created or triggered – You can customize the trigger so that it relates only to alerts with the severity levels that interest you.
  • When a Defender for Cloud regulatory compliance assessment is created or triggered – Trigger automations based on updates to regulatory compliance assessments.

And this how it will look like inside Logic Apps

And if you like to use JSON more, you can also edit that one, all the pieces just fit together.

See more on this topic from Learn. I really suggest you on learning Logic Apps also, it’s used in many of the automations for Azure, in my opinion it’s a must learn skill.

Closure

  • Remember that Defender for Cloud categorizes alerts to 4 different levels: High, Medium, Low and Informational
  • Alert status can be Active, In-progress, Dismissed or Resolved

From Email notifications for the test and your setup remember that:

  • approximately four emails per day for high-severity alerts
  • approximately two emails per day for medium-severity alerts
  • approximately one email per day for low-severity alerts

Which translates to:

  • High-severity notifications are limited to one email every 6 hours
  • Medium-severity alerts to one email every 12 hours
  • Low-severity alerts to one email every 24 hours.

Why should you use Alert suppression rules? To avoid noise and false-positives.

Remember that Suppression rules can only dismiss alerts that have been triggered at least once on the selected subscriptions.

What roles are needed to create Workflow automation from Subscription level and what in Logic Apps? What template types are available currently?

If want see more from Microsoft Interactive guide, you can access it here

Link to main post

This image has an empty alt attribute; its file name is image-123.png
Author: Harri Jaakkonen

Leave a Reply

Your email address will not be published. Required fields are marked *