Building an AWS Dete

How I built Sentinel Rules, a detection engineering project that turns AWS threat detection logic into version-controlled, testable, CI-validated code.

Why this project exists

Most cloud security portfolios lean heavily on offensive tooling: attack path analyzers, privilege escalation mappers, exploitation frameworks. Mine did too. I had built an AWS Attack Path Analyzer that could find 34 exploitable paths in a live account and score them for risk. It was a strong offensive piece, but it was missing its counterpart.

Finding an attack path is only half the story. The other half is catching someone who actually walks it.

That gap is what Sentinel Rules is built to close: an AWS Detection-as-Code engine that codifies threat detection logic as version-controlled Sigma rules, evaluates them against real CloudTrail activity, and maps every finding back to MITRE ATT&CK. It's the blue-team layer that complements the red-team work I'd already done.

Detection engineering principles

Writing a rule that says "alert when X happens" is easy. Writing a rule that survives contact with a real, noisy AWS account is a different problem entirely, and that difference is the actual discipline of detection engineering.

I structured the project around a threat model first, not a tool list. I asked: what does a real account takeover actually look like, step by step, in AWS? The answer, drawn from documented cloud breach patterns, looks roughly like this:

1. An attacker gets valid but stolen credentials
2. They disable MFA so they can't be locked out
3. They attach an administrator policy to escalate privileges
4. They create persistent access, in the worst case, a root access key
5. They open a data store to the public to exfiltrate
6. They pivot laterally into other accounts in the organization

Each of those six steps became a Sigma rule, tagged with its corresponding MITRE ATT&CK technique. Sigma specifically, not a custom format, because using an industry-standard rule syntax means these rules are portable to real SIEM tooling, not locked into a one-off script.

False positive reduction: the part nobody shows you

The moment I ran the engine against static test fixtures, it worked perfectly. Every rule fired exactly where it should. That felt like a finished project.

Then I pointed it at a live AWS account, using the AWS CloudTrail Event History API, and watched the "Suspicious Cross-Account AssumeRole" rule fire dozens of times in a single day. Every single hit was userIdentity.type: AWSService, AWS's own internal service-linked roles doing routine background work. Not an attacker in sight.

This is the part of detection engineering that separates a demo from a usable tool. A rule that fires on every legitimate automation event isn't a detection, it's noise, and noise is worse than nothing because it trains people to ignore alerts. I added an explicit filter to exclude AWS service principals and known CI/CD automation ARNs, then re-ran the engine. The false positives disappeared; the real signal stayed.

That tuning cycle, deploy against real data, get burned by noise, add a targeted filter, re-validate, is the actual job. It's also the story I'm proudest of in this project, because it's the difference between a rule that looks good in a README and a rule that would survive a week in a real SOC.

Correlation logic: making weak signals strong

Individually, an MFA deactivation event has a legitimate explanation. So does a privilege escalation event. Either one, alone, generates a medium-confidence alert at best, the kind of thing an analyst might reasonably dismiss.

But the same actor doing both within a ten minute window is a different story. That sequence, disable defenses, then escalate privileges, is close to a textbook account takeover pattern, and it's far less likely to have an innocent explanation.

I built a correlation rule specifically to catch this. It's the most technically interesting piece of the engine: it groups matching events by actor, sorts them chronologically, and checks whether all required event types occur within a defined timeframe for the same principal. When they do, it emits a single critical-severity alert instead of two separate medium-severity ones.

This is the same pattern real SIEM correlation engines use to reduce alert fatigue while actually improving detection of multi-stage attacks: don't just detect events, detect sequences.

Lessons learned

Testing catches things you don't expect. While writing unit tests for the condition parser, one test deliberately fed it a malformed expression to confirm it failed safely. It did fail, but with the wrong exception type, a SyntaxError instead of a clean, expected ValidationError. No actual code executed, since the parser's tokenizer had already stripped out anything dangerous, but it was a reminder that "it works" and "it fails safely" are two different claims, and only tests prove the second one.

Static fixtures lie by omission. They prove your logic is correct. They don't prove your rule is usable. Only real data, with its irrelevant background noise, its automation traffic, its unpredictable weirdness, tells you whether a detection rule is actually deployable or just theoretically correct.

Documentation is part of the engineering, not an afterthought. Writing out the threat model forced me to be explicit about what this project does and does not detect. It only sees what CloudTrail logs; if logging is disabled or a region isn't covered, an attacker is invisible to it. Writing that down isn't just for a README, it's an honest accounting of the tool's actual boundaries.

What's next

Sentinel Rules currently supports two-stage correlation chains and CloudTrail as its only log source. The natural next steps are GuardDuty finding ingestion as an additional signal, N-stage correlation for longer attack chains, and expanding coverage beyond IAM and S3 into services like Lambda and EC2.

The full project, including the Sigma rules, the Python detection engine, the test suite, and the CI pipeline, is open source: github.com/GeekyBlessing/sentinel-rules

---

Toriola Opeyemi is a Cloud Security Engineer focused on detection engineering, cloud security automation, and offensive security tooling. More at toriolaopeyemi.com.