Azure Threat Detection & Response: How to Detect & Respond. The cloud movement greatly changed the attack surface. Organizations find that detection and alerting are not that straightforward. In the past, perimeter security was simple. But with the cloud your security operations team needs visibility for identities, devices, networks, applications, data… the list goes on.
Cloud providers understand this requirement to enable customers to generate alerts based on their needs. This brings a greater level of detection, however if not done correctly, it may overload your SOC with false positives, and unactionable alerts
In the post we cover basic concepts, and how Microsoft’s Azures native solutions assist with your incident response plan.
For Microsoft benchmark guide take a look here: Azure Security Benchmark v3 – Incident Response | Microsoft Learn
Scope
If you are in the process of reviewing tools such as these, it’s advised that you first have a scope. The business should define what they are wanting to detect and gain visibility on before reviewing tools. Solutions such as these should match that scope, and give you the expected results. Without this, enabling services such as these will bring unexpected results and interruptions to SecOps.
Defender For Cloud
Defender used to be Microsoft’s answer to EDR, however it has greatly expanded. Defender for cloud allows various resources to be protected by Microsoft’s intelligence. Within the portal, you can tailor your deployment to cover which resources you need to secure. Defender for cloud is then able to alert you for any suspicious or malicious activity which occurs on protected resources.
Configuring Alerts
To configure who receives these alerts, go to environment > email notifications and set the values. It’s advice to either create a distribution list, or enable by role. This way onboarding new Security resources are managed via groups. This is because Defender email notification is specific per subscription.
It’s worth noting Microsoft’s restrictions on alerts:
- 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
Read more here: https://learn.microsoft.com/en-us/azure/defender-for-cloud/configure-email-notifications
Adding Automation
For those wanting more, an option may be to enable automation. Here we can forward all triggers to a logic app which in turn notifies the select party.
Doing this also increased you ability to respond, however we will discuss this later on. In most cases, a company may not want to handle incident response via email. In doing so, you can lose track of alerts/response, cause delays and/or add extra manual effort in raising incidents within your ticketing system.
Instead you may explore Microsoft’s preview of ServiceNOW integrations. Here, Defender automatically creates a ticket when an alert is created.
More: https://learn.microsoft.com/en-gb/azure/defender-for-cloud/integration-servicenow
Enabling several of these options isn’t necessarily a bad idea. Whilst ticketing incidents are important, so is being aware. You may want to only alert on high severity to get your team engaged, whilst still logging tickets for all. You may also want to respond differently, so feeding to logic apps allows you to create conditional response.
Try our Active Directory & Office 365 Reporting & Auditing Tools
Try us out for Free. 100’s of report templates available. Easily customise your own reports on AD, Azure AD & Office 355.
Responding Using Defender For Cloud
Being alerted is great, however there is a short period of time between being alerted and a SOC member acknowledging it. Within this time gap, malicious parties thrive as it’s a blind spot. This is where response via automation plays a big part. You may want to isolate, contain or respond automatically based on your defined playbooks. This is where logic apps come into play.
Logic apps are simple low-code solutions to allow those that aren’t aware of programming language to build large scale automation. A simple example could be that if a host has a high severity alert, the machine is isolated until an agent responds. If you are not running Defender endpoint, you could look for alternatives that preserve the image such as restrict an NSG or remove the NIC. This could replicate isolating the machine, or resource.
Logic apps are not security specific so you can be as creative as you like. Consider how the automation either enriches the alerts, or helps your SOC respond. If the design is creating more work, it might not be worth it. There is a great repo that may spark ideas: Microsoft-Defender-for-Cloud/Workflow automation at main · Azure/Microsoft-Defender-for-Cloud · GitHub
However you respond, it’s important to update and manage the alerts within the Defender portal. If you’ve not integrated with ServiceNow, you will need to update each alert on its current status. This can be done via the alert section, either by highlighting or going into the alert.
Remove The Noise
It’s advised to review each alert, and reflect as you close. In some cases, alerts are generated based on expected activity. If this is the case, it may be worth creating a suppression rule. Remember, removing noise is another vital step in improving the effectiveness of your SOC.
It’s strongly advised to design this, and to get a peer review before implementing these. The last thing you want to do is blind yourself to actual attacks. It’s important to make them as specific as possible so that it’s not broad enough to include other alerts by mistake. To set these, dive into the alert and create the criteria.
The last point is that not all responses can be automated. That’s why it’s important to make sure you have eyes on your alert sources at all times. It’s also advised to build out playbooks, so that your response success isn’t based on the responders knowledge/skillset. In some cases, Defender may not have all the information, so it’s important to highlight what steps need to be followed in order to gather.
Microsoft Sentinel Alert and Response
Whilst Defender may detect, it may not have all the information required. This means the alerts generated may not give the complete picture. To prevent this look to forward logs to a SIEM. In doing so, you allow better consolidation of log sources, and give the SOC the edge to be able to drill down further based on detection. Microsoft Sentinel is the native option, however there are many third party solutions that allow complete integration with Defender for cloud.
Whilst you still need to define playbooks, policies and incident response, the added benefit of Sentinel is that you mirror the majority of written procedures within the tool itself. This reduces the need for responders to have documentation present, or memorize all attack responses. Although you could match something similar in Defender for cloud with Logic Apps, the added benefit is that the majority of work is done for you.
It’s worth reviewing and looking at the content hub within your Sentinel instance.
Thank you for reading our article on Azure Threat Detection & Response: How to Detect & Respond. We shall summarize.
Azure Threat Detection & Response: How to Detect & Respond Conclusion
As you see, Microsoft Azure provides various tools to allow customers to build incident response with automation at the heart. With the adoption of community, each customer benefits from innovation of their peers within the content hub, or managed repos. All of this, with a pay-as-you-go license model, so that even those with a tight budget ensure their resources are protected.
Try InfraSOS for FREE
Try InfraSOS Active Directory, Azure AD & Office 365 Reporting & Auditing Tool
- Free 15-Days Trial
- SaaS AD Reporting & Auditing Solution
