Security in the cloud can be complicated to understand. There are a multitude of native and third-party tools, a large number of different features within them, free and paid product plans, pricing logics that are hard to compare, and endless dashboard views with warning signs. It’s not uncommon to see all this hassle giving either a false sense of security or a feeling of security information fatigue.  

In this blog post, I’ll be going through how to start building maturity for Azure Cloud security from the aspect of threat detection coverage. 

What is threat detection?

Threat detection is the process of identifying potential security threats and vulnerabilities within a system or network. It detects anomalies, malicious activities, and security breaches to prevent or mitigate cyber attacks. Given the evolving nature of cyber threats, continuous improvement in detection capabilities is crucial for maintaining a robust security posture. 

Set up visibility

Birdwatchers need their binoculars in order to see the high flying birds. Our binoculars is Azure Monitor which enables us to see what we are looking for: logs.

Starting to build our logging strategy, we must consider couple of things: 

• Who’s consuming the logs? 
• What logs do they need? 
• Are cloud resource logs enough or is there a need for operating system level security events? 
• How long do they need those logs? 
• Is there a regulation or other external requirement that we need to comply with? 
• Is there a need for those logs to be resilient? 
• Who should be able to access those logs? 
• Where should these logs reside geographically? 
• Is there a need to integrate external systems to the log storage? 
• What does it all cost? 

These questions help us understand our logging needs. We want to avoid hoarding all logs, which would accrue excessive cost, because we didn’t want to study which logs are important for us. For security logs we want to restrict read and write access to them and also consider pros and cons of keeping those logs in their respective geography. 

 Log Analytics Workspace is the de facto log storage in Azure Cloud. Depending on the cloud resource type you can configure them to forward their resource logs to log storage either using an agent or via agentless configuration. We can automate and scale audit and resource log gathering using Microsoft Defender for Cloud environment settings and Azure Policies. Microsoft Entra ID sign-in logs are usually forwarded to a central log workspace where these identity and authentication events can be correlated with Azure activity logs and resource logs to enable better, more accurate detections. 

What makes building detections from scratch quite hard in Azure is the fact that there are inconsistencies and exceptions in the log schema.

Analyzing the data

Now that we have visibility, we need to be able to analyze our logs. In Microsoft Defender for Cloud, we have built-in threat detection provided by each enabled Defender Plan. These advanced detections from specific resource types raise security alerts and incidents. 

Furthermore, these logs and incidents can be ingested into Microsoft Sentinel where there are built-in detections, but more specifically custom detections can be crafted as well to address special needs and existing gaps. Sentinel offers tools for automating detections and makes it easy to continue to incident response process. We could ignore Sentinel and run our custom queries against the Log Analytics workspace, but we’d end up with more resources – to manage the automated querying which then increases our attack surface and management overhead. 

There are other possibilities for custom detection needs, but all of them require specific knowledge and a bit more configuration effort. We could store logs in Azure Storage or Azure Data Explorer (ADX) and then build our custom detections on top of those. This is more laborious route as we have to maintain all detections by ourselves, and we would need to implement some incident response capabilities as well. 

What makes building detections from scratch quite hard in Azure is the fact that there are inconsistencies and exceptions in the log schema that has evolved over time when separate product teams have chosen different paths for their logging schema.

Comparing an IP address data of one resource log to an IP address data on another might not be achievable without some string parsing first.

Defenders think in lists. Attackers think in graphs.

John Lambert, Microsoft

Threat Hunting

To complement built-in detections that continuously analyze the environment, there are threat hunting capabilities offered by Microsoft Sentinel. 

Threat hunting is typically operated in proactive manner where a security analyst has a hypothesis of a threat and building hunting query to test the hypothesis requires technical knowledge and understanding of both the cloud workloads and the supposed threat. 

Successful threat hunt may lead to new built-in detection rules. Consider it being more like precision tool whereas automated reactive detections are like a wide broom capable of detecting wide range of known threats. 

In addition to Sentinel’s threat hunting, Defender CSPM Plan offers Attack Path Analysis. It is not assessing single workload configuration or environmental security posture, instead it’s based on an algorithm that uses the security graph of the environment to find potential attack paths. Famous quote by John Lambert is more true than ever: Defenders think in lists, attackers think in graphs. That’s why finding and securing these attack paths is important to mitigate threats targeting organizational crown jewels. 

Included in the same Defender CSPM Plan is also Cloud Security Explorer. I wouldn’t consider it threat detection capability, but rather a similar concept like threat hunting, but for cloud workload misconfigurations. More like proactive risk hunting. It uses a nifty query builder experience which significantly lowers any beginner’s threshold for gaining value from Cloud Security Explorer. 

Cost management

One often overlooked angle to detection is cost alerting. Azure Cost management tools enable setting a budget for a scope e.g. Azure subscription. When budget is set, alerting can be configured to notify an owner of the consumption progress. There are legitimate reasons why costs would change drastically on a given time period, but there are cases where the attacker is spinning up expensive resources for crypto-mining. This type of an attack has a limited lifetime because the cost impact will be noticed at latest when invoiced – but that might be too late. By default, Microsoft is not responsible for covering the costs incurred. Budget alerts cost practically nothing compared to the malicious expensive resources that are deployed in secrecy. 

Summary

Native tooling like Defender for Cloud, Sentinel, Azure Monitor Logs can cover a lot of ground easily when discussing detections in Azure. To detect and protect from threats in our Azure environment, we start by adopting Defender for Cloud and checking out Defender Plans which enable Cloud Workload Protection (CWP). 

 When we have Microsoft 365 E5 commitment, and possibly some third-party vendor tooling, we should start moving towards Microsoft Sentinel which covers a lot of integrations and enable custom log ingestion. The more systems we can integrate, the more log data points we have and thus better detection coverage and accuracy we have, decreasing the incident fatigue that comes with false positive incidents. 

Building custom detections may be inevitable at some point, but in the AI-era we need to have native AI-backed tools making most of the heavy lifting if we want to be able to detect both anomalous events and pre-breach attack paths. 

Want to identify blind spots in your Azure security?

Let’s talk!

Our specialized security experts can help you stay ahead of cloud security threats.
Leave your contact information below and we’ll get back to you.