Coverage assessment
We map your current detections to MITRE ATT&CK and show you where the gaps are, and more usefully, which of your existing rules have never fired a true positive.
Detections your analysts will actually keep switched on.
Most SIEM deployments fail the same way: hundreds of rules shipped by a vendor, thousands of alerts a week, and a team that has quietly stopped reading them. We build detection content against your telemetry and tune it until the signal-to-noise ratio is one a human can work with.
What we do
Retainer-based. Monthly content drops, tuned against what your environment actually produces.
01
02
Rule development
Sigma as the source of truth, compiled to your platform’s query language. Written against your log sources, not a generic sample set.
03
Validation
Every detection tested with Atomic Red Team or a hand-built equivalent, so we know it fires on the technique rather than on a string that happened to appear in a sample.
04
Tuning
The part vendors skip. We run each rule against historical data, measure the false-positive rate, and tune until it is low enough that an analyst will trust the alert.
05
Documentation
Each detection ships with the technique it covers, the data source it needs, known false positives, and a triage runbook. A rule nobody knows how to action is noise.
06
Maintenance
Detections decay. Log formats change, attackers adapt, and your environment shifts. The retainer covers keeping the content alive rather than delivering it once.
Platforms
Primarily Splunk, where we have current production experience, and Elastic. Sigma rules are portable, so the detection logic transfers even where the query syntax does not.
How engagements are priced
Monthly retainer rather than per-rule. Per-rule pricing incentivises writing many bad rules, which is precisely the problem we exist to fix. Scope is agreed as a number of techniques covered per month, with tuning and maintenance of everything previously delivered included.
Talk to us for a quote. This one genuinely depends on your log volume, source diversity, and how much existing content needs remediation.
On our track record here
We currently run detection engineering for a client on Splunk under an NDA that prevents us naming them or describing their environment. We would rather say that plainly than imply a longer client list than we have. Ask us on a call and we will describe the work in as much detail as the agreement permits.
Open-source detections
We publish Sigma rules we have written where they are not client-specific. If you want to evaluate the quality of our detection logic before engaging us, read the rules rather than the sales page. github.com/inversez
Where the gaps actually are.
A coverage assessment produces this before it produces anything else: every technique in scope, scored against what your existing rules genuinely detect rather than what the vendor documentation claims.
Covered · 43
Partial · 25
No coverage · 28
96 techniques · 12 tactics
Read it as a table
| Tactic | Covered | Partial | No coverage |
|---|---|---|---|
| Initial Access | 5 | 3 | 0 |
| Execution | 5 | 2 | 1 |
| Persistence | 3 | 2 | 3 |
| Priv Esc | 5 | 2 | 1 |
| Defense Evasion | 4 | 3 | 1 |
| Cred Access | 2 | 3 | 3 |
| Discovery | 4 | 1 | 3 |
| Lateral Move | 2 | 2 | 4 |
| Collection | 1 | 3 | 4 |
| C2 | 3 | 2 | 3 |
| Exfiltration | 6 | 0 | 2 |
| Impact | 3 | 2 | 3 |
Illustrative shape, not a real client environment. The interesting column is usually not the empty one. It is the half-covered one, where a rule exists, fires occasionally, and has never once produced a true positive.
Start with a coverage assessment.
We map what you have against ATT&CK, identify the rules that have never produced a true positive, and show you the gaps that matter for your threat model. It is the cheapest way to find out whether a retainer is worth it.
- No obligation to continue afterwards
- You keep the assessment either way
- Splunk and Elastic