Most teams have never seen it.
Coverage percentages come from counting rules. We get the number the other way round: replay the technique, watch the SIEM, and write down what fired, what stayed silent, and how long each one took.
Run Wazuh? Rule Doctor Lite is free: one read-only Python file that lists the custom rules that never fired, and why — including the ones Wazuh drops at load.
“Nobody publishes how low” is the reason we did. Same bench, same terms, method and limits in the body: Detection Reality Index Vol.1 (the 3 / 24 run) · Vol.2 (IBM QRadar) · Vol.3 (what moves between two audits).
One problem on your own Wazuh, reproduced on your exact version. You get the change and the steps, you apply it on your system, and you pay only once it works there. If it doesn’t work, you owe nothing.
A rule or decoder that doesn’t fire, an agent, vulnerability detection, or one log source. For a silent rule we work out why — shadowed by a sibling rule that matches first, an event that never reaches the manager, no event that matches it, or a rule Wazuh dropped while loading — by replaying the events you send and reading the manager’s own log, not by reading rule IDs.
Alerts that never reach the indexer: mapper_parsing_exception in Filebeat, a field that is an
object in one event and a string in the next, documents dropped without a trace. You get the pipeline processor
and index template, tested on an indexer of your version against your event samples, with apply and rollback steps.
One fix for USD 49, in exchange for an anonymised write-up we can publish.
We agree the scope in one email: the problem, your Wazuh version, the samples. We deliver files and steps. When they work on your system — the rule fires on the replayed event, or the samples index with no mapping error on the next daily index — ATK sends the invoice (bank transfer or an online payment link). We never need write access to your systems.
We build a twin of the stack you want measured — hosts, roles, network zones and the SIEM configuration — as a graph. No agent is installed on your side and no production system is involved.
Real techniques run against the twin: credential brute force, lateral movement, ransomware behaviour, command and control. Not synthetic log injection — the attack actually executes.
Every technique is timed against the SIEM's own alert stream. The same SSH brute force (T1110.001) alerted in roughly 0–2 s on Wazuh, ~4 s on Splunk and ~4–8 s on QRadar. Those are clock readings, not estimates.
Where we have detection content for a silent technique, it comes back with the report, and re-running shows the delta. Two honest limits: not every gap we find has a rule behind it, and each rule is labelled either verified — loaded into a live SIEM and observed to fire, or not yet verified. We will not hand you a rule of the second kind and call it a fix.
These are enforced in the software, not promised in a contract. A promise can be forgotten. A gate runs on every job.
“No alert” has three possible causes. Only one of them is your problem.
The monitoring missed it · the monitoring received nothing to miss · the attack never reached the sensor. Before we call anything a gap, the software has to prove the log pipeline was alive inside the measurement window. If it cannot, the cell is labelled UNMEASURED, with the reason printed verbatim — and it is excluded from your gap list, from the coverage denominator, and from the invoice.
We say whose monitoring we measured.
By default the measurement runs on a replica on our bench, built from what you declared. The attack is real, the alert is real, the rule ID and detection time are real — but the thing being measured is the replica, not the system you are running. Every coverage figure carries that label next to it, not in a footnote. If you give us access to your own SIEM, the label changes accordingly.
We do not bill a measurement that could not measure.
Every run records how many techniques were actually measurable. If none were — a dead log pipeline, an expired SIEM licence, an attack that never landed — the run is marked non-billable with the reason, and you can read that ledger yourself.
We publish our own error bars, including the corrections.
We ran both of our modes against the same twin, compared them cell by cell, and published the confusion matrix — along with a correction to our own sales document when a later review showed one of our figures was wrong. A buyer who watches a vendor retract a claim should trust the remaining claims more, not less.
What fired. What stayed silent. How long each one took.
A report on one stack profile, in language a technical buyer can check and a non-technical one can act on. It runs on our bench, so nothing goes through your change board and nothing goes through your procurement.
A number you can put in a renewal conversation or a competitive pitch — evidence that the tuning you did is worth what you charge for it, rather than an assertion the client is asked to trust.
A third-party measurement. A number your own team produced is the one a board quietly discounts; the one that travels is the one you did not produce yourself.
We configure a build to match one of your stack profiles and measure that. The report characterises that build, not your live estate — and it says so, in the report, in those words. Anyone selling you a bench result as a measurement of production is selling you something they cannot deliver.
A pentest answers can this be exploited? This answers would anyone have seen it? The two are complementary, and a pentest report carries no detection telemetry.
This measures configuration and deployment. It is not a verdict on any product you have partnered with or resold.
Pilot. Live demo environment, single-tenant per twin, no production customer deployment yet. We would rather tell you that here than have you find out in week three.
The Wazuh fix notes on atkvn.com are signed with this name, and each one says what was measured, on which Wazuh version, and where the measurement stops. You can check who you are writing to on LinkedIn.
The legal entity that signs, invoices and receives payment. Tax ID 0110935486. No. 1, Lane 454 Xuân Đỉnh Road, Xuân Đỉnh Ward, Hanoi, Vietnam.
An invoice from ATK, sent after the fix works on your system: bank transfer in USD, or an online payment link (cards accepted). A fix isn’t charged up front, and there’s nothing to pay before the scope is agreed in writing.
Detection measurement with VCyber Twin is priced per stack profile: write to support@atkvn.com.