Open-Sourcing Sigma Rules: Detective Controls as Portable Detections
We are releasing Sigma rule packages for AWS S3 and GCP BigQuery, turning our detective controls into detection logic you can convert into queries for most SIEMs.
Today we are open-sourcing Sigma rule packages for AWS S3 and GCP BigQuery. Sigma is a portable detection format: you write the detection logic once and convert it into queries for most SIEMs and log platforms. We have taken the detective controls from our threat models, the ones that already say exactly what to look for in the logs, and expressed them as Sigma rules so customers can deploy them without rewriting the logic by hand.
This release covers 15 AWS S3 controls and 4 GCP BigQuery controls, all built on the native cloud log source (CloudTrail for AWS, Cloud Logging for GCP). Azure Storage rules will follow after a control revamp.
Why Sigma, and Why Now
When we published our open-source Wiz Custom Configuration Rules, we made our preventive and configuration controls deployable as code for one platform. Detective controls are a different problem. A detective control monitors a specific indicator of compromise, a logging event with specific parameters, or abnormal usage in monitoring metrics, and the way you implement that detection depends entirely on which SIEM, monitoring or log platform you run.
Our customers want detections they can deploy. Our threat models already give them the what: every detective control spells out the exact event and fields that signal a problem, in plain English. The gap was the how, the translation step where they had to take that description and hand-write a query for Splunk, Microsoft Sentinel, Elastic, Google Security Operations, or whatever platform they run.
Sigma closes that gap. It is a portable detection rule format for logs, similar in spirit to how YARA describes patterns for files. You write one rule in a readable YAML format, then a backend converts it into a query for your specific platform. Sigma lets analysts express what to look for, while the platform-specific backend handles how to query it.
Here is what a Sigma rule looks like, using Sigma's own official AWS root account usage example:
title: AWS Root Credentials
description: Detects AWS root account usage
logsource:
product: aws
service: cloudtrail
detection:
selection:
userIdentity.type: Root
filter:
eventType: AwsServiceEvent
condition: selection and not filter
falsepositives:
- AWS Tasks That Require Root User Credentials
level: mediumYou write the rule once, then run it through the Sigma converter for your platform. For Splunk, sigma convert -t splunk -p config.yml turns the rule above into a native query:
sourcetype="aws:cloudtrail" userIdentity.type="Root" NOT eventType="AwsServiceEvent"The same rule converts to a query for Microsoft Sentinel, Elastic, Sumo Logic, CrowdStrike, Rapid7, and other supported backends. That is the whole point: write the detection logic once, deploy it wherever you keep your logs.
What Is in Scope for This Release
Sigma is focused on detection rules for logs, so the scope is our detective controls. For this first release we narrowed scope further: only detective controls that use the default native audit log service for the cloud provider are included. For AWS that means CloudTrail events. For GCP that means Cloud Logging events. Controls that depend on a different source are out of scope for now, for example Amazon Macie findings, GuardDuty malware scanning, or BigQuery Admin Resource Charts.
Sigma rules contain the detection logic, but many detections require environment-specific values such as account IDs, project names, resource identifiers, or other deployment-specific parameters. To make those requirements explicit, we use variable files: structured templates that tell you exactly which values need to be supplied for a particular rule.
We are publishing the Sigma rules and their corresponding variable files together. The rule files contain the detection logic, and the variable files provide the deployment-specific inputs needed to operationalize them.
| Service | Log source | Controls covered | Status |
|---|---|---|---|
| AWS S3 | CloudTrail events | 15 | Released |
| GCP BigQuery | Cloud Logging | 4 | Released |
| Azure Storage | Azure activity log | To follow | In progress |
Rule Modes: Universal, Allowlist, Denylist
Each control can be translated into up to three rule modes, the same approach we took with the open-source Wiz CCRs.
- Universal mode: the log pattern provides everything the rule needs, with no customer input. Used when a rule should apply with no exceptions.
- Allowlist mode: needs customer input via variables. The rule fires on every event that is not tied to a resource the customer marked as authorized.
- Denylist mode: the opposite. The customer supplies the unauthorized values, scoping detection to specific bad values.
Not every control needs all three modes, and very few implement all three.
How Variables Keep Rules Portable
A variable is a named placeholder embedded in the rule, written as %variable_name%, resolved at query-generation time through a transformation file. Variable names are per rule, not shared, and each carries the control ID as a suffix. We ship one example variable file per cloud provider and service. You copy it, replace the placeholders with your real values, then pass it to a Sigma parser such as sigma-cli or pySigma at conversion time.
Mapping Severity to Sigma Levels
| TrustOnCloud severity | Sigma level |
|---|---|
| Very High | critical |
| High | high |
| Medium | medium |
| Low | low |
| Very Low | informational |
One principle underpins the library: every Sigma rule must remain aligned with its corresponding detective control. Threat modeling is not a one-time exercise, and neither is detection engineering. As we refine controls, incorporate new learnings, and adapt to changes in cloud services and attacker behavior, the Sigma rules evolve alongside them. The goal is to keep the library accurate, relevant, and continuously aligned with our latest guidance.
Collaboration with the Sigma Community
Building this release meant working closely with the Sigma community. Thomas Patzke, a Sigma co-founder and core contributor, reviewed our approach, repository structure, and rule implementation, and his feedback helped align the project with established Sigma practices. We are grateful for the time he gave it.
This is the start of an ongoing commitment for us. We plan to contribute these rules to the Sigma community ruleset, keep refining them with community feedback, and expand coverage across more services. Sharing detection logic back with the ecosystem is how the whole community gets stronger, and we want TrustOnCloud to be an active part of that.
What's Next
- Azure Storage. Threat models are living artifacts that continuously evolve. Azure Storage is currently undergoing a threat and control enhancement initiative. As that work progresses and new detective controls are introduced and refined, the corresponding Sigma rules will be released alongside them.
- More services. Expand Sigma coverage across more threat models, prioritised by customer demand.
- Broader detective scope. As more detective controls align to native log sources, more become expressible as Sigma rules.
Closing Thoughts
Our preventive controls became deployable code with the Wiz CCRs. With Sigma, our detective controls do too, not for a single platform, but for any SIEM with a Sigma backend.
This is the direction we want our threat models to keep moving: more insightful, more practical, and more actionable. Threat modeling is often treated as an abstract exercise, but its real value is in turning knowledge about how systems can fail into controls that teams can deploy, monitor, and improve.
If you have questions, feedback, or want to see how this maps to your detection stack, reach out.