What Does It Actually Detect?
A question most SIEM vendors answer with a number. Here is the rule count, the technique coverage, how the rules get onto your appliance safely — and which of them your estate can actually run.
In short
- 104 detection rules, covering 52 adversary techniques across 11 of the 12 ATT&CK tactics.
- Rules are data, not code. Sigma-compatible YAML you can read, audit and contribute to — not a black box you have to take on trust.
- Coverage never claims what your estate cannot deliver. Rules needing a connector you do not have are reported separately as latent, not counted as protection.
- Content updates are signed and verified before they are parsed. The trusted keys are built into the appliance image and cannot be added at runtime.
- Suppressions expire. A rule silenced during a migration does not stay silenced for two years because nobody remembered.
The numbers, and what they exclude
Thirteen rules need a source a given estate may not have: six want a Microsoft 365 connector, four a Fortinet firewall connector, three the Aperlock Scope bridge. The remaining five are operational rules — drive failure, backup job failure, certificate expiry, storage capacity, server health — counted apart from the security set because they detect a failure rather than an adversary.
A rule that needs a data source you do not have is shipped disabled and reported separately. It never contributes to a coverage figure, because a coverage map that counts protection the deployment cannot deliver is worse than no map — it produces confidence rather than a work item.
Connect the source and the rule activates, and the coverage figure moves for a real reason.
Coverage is exportable as an ATT&CK Navigator layer, so it can be compared against your own assessments rather than taken on our word. A test asserts that every shipped rule has a coverage entry, so the map cannot quietly drift from the rule set.
Detection content is data, not code
Every rule is a Sigma-compatible YAML document. That has three consequences that matter more than the format itself.
- You can read what it detects. Not a marketing list of threat names — the actual matching logic, in a format an analyst can review and a consultant can audit.
- Content ships independently of the product. A new detection does not require a software release, so the gap between a technique being published and your appliance detecting it is a content update rather than an upgrade cycle.
- The community contributes data, never code. Detections can come from outside; executable extensions cannot. No third-party code runs inside a deployed appliance, by architectural decision.
How updates reach the appliance without becoming an attack
Content decides what the system detects. An attacker who can inject content does not need to evade detection — they switch it off, in the one system whose job is to notice, across every customer rather than one.
Everything in this path fails closed.
- The signature is verified before anything is parsed Parsing first would hand an attacker the YAML parser — a far larger attack surface than the signature check meant to gate it.
- Signatures cover the exact bytes Not a re-serialisation. The same data can be written many valid ways, so a round trip through a parser would break verification for innocent reasons and invite someone to relax the check.
- Every document is hashed against the signed inventory A tampered rule inside a validly signed package is still rejected.
- Any failure aborts the whole package A half-applied update leaves an estate whose detection set nobody can describe.
There is deliberately no setting, environment variable or file path that can add a trusted signing key at runtime — a key an attacker with file access can add is not a key. Keys are embedded in the appliance image at build time.
An appliance built without them verifies nothing and therefore applies nothing, which is the correct posture for a build that has not been given an identity to trust. Two keys are embedded rather than one, so losing a single key cannot strand every fielded appliance.
Two engines, both on a sixty-second cycle
Both run continuously on the appliance and evaluate every sixty seconds. Only one instance evaluates rules regardless of how many worker processes are running, so a rule cannot fire twice for the same event.
| Shape | What it matches | Example |
|---|---|---|
| Threshold | N matching events within a time window | Repeated failed logons from one address |
| Count, grouped | N events grouped by user, host or address | One account failing against many machines |
| Distinct count | Breadth rather than volume | One password tried against many accounts — a spray |
| Sequence | Event A followed by event B on the same entity, within a window | Share access to an administrative share, then a new service |
A brute-force rule counts failures against one account and catches the loud attack. A password spray does the opposite — one password, many accounts, never enough failures per account to trip a threshold. Counting distinct accounts rather than attempts is what separates the two.
Suppression that does not become amnesia
Every estate has legitimate activity that looks like an attack: a backup agent authenticating oddly, a vulnerability scanner sweeping the network, a migration generating thousands of file operations.
- Suppressions carry an expiry date. A rule silenced for a weekend migration comes back on its own.
- Suppressions carry a reason. Written down at the moment somebody knew why, not reconstructed a year later.
- Suppression is not deletion. The underlying events remain searchable; only the alert is withheld.
A permanent suppression added during an incident, by somebody under pressure, with no note and no expiry, is indistinguishable a year later from a detection that was never written. Expiry turns that from a silent hole into a decision somebody has to make again.
Common questions
Can we write our own detections?
Yes. Rules are Sigma-compatible YAML, so a rule written for the wider Sigma ecosystem is close to portable, and one written here is close to portable elsewhere. You are not buying into a rule language you can only use in one product.
Can we run third-party plugins or scripts?
No, and that is deliberate rather than a gap. Detections are contributed as data; executable extensions are not accepted. Nothing written by a third party runs inside a deployed appliance. That closes an entire category of supply-chain risk at the cost of some flexibility, and for this customer base it is the right trade.
How quickly do new detections arrive?
Content updates are independent of software releases, so a new detection is a signed content package rather than an appliance upgrade. Nothing is applied unless it verifies against a key already built into your appliance.
Why is your rule count lower than other vendors quote?
Because we only count what your estate can actually run, and we do not count variants as separate rules. Thirteen of ours are reported as inactive precisely because they need a source a typical on-premises firm does not have. A large rule count that includes everything the vendor has ever written is a marketing figure, not a coverage figure — ask any vendor how many of their rules are active in a deployment like yours.
What is not covered?
One ATT&CK tactic has no coverage, and eight techniques are reachable only through connectors many estates lack. Detection also depends entirely on the telemetry reaching the appliance — a technique executed on a machine sending no logs is invisible regardless of how many rules exist. The coverage export shows exactly where those edges are.