Module 9 · Cloud Detection — Different Telemetry, Different Rules 🔒

Traditional SIEM was built for on-prem network + endpoint telemetry. Cloud-native environments produce different events at different scale — API calls, config changes, sign-ins from global IPs, serverless invocations, container spawns. Mature cloud detection requires specific tooling, rules, and investigation workflows. Most programs are behind.

Why cloud detection is different

• Volume + velocity: CloudTrail, Azure Activity, GCP Audit Logs generate millions of events per account per day.
• Most events are benign: auto-scaling spawns instances, Lambdas run routinely, CI deploys update configs. Signal-to-noise ratio brutal.
• Attacker moves are one API call: single CreateUser, AttachPolicy, AssumeRole — easy to miss in volume.
• Geographic distribution: legitimate activity from many IPs globally; anomaly detection must account for normal distribution.
• Identity-first: most attacks are credential compromises; detection centers on identity, not network.

Key log sources

# AWS
# - CloudTrail (API calls) — mandatory; multi-region + org-wide
# - CloudTrail Data Events for S3, Lambda (paid, verbose, valuable)
# - VPC Flow Logs — network-level visibility
# - GuardDuty (managed threat detection, enabled by default ideally)
# - Config (configuration change tracking)
# - Security Hub (aggregated findings)

# Azure
# - Activity Log (management plane)
# - Sign-in Logs (Entra ID)
# - Audit Logs (admin changes in Entra)
# - Diagnostic Settings per resource (data plane)
# - Defender for Cloud (threat detection)
# - Sentinel (SIEM)

# GCP
# - Cloud Audit Logs (Admin Activity — free always on)
# - Data Access Logs (paid, opt-in, valuable for forensics)
# - VPC Flow Logs
# - Security Command Center (threat detection)

Detection signals that matter

Identity

• Console login from country where user doesn’t normally work
• Impossible travel (NYC + Beijing within 1 hour)
• First-time use of credentials from a user’s existing keys
• MFA bypass indicators (legacy auth success)
• New admin role assignments
• New service principal creations with broad permissions
• User impersonation actions

Privilege / config

• IAM policy changes granting wildcard permissions
• New cross-account trust relationships
• SCP changes (AWS)
• New roles with AdministratorAccess
• CloudTrail disabled or log file deleted
• GuardDuty / Security Hub disabled

Data access

• S3 object-level data events: large number of GetObject from single IP
• DynamoDB, RDS large query volumes from unexpected source
• Secrets Manager GetSecretValue spike
• KMS decrypt anomaly — unusual key, unusual principal

Compute

• New EC2 instances in unusual regions
• Large / expensive instance types in dev account (cryptomining)
• Egress to tor exits, known-C2 domains, cryptomining pools
• Lambda invocation pattern anomalies
• Container images pulled from unexpected registries

Real detection successes and gaps

• SolarWinds discovery (2020): FireEye noticed unusual MFA enrollment in their own Entra tenant — single sign-in log event led to discovery. Good detection.
• Capital One (2019): SSRF → IMDS → data exfil happened before detection; discovered when attacker bragged publicly months later. Bad detection.
• Snowflake 2024: defenders noticed authentication pattern anomalies correlated with IOCs from Snowflake’s side. Multi-org response limited spread. Good.
• Ongoing: cryptomining attacks in cloud often detected by billing alerts first, not security tools. Detection gap.

Commercial tools for cloud detection

• AWS GuardDuty: native. Threat detection covering VPC flow + CloudTrail + DNS. Required baseline.
• Microsoft Defender for Cloud: Azure’s equivalent. Posture + threat detection.
• GCP Security Command Center Premium: threat detection (required tier for real detection).
• Wiz, Orca, Prisma Cloud: multi-cloud CSPM + runtime protection.
• Lacework, Datadog Security: unified observability + security.
• CrowdStrike Falcon Cloud Security: extending EDR to cloud.
• Vectra AI, ExtraHop Reveal(x) 360: NDR adapted to cloud.

Defender maturity model

1. L0: Cloud logs not collected. Zero cloud detection.
2. L1: Native tools enabled (GuardDuty, Defender for Cloud). Alerts sometimes reviewed.
3. L2: Cloud logs in SIEM. Basic correlation rules. Cloud-specific detection content.
4. L3: Custom detection engineering for cloud TTPs. ATT&CK cloud matrix coverage measurement.
5. L4: Continuous purple teaming in cloud. Automated response. Integrated with identity (Entra/Okta) for user-risk response.

Most enterprises L1-L2 for cloud. L3 is the high-value investment.

Mindset takeaway

On-prem detection experience transfers partially to cloud. The tools and signals differ. If your SIEM team has “we have CloudTrail ingest” but hasn’t written cloud-specific detections, you’re at L2 at best. Build cloud-native detections for identity, config, data access, and workload patterns — the four domains matter differently in cloud.