Multi-Cloud Detection & Response Without Drowning in Alerts
One SIEM, three clouds, 40,000 alerts a day. Here's the detection engineering approach that gets your team back to signal — with a reference stack you can copy.
RAZR Advisory
7 min read
The multi-cloud alert problem
A typical mid-size shop runs workloads across AWS, Azure, and GCP. Each cloud ships its own detection service (GuardDuty, Defender for Cloud, SCC). Piped raw into a SIEM, you get:
- Duplicate alerts for the same identity across clouds
- No consistent severity model
- No context — "port scan detected" without knowing if the target is production
Detection engineering, not alert forwarding
Stop forwarding vendor alerts. Instead:
- Normalize — every event maps to OCSF (Open Cybersecurity Schema Framework)
- Enrich — attach asset criticality, owner, environment at ingestion
- Correlate — detections run on the normalized layer, not per-cloud
- Tune — every alert has a documented FP rate; anything above 20% goes back to the drawing board
A reference stack that works
- Ingestion: Vector or Cribl to normalize into OCSF
- Storage: object storage (S3/GCS) + a query engine (ClickHouse, Snowflake, or Athena)
- Detections-as-code: Sigma rules in Git, tested with
sigma-cli - Response: Tines or Torq for automated triage of the top 10 detection types
The KPIs that matter
- Alerts per analyst per shift — target <30
- Time to close a benign alert — target <5 minutes with automation
- Detection coverage — % of MITRE ATT&CK techniques mapped to at least one rule, tested quarterly
Get those three under control and you'll retire more legacy tooling than any "platform consolidation" project promised.