01
Rules accumulate, nobody prunes
Detections are added under incident pressure and never retired. Five years in, the estate is thousands of rules, a tenth of which produce nearly all the alerts, and no one can name which.
About
Detection is an engineering discipline.
We staff it like one.
DetectionOps builds detection functions the way good teams build software: in version control, under test, reviewed by a peer, deployed by pipeline, measured in production and deleted the moment they stop earning their place.
We are practitioners, not a reseller. We write rules, break them on purpose, and publish the ones that survive along with the conditions under which they fail.
Detection-as-code pipelinesWindows and Active DirectoryIdentity and Entra IDCloud audit telemetryPurple team validationSIEM migrationLog-source engineeringRule health and decay
Why we exist
Detection programmes fail in three predictable ways
None of them are about not knowing the techniques. They are about running a software problem without software practice.
02
Coverage is asserted, never measured
A spreadsheet maps rules to ATT&CK. It proves a rule was written, not that it works, and it never goes backwards even as telemetry and tooling change underneath it.
03
Rules go quiet and nobody notices
A log source stops arriving, a field gets renamed, an agent upgrade changes an event ID. The detection does not error. It simply stops firing, and silence looks exactly like safety.
Every one of those is solved practice in software engineering. Version control, tests, code review, CI, monitoring and deprecation are not novel ideas. They are simply not yet the default in detection, and that is the gap this company was built to close.
How we operate
Six positions we will not negotiate
These shape every engagement, every rule in the library and every feature in the platform. If one of them is wrong for your organisation, we are probably the wrong firm.
Detections are code, not settings
A rule that lives in a console text box has no history, no reviewer and no test. Everything we write lands in Git, goes through pull request, and is deployed by a pipeline that can roll it back.
Detonation or it did not happen
Coverage claimed from a rule name is a guess. A detection counts once an atomic test has fired it in the environment it defends and the alert reached a queue a human reads.
We delete more than we add
The hardest number to move in a SOC is alert volume, and it almost never comes down by writing rules. Most estates we meet can lose a third of their detections and detect strictly more.
Coverage expires
Validation has a shelf life. A technique proven 90 days ago against an agent version that has since shipped four releases is not covered, it is assumed. Our boards fade on purpose.
A detection without failure modes is a draft
If nobody has written down what makes a rule fire wrongly, nobody has finished thinking about it. Documented false positives are a merge requirement here, not a nice-to-have.
We leave capability, not dependency
The measure of an engagement is what your team can do after we go. Every build ends with your engineers running the pipeline, reviewing the rules and owning the standard.
In the open
Our work is inspectable before you pay for any of it
The rule library, the write-ups and the coverage board are free and permissively licensed. Read them first and decide whether we think the way you want your detections thought about.
Open rule library
26 detections across 4 query languages, each published with its log-source requirements, documented false positives and the validation steps that proved it fires.
Browse the library →
Field notes
Long-form walkthroughs of individual detections, including the versions that did not work and why. The failed attempts are usually the useful part.
Read the notes →
Coverage board
26 of 39 tracked techniques carry a rule, 26 of them validated inside the last 90 days. The board is computed from the library, so it cannot flatter us.
See the board →
The standard
What has to be true before we call a rule finished
- It is expressed as Sigma unless the logic genuinely cannot be, and the exception is recorded.
- The log sources it depends on are named, along with the configuration that produces them.
- Its false positives are written down, with the environments that cause them.
- An atomic test has fired it, and the date that happened is attached to the rule.
- It carries a severity that reflects what a responder should actually do at 3am.
- Someone other than the author has read it and agreed.
Tell us what is not firing
Most conversations start with a specific frustration: an estate nobody can prune, a migration nobody wants to port, a coverage map nobody believes. Bring that, not a requirements document.