Connecting to Cyberolog Lab… Open the live PulseLive Pulse
For SOC teams and MSSPs · works on top of your SIEM

Detections don't break loudly.
They go quiet.

Cyberolog Fleet keeps a heartbeat on every rule in your SIEM. It checks each one, branch by branch, and shows which can still fire. Each answer comes with the evidence behind it.

Read-only to start. Nothing in your SIEM is changed.

Works with
Livenano.rsSplunk
In progressElastic Security
PlannedMicrosoft Sentinel
Another SIEM? Tell us which.

Live means rules are inventoried, checked and attack-tested on that SIEM today.

One beat per hour of real pipeline runs on Cyberolog Lab; red beats are hours where a run failed.
Every beat is one real hour of automated runs on our lab SIEM. ran   a run failed, and it shows   nothing scheduled
Sound familiar?

Six sentences you may recognise.

It says enabled. It hasn't matched anything since March.

Fields go empty, parsers change, sources move. The rule stays green in the SIEM and can never fire again.

We cover T1059. Has anyone checked?

An ATT&CK mapping is a claim. The heatmap turns green whether or not the rule ever caught the technique.

Turned it off during the incident. Forgot to turn it back on.

The 3 a.m. fix leaves a gap for months, exactly where an attacker would want one.

Who disabled this rule? And why?

Scripts, analysts and vendor auto-tuning all toggle rules, and nobody can say who changed what.

Forty customers, forty copies of the same rule. Which ones still work?

Each tenant has its own log sources and field names. A rule that fires for one customer can be blind for the next.

The customer asks what they are paying for. We send an alert count.

Alert volume says nothing about coverage. Proof per rule is something a customer can read and an auditor can keep.

13%

of SIEM rules are broken and will never fire.

CardinalOps, State of SIEM Detection Risk 2025, 13,000+ rules
58% → 14%

of simulated attacks were logged, but only 14% raised an alert.

Picus Blue Report 2026
Deployed and enabled is not the same as proven to work.

A log source changes, a field goes empty, a parser is updated. The rule stays green and stops matching.

How it checks

Four questions, asked of every rule.

The last two are where detections fail without anyone noticing.

01Is it deployed?

Every rule is inventoried hourly, with its query hash and full change history.

02Is it running?

Alerting, monitoring, staged or switched off, and who set it that way.

03Does it still see data?

Each field and each branch of the query is checked against real events. A rule can be half dead and look healthy.

04Does it fire?

A safe simulated attack runs on a test host. The rule passes only if it matched. If the telemetry never arrived, the verdict is “inconclusive”, not “pass”.

Our own lab, answered honestlyCyberolog Lab

Cyberolog Lab is public and live: a filtered public view of the fleet's real record. It shows failed runs and untested rules as they are.

Caught, live

What it found, as it happened.

Straight from the fleet's own record. Every line is a real event on the lab SIEM; every rule name opens its receipt.

fleet_audit · Cyberolog Lab
Loading the record…
New rules rolling out

A new rule has to earn its place.

Rules can be onboarded from SigmaHQ, and other sources plug into the same intake. Each one passes the same checks as the rules you already run, before it is allowed to alert.

01
Does this environment have the data?

A rule that filters on a field your SIEM never fills is held back, not deployed blind.

02
Is it a duplicate, or too broad?

The draft is linted and compared with the rules already in place.

03
A person approves it

The rule is created parked, in a mode the SIEM does not run. Only a reviewer's approval starts it, in silent monitoring.

04
It is promoted on evidence

After a quiet period, healthy data and a passed attack test, it can move to alerting. Promotion is automatic only if you switch it on.

Evidence

Every rule has a receipt.

One record per rule: its mode and who set it, the data check for each branch, the attack test result, and every change since day one. A value that was never measured is shown as “not recorded”, never as zero.

For your auditor

DORA Article 10 requires detection mechanisms to be regularly tested. NIS2 asks you to assess whether your security measures are effective. A receipt per rule is that evidence.

For your customers

If you run SIEMs for others, each customer gets their own login and sees only their own rules. You can show what is proven, not only what is deployed.

Independent of your SIEM vendor

The same checks and the same receipt on every SIEM we connect. Live today on nano.rs and Splunk.

How it stays safe

It starts by only looking.

Automation is optional and comes later, one customer at a time, when you decide.

1
Read-only first

Inventory, data checks, quality review and noise findings need no write access.

2
One decider

If you turn automation on, a single governor is the only thing that can change a rule, under a mass-change cap and a stop switch.

3
Nothing is ever switched off

A noisy rule drops to silent monitoring, keeps watching, and is re-armed when it's quiet, or at once if triage suspects a real incident.

4
Every change has a receipt

Who, when, why, and the evidence behind it, in the rule's history. Open any rule on the live Pulse to read its receipt.

Start here

A 30-day read-only audit of your detection rules.

We connect with a read-only account and watch your rules for 30 days. At the end you will receive one report you can forward.

Ask for the audit [email protected]

What the report will contain
1Every rule, its mode and its change history
2Rules and branches that no longer see data, with the event counts
3Quality findings: duplicates, over-broad queries, fragile literals
4Noisy rules and what is driving the noise
5Optional: attack tests on a host you choose, to prove which rules fire