Theory — Anomaly Detection in Cloud Security

This page covers the core concepts behind anomaly detection — what it is, how it works, and how it fits into Day 5's labs.

---

What Is Anomaly Detection?

An anomaly is an event that deviates significantly from what is normal. In security, anomalies can indicate:

• A compromised account (unusual sign-in times or locations)
• Data exfiltration (unusual outbound data volumes)
• A misconfigured service (suddenly high CPU on a VM that normally runs idle)
• A supply chain attack (a dependency suddenly downloading new packages)

The challenge is that not all anomalies are threats. A user travelling to a new country is anomalous but not malicious. An application spike during a sales event is normal for the business.

---

Rule-Based Detection vs Statistical Anomaly Detection

These are two fundamentally different approaches:

Rule-Based Detection

You define specific conditions that indicate a threat:

// Rule-based: Detect admin sign-in from new country
SigninLogs
| where UserType == "Admin"
  and LocationDetails.CountryOrRegion !in ("United States", "Canada", "United Kingdom")
| summarize count() by UserPrincipalName, LocationDetails.CountryOrRegion

Pros: Simple, predictable, catches known attack patterns. Cons: Only finds what you've already thought of. Doesn't adapt to changing baselines.

Statistical Anomaly Detection

You establish a baseline of normal behaviour and flag deviations:

// Statistical: Detect unusual sign-in frequency for a user
SigninLogs
| where TimeGenerated >= ago(30d)
| summarize NormalCount = count() by UserPrincipalName
| join (
    SigninLogs
    | where TimeGenerated >= ago(1d)
    | summarize RecentCount = count() by UserPrincipalName
  ) on UserPrincipalName
| where RecentCount > 5 * NormalCount and NormalCount > 10

Pros: Catches novel threats, adapts to changing baselines. Cons: Harder to tune, more false positives, requires historical data.

---

Lightweight Anomaly Detection with KQL and Application Insights

You don't need expensive SIEM tools to detect anomalies. Azure's built-in monitoring can do a surprising amount of work:

Application Insights — Anomalies Detector

Application Insights includes a built-in anomaly detector that uses exponential smoothing algorithms to identify deviations in metrics like response time, request count, or error rate.

In the portal:

1. Navigate to your Application Insights resource
2. Click Analytics → New query
3. Write a KQL query against requests or exceptions tables
4. Use the built-in anomaly detection features in the results view

Simple KQL-Based Anomaly Detection Patterns

// Pattern 1: Sudden spike in error rate
requests
| where TimeGenerated > ago(1h)
| summarize Total = count(), Errors = countif(success == false) by bin(TimeGenerated, 5m)
| extend ErrorRate = Errors * 100.0 / Total
| where ErrorRate > 10  // Alert if error rate exceeds 10%

// Pattern 2: Unusual geographic access
SigninLogs
| where TimeGenerated > ago(24h)
| summarize Countries = dcount(LocationDetails.CountryOrRegion) by UserPrincipalName
| where Countries > 5  // User signed in from more than 5 countries in 24 hours

// Pattern 3: Storage access outside business hours
AzureActivity
| where OperationNameValue == "Microsoft.Storage/storageAccounts/listKeys/action"
  and TimeGenerated > ago(7d)
| summarize AccessHours = make_set(hour(TimeGenerated)) by Caller
| where has_any(AccessHours, ["2", "3", "4", "5"])  // Keys accessed at unusual hours

---

Azure Defender for Cloud vs Manual KQL Hunting

Both approaches have value. Understanding when to use each helps you design effective monitoring:

	Defender for Cloud	Manual KQL Hunting
What it detects	Known patterns, misconfigurations	Unknown threats, novel attack patterns
Setup effort	Enable and configure	Requires writing and tuning queries
Coverage	Broad but shallow	Narrow but deep
Best for	Baseline monitoring	Targeted investigation

When to Use Defender for Cloud

• You need broad coverage across your infrastructure
• You want to catch known misconfigurations automatically
• You're just starting with security monitoring
• You don't have time to write custom queries

When to Write Custom KQL Queries

• Defender for Cloud isn't catching the specific threat you're worried about
• You need to correlate events across multiple data sources
• You want to detect a novel attack pattern
• You need more context than Defender provides

The practical approach: Use Defender for Cloud as your baseline, then write custom queries for the specific threats that matter to your organisation. In production environments, these KQL queries are typically converted into Azure Sentinel analytics rules, which can trigger automated response actions through Logic Apps.

---

The Importance of Baselining

Before you can detect anomalies, you need to know what normal looks like. This is called baselining, and it's often skipped — which leads to lots of false positives.

How to Establish a Baseline

1. Collect data first — Don't enable alerts until you've seen at least 2–4 weeks of data
2. Identify patterns — Look for daily/weekly cycles, business hours vs off-hours, seasonal variations
3. Define thresholds — Set thresholds based on the observed patterns, not arbitrary numbers
4. Validate — Check that your rules don't fire during normal operations

Example: Establishing a Baseline for API Traffic

// Collect baseline data over 2 weeks
requests
| where timestamp > ago(14d)
| summarize AvgCount = avg(Requests), StdDev = stdev(Requests) by bin(timestamp, 1h)
| project Hour = hour(timestamp), DayOfWeek = weekday(timestamp), AvgCount, StdDev

// Now you can set a threshold: Alert when count > Avg + 3*StdDev

Without a baseline, you might set an alert at "more than 100 requests per minute" — but if your application normally handles 95 requests per minute during peak hours, that alert fires constantly.

---

Avoiding Alert Fatigue

Alert fatigue is the number one reason security monitoring fails. When analysts receive too many alerts, they start ignoring them — including the ones that matter.

Common Causes of Alert Fatigue

1. Too many rules — Every possible threat gets its own alert
2. Poor thresholds — Rules fire on normal variations in behaviour
3. No prioritisation — All alerts look equally urgent
4. No feedback loop — Analysts can't mark false positives, so the rule keeps firing

Strategies for Reducing Alert Fatigue

Strategy	How It Works
Tier your alerts	Critical → Immediate action; High → Investigate today; Medium → Investigate this week; Low → Review monthly
Group related alerts	Instead of 10 alerts for a single incident, create one "incident" that groups them
Tune thresholds regularly	Review alert volume weekly. If a rule fires more than once per day, tune it
Enable feedback loops	Allow analysts to mark alerts as false positive, and use that data to improve rules

The 10% Rule

A practical guideline: if your team is receiving more than 10% of alerts that turn out to be false positives, you have an alert fatigue problem. Tune aggressively until you're below that threshold.

---

Key Takeaways

1. Anomaly detection finds unusual events; rule-based detection finds known threats. Both are needed.
2. Statistical anomaly detection requires historical data — establish a baseline before enabling alerts.
3. Simple KQL queries can detect anomalies without expensive SIEM tools.
4. Defender for Cloud provides broad baseline coverage; custom KQL provides targeted deep detection.
5. Alert fatigue is the number one reason monitoring fails — tune your rules and prioritise your alerts.

---

Sources

• Application Insights Smart Detection for anomalies — Microsoft Learn