One pipeline, many clouds
Cloud native detection rules age fast. The provider changes a log field name and your alert silently stops firing. A multi cloud estate compounds the problem by three.
The pattern that works is detection as code. Rules live in git, get reviewed in pull requests, run against replay corpora in CI, and ship to whichever SIEM you operate.
Schema
We normalise CloudTrail, Entra ID, GCP audit, Kubernetes audit, and EDR telemetry into the OCSF schema. Rules are written against OCSF fields, so a rule that detects suspicious AssumeRole works the same shape for an Entra ID role activation.
Rules and tests
Sigma is the rule language. Every rule has a name, a description, a MITRE ATT&CK mapping, a severity, and a test fixture in the corpora. Pull requests cannot merge without a passing test.
- rule library mirrored to sentinel, splunk, and chronicle
- unit tests with synthetic and replayed real events
- detection coverage tracked against att&ck matrix
- severity drives notification channel (slack, pagerduty, jira)
- auto enrichment with asset and identity context
Response
High severity events trigger SOAR playbooks. Common actions: just in time revoke a role, snapshot a disk for forensics, page the on call. The aim is a mean time to respond under fifteen minutes for the top alert classes, measured weekly.
References
Official documentation and standards we draw on for this pattern.
Sigma rule format
github.com
OCSF schema
schema.ocsf.io
MITRE ATT&CK
attack.mitre.org
Microsoft Sentinel documentation
learn.microsoft.com
Google Chronicle SecOps
cloud.google.com
Links open in a new tab
Takeaway
A detection programme is a software product. Treat it like one. Code review, tests, releases, metrics.