DEV Community: Nguyen Dong

Wazuh custom rule never fires, and analysisd -t still exits 0: the file name decides

Nguyen Dong — Sat, 26 Sep 2026 06:21:21 +0000

You write a child rule for a stock Wazuh rule, drop it into /var/ossec/etc/rules/, and run the config check. wazuh-analysisd -t exits 0. You restart the manager. The rule never fires, and wazuh-logtest shows the event landing on the parent instead.

One common cause has nothing to do with the rule itself. It is the name of the file you put it in.

What we measured

On a throwaway wazuh-manager:4.14.7 container we used one test rule, a child of the stock sshd rule 5715:

<group name="test,">
  <rule id="100080" level="9">
    <if_sid>5715</if_sid>
    <match>Accepted password</match>
    <description>test child of 5715</description>
  </rule>
</group>

5715 lives in /var/ossec/ruleset/rules/0095-sshd_rules.xml. We put the same rule in five differently named files in /var/ossec/etc/rules/, ran wazuh-analysisd -t, restarted, and sent one line through wazuh-logtest:

Sep 26 10:00:00 host1 sshd[1234]: Accepted password for root from 203.0.113.5 port 22 ssh2

file	7617 / 7619 warnings	logtest lands on
`0094-test.xml`	yes	`5715` (our rule ignored)
`0096-test.xml`	no	`100080` (fires)
`local_rules.xml`	no	`100080` (fires)
`0095-aaa.xml`	yes	`5715` (our rule ignored)
`0095-zzz.xml`	no	`100080` (fires)

The two warnings, word for word:

WARNING: (7617): Signature ID '5715' was not found and will be ignored in the 'if_sid' option of rule '100080'.
WARNING: (7619): Empty 'if_sid' value. Rule '100080' will be ignored.

What it means

Files in etc/rules are not loaded after the stock ruleset. They are merged with ruleset/rules and loaded in order of the full file name. The last two rows show it: 0095-aaa.xml sorts before 0095-sshd_rules.xml, so when our rule is read, 5715 does not exist yet and the rule is dropped. 0095-zzz.xml sorts after it, and the same rule fires.

local_rules.xml is safe for this reason: letters sort after digits, and all 168 stock rule files in 4.14.7 start with a digit (0010 to 0999), so it loads after every one of them.

The trap is the config check. wazuh-analysisd -t exits 0 in all five cases. It prints the two warnings, but a warning is not a failure, and nothing in a deploy script that checks the exit code will stop. The manager then starts cleanly with one rule fewer than you think.

Check yours in a minute

After a restart, the warnings are also in the manager log:

grep -E '\((7617|7619)\)' /var/ossec/logs/ossec.log

Every rule id you see in a 7619 line is a rule that is not running. The 7617 line on the same second tells you which parent it was waiting for.

Before a restart, run the check yourself and read its output instead of trusting the exit code:

/var/ossec/bin/wazuh-analysisd -t 2>&1 | grep -E '\((7617|7619)\)'

For a single rule, wazuh-logtest with a real sample line is the final word: if the output shows the parent's id and not yours, your rule did not load or did not match.

The fix

Move the child rule into a file whose name sorts after the file that holds its parent:

put it in local_rules.xml, or
give your file a prefix above the parent's file (0096-... or higher for children of sshd rules), or a name that starts with a letter.

To find the parent's file:

grep -l 'id="5715"' /var/ossec/ruleset/rules/*.xml /var/ossec/etc/rules/*.xml

Then run the check again and confirm the 7619 line is gone, and that logtest lands on your rule.

What we did not measure

One Wazuh version (4.14.7), a single manager, one parent rule, and only if_sid. We did not test if_matched_sid, if_group, decoders, or a cluster. If you run a cluster, check the warnings on every node.

Credit to Francisco Sousa, who found the file name half of this in his own container before we did.

If one of your rules loads and never fires and you would rather not dig into it yourself, send us the rule, your Wazuh version and a sample event: we find why, then write and test the fix on that version. USD 490 per rule case, paid only after it runs clean on your side. vct.atkvn.com/#fix-pack

Dong Nguyen, ATK New Technology

Wazuh ms-graph: why Entra ID sign-ins never reach the indexer, and a one-processor fix

Nguyen Dong — Sat, 26 Sep 2026 02:58:36 +0000

You enable the Wazuh ms-graph module for auditLogs/signIns. The module logs clean scans. With wazuh_modules.debug=2 it even logs Sending log: {"integration":"ms-graph", ... "relationship":"signIns"}. And yet there is not a single sign-in in wazuh-alerts-* or wazuh-archives-*.

There are two separate reasons, and on a stock install you hit both.

1. The stock ruleset has no rule for sign-ins

0995-microsoft-graph_rules.xml in 4.14.7 has 99 rules. The parent rule 99500 (level 0) catches every ms-graph event. Its children cover alerts, incidents, audit events, devices, apps and risk detections. None matches relationship: signIns.

So on the stock ruleset a sign-in stops at level 0 and never becomes an alert. It can only reach the indexer through the archives (<logall_json>yes</logall_json>). That is where the second problem waits.

2. The stock template rejects every sign-in

wazuh-template.json applies to both wazuh-alerts-4.x-* and wazuh-archives-4.x-*. It maps two ms-graph fields as keyword:

field	template	alerts_v2 / incidents send	signIns send
`data.ms-graph.status`	`keyword`	a string (`"resolved"`)	an object (`{errorCode, failureReason, additionalDetails}`)
`data.ms-graph.appliedConditionalAccessPolicies`	`keyword`	not sent	a list of objects

A keyword field cannot hold an object, so the indexer rejects the document:

mapper_parsing_exception: failed to parse field [data.ms-graph.status] of type [keyword] ...
caused_by: illegal_state_exception: Can't get text on a START_OBJECT

Three details that make this harder to see than it should be:

It does not depend on which event arrives first. "First shape wins" only holds for unmapped fields. These two are mapped explicitly, so every object-shaped sign-in is rejected, in any order, even if signIns is the only relationship you enabled. We checked the template at tags v4.8.0, v4.10.0, v4.12.0, v4.14.0, v4.14.3 and v4.14.7: the same in all six.
The error names only the first bad field. A sign-in with at least one Conditional Access policy fails on appliedConditionalAccessPolicies. One with an empty policy list fails on status. Fix status alone and the sign-ins that had a policy applied are still rejected.
Nothing on the manager says so. ossec.log is clean and archives.json has the event. The rejection happens inside the indexer, after Filebeat has shipped the event. One of the reporters found nothing in the Filebeat log either.

If the sign-in is missing from archives.json itself, you have a different problem, upstream of the indexer. Look at time_delay first: sign-in records show up in Graph with a delay, and a scan window that closes at "now" can miss them. Issue 39460 in wazuh/wazuh has both problems, one after the other.

Check yours in a minute

On the stock template timing does not matter, so the mapping tells you:

GET wazuh-archives-*,wazuh-alerts-*/_mapping/field/data.ms-graph.status,data.ms-graph.appliedConditionalAccessPolicies

If either field comes back "type": "keyword" and you have signIns enabled, every sign-in that reaches the indexer is rejected: through the archives, or through the alerts index once you add your own sign-in rule.

The fix: one `script` processor, by type

The idea is to leave the string status of alerts and incidents where it is, because dashboards and saved searches on data.ms-graph.status expect that string. Only the sign-in shapes move to new fields. The rules are not affected either way: they run on the manager, before the indexer.

status, when it is an object → data.ms-graph.signInStatus
appliedConditionalAccessPolicies, when it is a list of objects → data.ms-graph.conditionalAccessPolicies

It is one script processor (FIX in the script at the end), right after the json processor, in the alerts and the archives pipeline. Two details matter:

ignore_failure: true. The stock Wazuh pipelines end with on_failure: drop, so a processor that throws does not just skip its own step; the whole event is dropped. With ignore_failure, the worst case is an event indexed unchanged.
d.get('ms-graph'), not ctx.data?.ms-graph. Painless reads the hyphen as a minus sign, the dotted form does not compile, and the indexer refuses the whole pipeline.

The two new fields get a dynamic mapping on first use (signInStatus.errorCode becomes long, the text fields keyword). No template change is needed, and the fix works on today's index too; you do not wait for the next daily index.

The script at the end of this post does this for you, with a backup and a rollback:

export URL=https://<indexer>:9200 AUTH='<user>:<password>'
python3 msgraph_signins_fix.py verify     # 4 test events through your live pipelines
python3 msgraph_signins_fix.py apply      # saves both pipelines to ./backup, installs the processor
python3 msgraph_signins_fix.py verify     # expect 0 problems
python3 msgraph_signins_fix.py rollback   # restores ./backup

What we measured, and what we did not

Measured on a throwaway wazuh-indexer:4.14.7 with the stock template and both stock pipelines, taken from the wazuh-manager:4.14.7 image. We sent Graph v1.0-shaped sign-ins, with and without a Conditional Access policy, plus an alerts_v2 alert, the way Filebeat sends them:

stock: every sign-in rejected, in both pipelines and in both arrival orders; the alert indexes fine
status fixed alone: sign-ins that had a policy applied still rejected, now on the second field
the processor: every sign-in and the alert indexed, in both orders, in a fresh index and in an index that already existed; data.ms-graph.status stays keyword and still aggregates; events without data are untouched
the script: verify 4 errors → apply → verify 0 of 8 (including a non-ms-graph event) → a second apply skips → rollback restores both pipelines byte for byte → verify 4 errors again

Not measured: a real tenant, the Graph beta API (it adds sign-in fields we have not checked against the template), a real Filebeat in the path, and whether the patch survives a restart or upgrade. Two things to check on your side:

If your filebeat.yml sets filebeat.overwrite_pipelines: true, Filebeat reloads the pipeline from disk and the patch has to go into the pipeline file instead.
After a Wazuh upgrade, the pipeline id can change. Run verify again.

And to get sign-in alerts rather than archives only, you still need your own rule on ms-graph.relationship = signIns. The stock ruleset does not ship one.

Credit to the reporters of wazuh/wazuh issues 38330 and 39460: the first described the collision, the second narrowed the loss down to the indexer.

The script

Save it as msgraph_signins_fix.py. Standard library only; it changes nothing but the two pipelines, and verify writes only to indices dated 2099.01.01, then deletes them.

#!/usr/bin/env python3
# Wazuh ms-graph sign-in fix: verify | apply | rollback. ATK New Technology, vct.atkvn.com/#fix-pack
import base64, json, os, ssl, sys, urllib.error, urllib.request

URL, AUTH, BK = os.environ.get("URL", "").rstrip("/"), os.environ.get("AUTH", ""), "backup"
TAG = "ms-graph signIns fix"
SRC = ("def d = ctx.get('data'); if (!(d instanceof Map)) { return; } "
       "def g = d.get('ms-graph'); if (!(g instanceof Map)) { return; } "
       "if (g.get('status') instanceof Map) { g.put('signInStatus', g.remove('status')); } "
       "def p = g.get('appliedConditionalAccessPolicies'); "
       "if (p instanceof List && !p.isEmpty() && p.get(0) instanceof Map) "
       "{ g.put('conditionalAccessPolicies', g.remove('appliedConditionalAccessPolicies')); }")
FIX = {"script": {"lang": "painless", "source": SRC, "ignore_failure": True, "description": TAG}}


def es(method, path, body=None):
    req = urllib.request.Request(URL + path, method=method, headers={"Content-Type": "application/json"},
                                 data=None if body is None else json.dumps(body).encode())
    if AUTH:
        req.add_header("Authorization", "Basic " + base64.b64encode(AUTH.encode()).decode())
    try:  # stock Wazuh indexers use self-signed certificates
        with urllib.request.urlopen(req, context=ssl._create_unverified_context(), timeout=30) as r:
            return r.status, json.loads(r.read() or b"{}")
    except urllib.error.HTTPError as e:
        return e.code, json.loads(e.read() or b"{}")


def pipelines():
    code, allp = es("GET", "/_ingest/pipeline")
    if code != 200:
        sys.exit("cannot list pipelines: HTTP %s" % code)
    out = {}
    for kind in ("alerts", "archives"):
        ids = sorted(p for p in allp if p.startswith("filebeat-") and p.endswith("-wazuh-%s-pipeline" % kind))
        if not ids:
            sys.exit("no filebeat-*-wazuh-%s-pipeline found" % kind)
        out[kind] = (ids[-1], allp[ids[-1]])
    return out


def apply():
    os.makedirs(BK, exist_ok=True)
    for kind, (pid, body) in pipelines().items():
        procs = body["processors"]
        if any(TAG in str(p.get("script", {}).get("description", "")) for p in procs):
            print(kind, pid, "already patched")
            continue
        i = next((i for i, p in enumerate(procs) if "json" in p), None)
        if i is None:
            sys.exit("%s has no json processor" % pid)
        path = os.path.join(BK, pid + ".json")
        if not os.path.exists(path):
            json.dump(body, open(path, "w"))
        code, r = es("PUT", "/_ingest/pipeline/" + pid, dict(body, processors=procs[:i + 1] + [FIX] + procs[i + 1:]))
        print(kind, pid, "HTTP", code, "backup", path)
        if code != 200:
            sys.exit(json.dumps(r)[:300])


def rollback():
    for kind, (pid, _) in pipelines().items():
        path = os.path.join(BK, pid + ".json")
        if os.path.exists(path):
            print(kind, pid, "restored, HTTP", es("PUT", "/_ingest/pipeline/" + pid, json.load(open(path)))[0])
        else:
            print(kind, pid, "no backup, left as is")


def verify():  # writes only to indices dated 2099.01.01, then deletes them
    ms = lambda **m: {"integration": "ms-graph", "ms-graph": m}
    st = {"errorCode": 50126, "failureReason": "Invalid username or password."}
    pol = [{"id": "0", "displayName": "verify", "result": "notApplied"}]
    cases = [("other event", {"srcip": "203.0.113.7"}),
             ("alerts_v2, string status", ms(status="resolved", relationship="alerts_v2")),
             ("signIns + policies", ms(status=st, appliedConditionalAccessPolicies=pol, relationship="signIns")),
             ("signIns, no policies", ms(status=st, appliedConditionalAccessPolicies=[], relationship="signIns"))]
    bad = 0
    for kind, (pid, _) in pipelines().items():
        pre = "wazuh-%s-4.x-" % kind
        for name, data in cases:
            a = {"timestamp": "2099-01-01T00:00:00.000+0000", "rule": {"id": "99500", "level": 0}, "data": data}
            code, r = es("POST", "/%sverify/_doc?pipeline=%s&refresh=true" % (pre, pid),
                         {"message": json.dumps(a), "fields": {"index_prefix": pre}})
            ok = r.get("result") == "created" and r.get("_index", "").endswith("2099.01.01")
            err = r.get("error")
            bad += not ok
            print("%-8s %-26s %s" % (kind, name, "OK" if ok else "ERROR %s" % (
                err.get("reason") if isinstance(err, dict) else r)[:160]))
        es("DELETE", "/%s2099.01.01" % pre)
    print(bad, "problem(s)")
    sys.exit(1 if bad else 0)


if __name__ == "__main__":
    cmd = sys.argv[1] if len(sys.argv) > 1 else ""
    if not URL or cmd not in ("verify", "apply", "rollback"):
        sys.exit("usage: URL=https://<indexer>:9200 AUTH='<user>:<password>' %s verify|apply|rollback" % sys.argv[0])
    globals()[cmd]()

If you would rather not patch this yourself, we write and test the fix for your exact Wazuh version and send you the files: USD 490, paid only after it runs clean on your side. vct.atkvn.com/#fix-pack

Dong Nguyen, ATK New Technology

One field path, two shapes: how Wazuh alerts get dropped with a 400 nobody sees

Nguyen Dong — Thu, 24 Sep 2026 11:12:36 +0000

In the last 24 hours, two people running Wazuh 4.14.7 in production hit the same defect from different directions, and neither of them saw it on a dashboard. They found it by going looking in a log.

The defect is simple to state. The alerts index template gives each field path one type. Some integrations send more than one shape of data under the same path. When an event arrives in the shape the template did not expect, the indexer rejects that document with mapper_parsing_exception, Filebeat gets a 400 back, and a 400 is not the kind of error a shipper retries. The event is gone. Nothing alerts on it, because the thing that would alert is the thing that never got stored.

Three paths so far. data.ms-graph.status is mapped as keyword, and some Microsoft Graph events send an object there. data.office365.ModifiedProperties is also keyword, and some Office 365 events send an object; one operator counted 35 of those in a single Filebeat log. The third runs the other way: an override that mapped data.data as an object then met events that send the string "[]" in the same place.

The useful part is that this is one class of bug, not three. Any path that can carry two shapes will drop the minority shape silently, so the audit is a count of failures by field name, not a hunt for a specific field:

grep -o 'failed to parse field \[[^]]*\]' /var/log/filebeat/filebeat* | sort | uniq -c | sort -rn

An empty result is only meaningful if Filebeat logs at a level that records the rejection, so check that one known-bad event shows up before trusting a zero.

On the fix, put the override in a template of its own with a higher order instead of editing the wazuh template, which the documented upgrade procedure reinstalls. On 4.14.7 two legacy templates with the same pattern merge and the higher order wins the field; that part I measured. Remember a template only applies when an index is created, so today's index keeps the old mapping and keeps dropping until tomorrow's index exists. And before you flip a path from keyword to object, run an exists query on it: every hit is an event that indexed fine as a string, and flipping the type moves the 400s onto those. If both shapes are real, enabled: false accepts both (one of the two operators measured this on status), at the price of not being able to query inside that field.

If you run the grep and get a path that is not on this list, I'd like to hear which one.

All 4052 if_sid anchors in the Wazuh ruleset resolve, so that's not why your rule is silent

Nguyen Dong — Wed, 23 Sep 2026 03:43:48 +0000

I kept seeing the same guess from Wazuh users: my rule never fires, so the shipped ruleset must be broken. That's checkable, so I checked it instead of guessing.

At commit 3bf1912 (measured 23 Sep 2026) the shipped ruleset is 166 files and 4420 rules.

Every if_sid anchor resolves to a rule that exists: 4052 of 4052. Every if_matched_sid: 205 of 205. Every if_group: 129 of 129. No dangling parents anywhere.

That zero is only worth reading because the detector was checked in both directions. A SID that can't exist (99999999) is reported as dangling, and SIDs that do ship (1002, 5701) are reported as defined. XML comments are stripped before parsing; three rule definitions live inside comments and would otherwise have been counted as real.

The number that does explain silence is different: 635 of 4420 rules, 14.4 percent, carry level="0". They never alert by design, they exist to be matched on. A chain that terminates on one of them is silent and correct at the same time.

So when a rule doesn't fire, the shipped anchors aren't where the fault is. Your own local rules, your ordering, and the level 0 parents in the chain are.

Limits worth stating. This is ruleset/rules/*.xml at one commit and nothing else. It doesn't cover decoders, custom rules, or whether a rule that resolves is one that matches your logs. It proves the anchors are reachable, and it doesn't prove the detection is right.

Re-run it against any commit:

const defined = new Set(), refs = [];
for (const p of ruleFiles) {
  const src = fetchText(p).replace(/<!--[\s\S]*?-->/g, '');
  const re = /<rule\b[^>]*\bid\s*=\s*["'](\d+)["'][^>]*>([\s\S]*?)<\/rule>/g;
  let m;
  while ((m = re.exec(src)) !== null) {
    defined.add(m[1]);
    let k; const ifRe = /<if_sid>([\s\S]*?)<\/if_sid>/g;
    while ((k = ifRe.exec(m[2])) !== null)
      k[1].split(',').map(s => s.trim()).filter(Boolean).forEach(t => refs.push(t));
  }
}
refs.filter(r => !defined.has(r));

Sixteen detection vendors, one TLS check, and nobody is near the 47-day floor

Nguyen Dong — Mon, 21 Sep 2026 06:07:38 +0000

On 2026-09-21 I opened the public front door of sixteen detection and SOC vendors, one browser session per host, and kept two things from the TLS handshake: the negotiated key exchange group, and the certificate validFrom and validTo pair. The question was narrow. Not "is this vendor secure". Only this: what lifetime does the certificate on their own hostname actually carry, now that the CA/Browser Forum schedule has started to bite?

Issued lifetime below is validTo minus validFrom, in days.

host	issued lifetime	key exchange group
elastic.co	397	X25519MLKEM768
expel.com	396	P-256, X25519, X25519MLKEM768
arcticwolf.com	376	X25519MLKEM768
splunk.com	364	X25519MLKEM768
crowdstrike.com	198	X25519MLKEM768
wazuh.com	197	X25519MLKEM768
rapid7.com	197	X25519MLKEM768
blumira.com	90	X25519MLKEM768
exabeam.com	90	X25519MLKEM768
graylog.org	90	X25519MLKEM768
huntress.com	90	X25519MLKEM768
redcanary.com	90	X25519, X25519MLKEM768
securityonionsolutions.com	90	X25519MLKEM768
sentinelone.com	90	X25519MLKEM768
sophos.com	90	X25519MLKEM768
todyl.com	90	X25519MLKEM768

Three clusters, and nothing between them. Nine hosts sit at exactly 90 days. Three sit at 197 to 198. Four sit at 364 to 397. There is no host at 120 days, none at 150, none at 250. This population isn't a spread. It is three points.

The number that made me write this down: zero of sixteen is at or under 47 days.

The CA/Browser Forum schedule caps issuance at 200 days from 2026-03-15, at 100 days from 2027-03-15, and at 47 days from 2029-03-15. Seven of these sixteen currently carry a certificate longer than 100 days, so seven renewal processes have to change shape before March 2027. All sixteen have to change again before March 2029.

The set reconstructs that schedule without being asked to. Every certificate here issued before 2026-03-15 runs 364 to 397 days. Every certificate issued after it runs 90 to 198 days. Sixteen out of sixteen, no exception. I didn't select for that. It fell out of the dates.

Two hosts served more than one key exchange group inside a single page load. On redcanary.com some responses came back classical X25519 while others came back hybrid. On expel.com three groups appeared at once, including P-256 over TLS 1.2. A single label per hostname hides that, so the table prints every group observed.

Controls, because a measurement without one is a story

Three of them, same sitting, same tool, and two are hosts anyone can hit.

Direction on group and protocol: sha256.badssl.com returned P-256 over TLS 1.2. Nothing collapses into a single hybrid label and nothing is forced into a TLS 1.3 bucket.

Fail closed: expired.badssl.com returned zero matching responses and therefore zero rows. A host whose certificate the browser rejects produces an absence, never an invented date. That matters more than it sounds, because it means a missing row in the table above would read as missing rather than as a clean result.

Discrimination inside the set: two of the sixteen came back with classical and hybrid groups on different responses of the same page load. The tool splits them apart on live data, not only on a rigged host.

What this doesn't measure

The marketing hostname only. Not the product plane, not the customer portal, not the API endpoint.

One client, one vantage point, one day. No repeat run, no second observer.

Several of these hosts sit behind a CDN. For those, the certificate describes the automation of whoever operates that CDN, not the engineering practice of the vendor. The issuers observed across the set were a mix of large cloud and CDN certificate authorities plus two commercial ones, which is roughly the shape you would predict from the 90-day cluster.

The sample is sixteen names chosen by hand. It isn't random and it isn't the whole market. One host redirected to a different hostname and was measured at the destination it landed on. Another redirected as well and was dropped instead of being silently attributed.

Lifetime is read from what the browser reports for the certificate it actually received. Certificate Transparency logs were not pulled.

How to run it yourself

Any TLS client that reports both the negotiated group and the certificate dates will do. The browser developer tools print both under Security. A scripted version attaches a Network.responseReceived listener over the debugging protocol, keeps only the responses whose hostname matches the host under test, and prints the matched count next to the total response count on every row, so that an empty result is visibly empty rather than quietly missing.

If you run the same check across your own vendor list, post the counts in the three buckets. I want to know whether the three cluster shape holds outside these sixteen names, or whether it's an artifact of picking well known ones.

Two coverage zeros, two different causes

Nguyen Dong — Thu, 17 Sep 2026 11:18:21 +0000

On 16 September 2026 we wrote detection rules for two classes our bench had never
covered, industrial control (OT) and Kubernetes, and loaded them onto our own
Wazuh rig. Both classes had measured zero before. Loading the rules told us
something the coverage count never could: the two zeros do not have the same
cause, and only one of them is fixable by writing rules.

The zeros themselves were measured and published before any of these rules existed: ot-k8s-rule-layer-2026-09-15.md.

What we ran

Rig: a stock Wazuh manager, v4.14.7 (revision rc1), with the shipped ruleset.
Two agents, both v4.14.7: one Linux host running a PLC runtime, one running k3s.
We wrote our own rules in a separate file and did not modify a byte of the stock
ruleset. wazuh-analysisd -t exits 0; the rules load.

The Kubernetes zero

We tagged a rule with T1611 (Escape to Host, from the ATT&CK Containers matrix).
The tool accepted it and echoed mitre.id: ['T1611']. No warning.

We replayed a real event against it (a pod requesting privileged, hostPID and
hostNetwork) and the alert came back at the level we assigned.

So the Containers technique exists in the platform's technique database. Nothing in
the platform was missing. What was missing was a rule, and a rule is something you
can hire someone to write.

The OT zero

We tagged a rule with T0886 (Remote Services, from the ATT&CK ICS matrix). The
same tool, in the same run, printed:

** Wazuh-Logtest: WARNING: Mitre Technique ID 'T0886' not found in database.

The rule still loads, and replaying a matching log line through the tool produces the
alert. But the technique it claims to cover is not a technique the platform knows
about. You can write the rule; you cannot make the
platform carry the tag.

That is a different kind of zero. Writing rules does not close it.

Why we are reporting the control, not just the finding

A tool that prints "not found in database" for every identifier you hand it would
produce exactly the output above, and would mean nothing. The T1611 result is the
control: same tool, same run, same rule file, with one identifier accepted silently
and one rejected with a warning. Without that pair, the warning is not evidence.

We also counted what the stock ruleset does carry: 97 distinct T1xxx identifiers
across 168 rule files. The ruleset is not untagged. It is tagged, thoroughly, in a
matrix that does not include ICS.

What this does not say

Both results above were produced by wazuh-logtest, replaying a log line through the
rule engine. They are not measurements of a live event stream. On this rig the OT
source had stopped emitting entirely by the time the rules were loaded, so the OT
rule has produced no alert from live traffic at all: a separate problem, and one a
rule cannot fix.

This is one rig, one version, one revision: 4.14.7 rc1, not a GA build. We have
not tested another SIEM, and we have not checked whether a later release ships the
ICS matrix. We are not saying the product does not support OT; we are saying that on
this build, an ICS technique identifier is not in the technique database, and that
this is a different problem from an empty ruleset even though both show up as a zero
on a coverage chart.

We also found stock rules that mention Kubernetes: 61 of them, in the AWS Security
Hub file, covering EKS. Their groups are compliance groups (CIS, PCI DSS, and an
800-53 control set). Across all 61 rules we count 7 MITRE blocks and 6 distinct technique
identifiers, none of them from the Containers matrix. We mention this because a reader checking our claim
will find those 61 rules in about thirty seconds, and we would rather name them than
have them look like something we missed.

The question worth asking your own stack

If you run a stock install against OT or Kubernetes log sources, the useful number
is not how many rules you have. It is: when your coverage says zero, which of the
two zeros is it? One of them a rule author can close. The other one cannot.

If you have run this and got a different result, particularly on a GA build, the
identifier and the tool output would be useful to us. Send it: open an issue or email dongnx.biz@gmail.com.

I scanned 37 security job posts tonight. Zero were posted in the last 24 hours.

Nguyen Dong — Wed, 09 Sep 2026 00:01:27 +0000

I measure whether security monitoring actually fires. Tonight I checked something I had been assuming instead of measuring: how fast does the security slice of one large freelance marketplace actually produce work?

Method: five one-word anchors (wazuh, splunk, siem, qradar, "soc 2"), sorted by recency, no time filter, page one, read at 2026-09-08 23:57Z.

Result: 37 cards. That is 33 unique jobs, because four cards were the same posting showing up under two or three anchors. Zero posted in the last 24 hours. The youngest card in the whole slice was a day old.

Two things there are worth more than the zero.

First, my own age parser lied to me. Five of the 37 cards came back with an unreadable age, and I nearly wrote that down as the platform being quiet. It wasn't. The parser matched the string "Posted last week" and returned null, because it only converted "yesterday" into a number. The platform stated the age; my ruler couldn't read it. One of those five sat at position zero of a recency-sorted list, which is exactly where a fresh post would sit, so that zero was one bad string away from being wrong. An unmeasurable cell doesn't prove the thing you measured is silent. Sometimes it's accusing your ruler.

Second, the only anchor that returned buyers with money wasn't a product name. "soc 2" gave 6 of 10 cards with payment verified and at least 1K spent, one of them past 300K. The four product-name anchors together gave 8 of 27. That's one slice on one night, so it's a hypothesis and not a finding. But it points somewhere I didn't expect: the people spending money here type the name of the paperwork they owe, not the name of the tool they run.

If you sell detection or SOC work on a marketplace like this, I'd like to know whether your own counts say the same thing, or whether my five anchors are just the wrong five.

Your SIEM has never been asked a question it could fail

Nguyen Dong — Mon, 07 Sep 2026 05:21:20 +0000

You run your own SIEM instead of buying a managed service because the maths worked. Licences, one engineer, a screen that stays green. That saving is real and it shows up on your P&L every month.

The exposure sits on a line nobody prints. What you are paying for is detection. What the console actually proves is ingestion. Those are two different facts, and during a real incident the first one keeps looking healthy while the second one is the only one that matters.

Here is the measurement I have. Default Wazuh build, stock rules, nothing tuned. I replayed 24 ATT&CK techniques against it (measured 01/09/2026). Three raised an alert. Discovery, collection, exfiltration and command-and-control produced nothing at all.

It is my own number and not an independent benchmark, and it carries a correction I published against myself: four of the 21 silent rows turned out to be measuring my observation window rather than the rule. Those four are marked in the data. A number that moves after someone checks it should show who moved it and why, otherwise you are being asked to trust a person instead of to read a measurement.

Raw data, host set and reproduction steps: https://github.com/xuxu298/siem-replay-24-techniques/

Run it against your own build rather than believing mine. What comes back is a number about your estate, which is the only version of this with any value to you.

The thing I do not know: for those of you running a self-hosted SIEM with no dedicated detection engineer, when someone above you asks whether you would actually see an intrusion, what do you put in front of them today?

A rule that is present, enabled, and silent: what Wazuh 92900 shows about coverage reports

Nguyen Dong — Sun, 06 Sep 2026 13:17:57 +0000

Wazuh rule 92900 is meant to catch LSASS credential dumping. It matches on an enumerated list of GrantedAccess masks: 0x1010 and 0x40.

Run the classic living-off-the-land dump:

rundll32.exe C:\windows\system32\comsvcs.dll, MiniDump <lsass pid> <path> full

Sysmon Event ID 10 fires with GrantedAccess 0x1fffff. That value is not on the list, so 92900 produces nothing. The dump succeeds. The rule is still present, still enabled, and still counts as covered in any report that counts rules.

That is the part worth sitting with. An enumerated-list rule does not fail loudly. It fails silent, and the silence is indistinguishable from "nothing happened."

The discriminator, and why the obvious one is the wrong one

Widening the mask list does not fix it: the Wazuh agent itself opens LSASS, so 0x1fffff on its own is benign traffic. The thing that separates the malicious open from the benign one is CallTrace.

The obvious key is comsvcs.dll, since that is what the command loads. It is the wrong key. comsvcs' MiniDumpW hands off to MiniDumpWriteDump, which lives in dbgcore.dll. Key on dbgcore instead and you catch the same comsvcs dump plus every dumper that reaches MiniDumpWriteDump by another path.

This is not a guess. In the public thread the reporter tested both against a live endpoint: dbgcore.dll appears in the CallTrace for the comsvcs dump, and also for ProcDump. comsvcs does not appear in ProcDump's CallTrace at all. A comsvcs-only rule would have missed ProcDump entirely.

The cost is real and should be stated: dbgcore and dbghelp also turn up in benign crash-handling traces, so this trades a silent miss for noise you have to tune.

The general shape

Two things travel together here, and only one of them is about Wazuh.

A rule written as a list of known-bad values answers "is this value on my list?", not "did this technique happen?". Any value off the list is silence. The rule is intact, the report is green, and the technique lands.

So the check that matters is not "is the rule there?" but "does it fire when I run the thing?" — and then run a second tool down the same code path before calling the gap closed. Here, one tool would have produced a rule that looked fixed and still missed the more common dumper.

The full test output is in the upstream tracker, in the wazuh/wazuh issue numbered 38716. I am not linking it directly here, but the number is exact and the thread is public, so you can check every claim above against what the reporter actually ran.

We replayed 24 ATT&CK techniques against a default Wazuh install. Three raised an alert.

Nguyen Dong — Thu, 03 Sep 2026 09:52:19 +0000

Not three percent. Three techniques.

The four chains you would most want to catch — discovery, collection, exfiltration, C2 — produced
zero alerts between them.

I want to be precise about what that number is and is not, because the number is easy to
misread in both directions.

What it is

A default install. Stock rules, no Sysmon, no ScriptBlock logging, no tuning. We replayed 24
techniques and counted how many produced an alert a human would see. Denominator: 24. Numerator: 3.

What it is not

It is not a claim that Wazuh is a bad SIEM. It is a claim that a default SIEM is close to
blind, and that most of the detection you think you bought is configuration you have not done yet.

The same technique, three SIEMs

T1110.001 (brute force) is the one technique we have run end-to-end on all three platforms.

SIEM	Setup	Result	MTTD
Wazuh 4.14.2	SSH brute force, 20+ failed logins, custom rule `100113`	ALERTED ×2, coverage 100%	25s / 45s
IBM QRadar CE 7.3.3	hydra, 50 SSH login attempts against a live victim host	ALERTED	~4s
Splunk Enterprise	`winsrv01`, 12× EventCode 4625 — events replayed into Splunk, not generated by a live attack	ALERTED	0s

Read the third row differently from the first two. Wazuh and QRadar were measured against a real
attack on a real host: hydra and a live SSH brute force, with the alert coming back out of the
platform. The Splunk row is a real Splunk Enterprise, a real detection-as-code rule, and a real
query — but the 4625 events were replayed in rather than produced by an attack we ran. That makes
it a valid test of the connector and the rule. It is not a test of Splunk's ingest path, and we are
not going to let it read as one.

🔴 Do not read this table as a race either. The three numbers are not comparable and we are not
going to pretend they are. Splunk's 0s is not Splunk being six times faster than QRadar — it is
Windows 4625 events already sitting in the index before the clock started, while the Wazuh figure
includes agent-to-manager-to-indexer propagation on a technique we had to write a rule for.
Different telemetry, different clocks, different work. Published anyway, with the caveats attached,
because a table with an honest asterisk is worth more than three separate write-ups with none.

The MISSED row is the one we care about most. Alongside winsrv01, we ran cleanhost — a host
with no events at all — and the connector correctly returned MISSED. A benchmark where nothing
can fail is not a benchmark. That negative control is what makes the other rows mean anything. A
third host, dbsrv02, carried events timestamped 4s late and returned MTTD 4s, so the clock is
measuring something real rather than returning zero by construction.

Two more findings from the same lab — and two things withheld

Real ransomware encrypting real files → caught by Wazuh file integrity monitoring in real-time mode. Two things are withheld here on purpose: the detection time, because the figure in our internal notes does not appear in any published report we can point you at, and the rule id, on the same ground.
SSH brute force → alert and an actual firewall drop that reached the host and stayed there. The rule ids for that one are withheld on the same ground.

We had both sets of ids written down and we have taken them back out. An id you cannot trace to a
source file is a claim nobody can check, which is worse than no id at all.

Dates, because they matter

These are lab measurements taken in June 2026, not last week. The Wazuh lab run is 15 June, the
Splunk connector proof 26 June, the QRadar proof 29 June. Nothing here has been re-run since. If
any of these platforms has changed its default rule set in the meantime, our numbers are stale and
we would like to know.

Why we can publish this and a vendor cannot

Every SIEM vendor can measure their own product. None of them can publish a table where their
product is one row among three, because the row that looks worst is the one paying for the
marketing team. We sell neither Wazuh, QRadar, nor Splunk. That is the entire reason this table
exists.

We will also tell you what we have not measured. We have not run this against Sentinel or
Elastic on live systems. We have no third-party audit of any of it — every number above is our own
measurement of our own lab, and you should discount it accordingly until someone outside our
company reproduces one.

Run it yourself

The detection library behind this is 71 scenarios, 84 Sigma rules, 84 techniques, with zero gap
between scenarios and rules, plus 6 named threat-actor campaigns. Rules translate to Splunk SPL,
Sentinel KQL, Elastic and Wazuh from the same detection-as-code source.

If you run any of those SIEMs and want your own number instead of ours, say so — we would rather
argue with your data than with our own.

Corrections wanted. If you think the 3/24 is wrong, tell us which technique should have fired
and on what rule. We will re-run it and publish the correction with the same prominence as the
original claim.

In April, banking was the least post-quantum-ready sector we measured. It is now second from the top.

Nguyen Dong — Thu, 03 Sep 2026 08:26:38 +0000

Global PQ Readiness Index — September 2026

Probe date: 2026-09-03 UTC · Previous runs: 2026-05-10 and 2026-04-23 UTC
Method: active TLS 1.3 ClientHello probe for NIST-track hybrid key agreement
(codepoints 0x11EC X25519MLKEM768 and 0x11EB SecP256r1MLKEM768)
Scope: 350 public hosts, 8 sectors, 28 region tags — same list all three runs, unchanged
Published alongside: aggregate counts per sector and per run, plus the probe method in full.
Not in this report: per-host results. Earlier runs of this index did publish host-level data,
and those files are still in this repository — see "Why we are not publishing the host list" below.

In April, banking was the least post-quantum-ready sector we measured. It is now second from the top.

Four and a half months ago we probed 350 public TLS endpoints and found that banking sat at the
bottom of eight sectors. We re-ran it in May, and again this week — identical probe, identical host
list, all three times.

Banking moved from 28% to 94%.

That is not a typo, and it is the largest sector move in the dataset. It is still not the highest
figure in the table: news & media finished at 96.4%. Banking travelled the furthest, not the
highest, and those are two different claims.

The number we trust, and why

The headline comparison people will want is 42.6% → 73.1% across all 350 targets. We are not
going to lead with that number, because the set of hosts that answered changed between runs and
a shifting denominator can manufacture a trend out of nothing.

Instead: 293 of 350 hosts returned a usable answer in both runs. That fixed cohort is the
only honest basis for a delta, so every number below is computed on it.

Run	Cohort PQ-safe	Banking
23 Apr 2026	147 / 293 = 50.2%	14 / 50 = 28.0%
10 May 2026	150 / 293 = 51.2%	15 / 50 = 30.0%
3 Sep 2026	252 / 293 = 86.0%	47 / 50 = 94.0%

The shape matters more than the endpoints. In the 17 days from April to May, the cohort moved
+1.0 point. In the 116 days from May to September it moved +34.8. This was not a gradual
drift; something changed over the northern summer. We do not know what, and we are not going to
guess in a document like this.

105 hosts moved from classical to post-quantum hybrid. Across all three runs, zero moved the other way.

That zero is the control. A measurement where nothing can move backwards is not measuring
anything; here something could have regressed, and nothing did. The shift is directional, not
noise.

By sector, same-host cohort

Sector	n	April	September	change
Banking	50	28.0%	94.0%	+66.0
Government	36	36.1%	86.1%	+50.0
E-commerce	33	30.3%	78.8%	+48.5
Critical infrastructure	30	43.3%	80.0%	+36.7
News & media	28	60.7%	96.4%	+35.7
CDN & cloud	34	64.7%	85.3%	+20.6
Control group (known PQ-shipping)	23	69.6%	87.0%	+17.4
Big-tech SaaS	59	71.2%	81.4%	+10.2

The sectors everyone assumes are slowest — banking, government — moved fastest. The sector
everyone assumes is fastest — big-tech SaaS — moved least, because it had the least room left
to move.

We are not naming hosts. Sector, region, denominator and delta are the whole product here.
A named list would be a different thing with a different purpose, and this is not that.

Why we are not publishing the host list

Earlier runs of this index named individual hosts. This one does not, and neither will the ones
after it. Those earlier files are still in this repository. We are not going to quietly delete
them and imply the policy was always this one — and deleting them would not unpublish them anyway.

A sector percentage with a stated denominator answers the question people actually have — is my
industry moving? A named list answers a different question, one that turns a measurement into a
scoreboard about specific organisations who did not ask to be on it. We would rather publish
something narrower and be able to keep publishing it.

The method is stated in full and the aggregate counts are attached. Anyone who wants to check us
can assemble their own list and run the same probe — that is a better reproducibility guarantee
than taking ours on trust.

Three things this does not prove

We measured a front door, not an estate. One public TLS endpoint per host. A bank whose www hostname negotiates ML-KEM may still run classical crypto everywhere that matters — internal PKI, batch file transfer, VPN, database links, HSM integrations. Front-door PQ is the cheapest possible indicator, and cheap indicators move first.
We cannot separate deliberate migration from vendor default. A large share of this shift is almost certainly CDN and load-balancer defaults rolling forward underneath organisations that made no decision at all. That is still real protection against harvest-now-decrypt-later, but it is not evidence of a migration programme, and it can be rolled back by a config change nobody announces.
57 hosts are missing from the cohort. 46 errored in September, 55 in April. The most common failure is a server alert rejecting our ClientHello outright. We count those as not measured, never as classical. If a systematic bias hides in there, it is the weakest part of this dataset, and it is the first place we would look for a correction.

Corrections wanted

The method and the per-sector aggregate counts for all three runs are published here. If you can
show that a sector figure is wrong, that the cohort method hides an artefact, or that the 0x11EB
codepoint should be counted differently, tell us and we will re-run and publish the correction with
the same prominence as the original claim.

We will run this again in December on the same list. The delta is the point; a single snapshot of
this is close to worthless.

HIDS + NIDS: Why Your SMB Needs Both (And How We Integrated Wazuh + Suricata in a Single Platform)

Nguyen Dong — Tue, 10 Mar 2026 12:09:42 +0000

Most SMBs think they're "covered" with just antivirus. Here's why that's like locking the front door but leaving every window wide open.

The Blind Spot in SMB Security

I've talked to dozens of SMB owners about their security setup. The conversation usually goes like this:

Me: "What security monitoring do you have?"
Them: "We have antivirus on every computer."
Me: "What about network traffic? Can you see what's going in and out?"
Them: ...silence...

This is the blind spot. Antivirus checks what's ON your computers. But nobody checks what's FLOWING THROUGH your network. A hacker stealing data over DNS tunneling, a compromised device beaconing to a C2 server, lateral movement between machines — antivirus won't catch any of it.

You need two types of monitoring. And no, you don't need a $200K/year SIEM to get them.

HIDS vs. NIDS: A 60-Second Primer

	HIDS (Host-based IDS)	NIDS (Network-based IDS)
What it watches	Individual devices (endpoints)	Network traffic flow
Detects	File changes, process anomalies, login attempts, malware	Port scans, intrusion attempts, data exfiltration, C2 beaconing
Tool	Wazuh Agent	Suricata IDS
Where it runs	On each endpoint	On a network sensor or device
Analogy	Security camera inside each room	Guard at the building entrance

HIDS tells you what happened on a machine. NIDS tells you what's happening on the wire.

You need both. Here's a real example:

A Wazuh alert says "3 failed SSH logins from 182.23.XX.XX". That's HIDS.
Suricata simultaneously sees "182.23.XX.XX is port-scanning 47 services on your network". That's NIDS.

Combined? You know it's not a typo — it's an active attacker probing your infrastructure. Block them instantly.

What We Built: Wazuh + Suricata → ClickHouse → AI

In VRadar, we integrated both HIDS and NIDS into a single pipeline. Here's how the data flows:

                    HIDS Pipeline
Windows/Linux/Mac ──→ Wazuh Agent ──→ Wazuh Manager
                                            │
                                            ▼ webhook
                                      VRadar Backend ──→ ClickHouse
                                            │              (security_logs)
                                            ▼
                                      AI Operator ──→ Triage + Auto-Response

                    NIDS Pipeline  
Network Traffic ──→ Suricata IDS ──→ eve.json
                                        │
                                  Wazuh Agent (monitors eve.json)
                                        │
                                  Wazuh Manager ──→ Custom Rules 100100-100104
                                        │
                                        ▼ webhook
                                  VRadar Backend ──→ ClickHouse
                                                     (nta_events)

Both pipelines converge into the same backend. One dashboard. One AI engine analyzing everything.

The Technical Integration (For the Engineers)

Getting Suricata to talk to Wazuh cleanly wasn't trivial. Here are the challenges we solved:

1. Interface Detection on Windows

Suricata crashes if you pass it a friendly interface name like "Wi-Fi" or "Ethernet". It needs the NPF device path: \Device\NPF_{GUID}. Our installation script auto-detects this:

# Convert friendly name → NPF device path (Suricata requirement)
$adapter = Get-NetAdapter | Where-Object { $_.Status -eq 'Up' -and $_.InterfaceDescription -notmatch 'Loopback|Virtual|Hyper-V' } | Select-Object -First 1
$npcapDevice = "\\Device\\NPF_$($adapter.InterfaceGuid)"

2. Rule File Auto-Detection

Suricata ships different rule files depending on version. Our script scans the actual rules/ directory and rewrites suricata.yaml to match:

$rules = Get-ChildItem "$env:ProgramFiles\Suricata\rules" -Filter "*.rules" |
    Where-Object { $_.Name -notmatch 'dnp3|modbus|ipsec' }  # Exclude ICS rules

3. JSON Decoder Limit

Suricata's eve.json events are large (800+ bytes). Wazuh's default JSON decoder limit (256) truncates them:

analysisd.decoder_order_size=1024  # Increased from 256

4. Custom Wazuh Rules for Suricata

Suricata alerts come through Wazuh's rule 86600 at level 0 (ignored by default). We created custom rules 100100-100104 to elevate them:

<rule id="100100" level="3">
  <if_sid>86600</if_sid>
  <field name="event_type">^flow$</field>
  <description>Suricata: Network flow event</description>
</rule>

5. One-Click Installation

The biggest challenge: making all of this install with one command. Our agent script handles 6 steps automatically:

Clean up any existing Wazuh/Suricata installation
Register with Wazuh Manager
Install Wazuh Agent (version-matched to Manager)
Configure HIDS monitoring
Install Npcap + Suricata IDS
Wire Suricata → Wazuh → VRadar pipeline

Works on Windows, Linux, and macOS.

What You See in the Dashboard

Once both HIDS and NIDS are running, the VRadar dashboard shows:

HIDS Tab (System Alerts)

Security alerts from Wazuh (3,000+ detection rules)
Alert severity distribution (Critical/High/Medium/Low)
AI-powered triage decisions with confidence scores
One-click IP blocking via Wazuh Active Response

NIDS Tab (Network Monitoring)

Suricata IDS events (flow, DNS, HTTP, TLS)
Severity breakdown over 7 days
Protocol distribution and traffic patterns
Source/destination IP analysis with geolocation

Threat Map

Real-time world map showing attacks hitting your network
SVG-based Mercator projection with animated attack lines
Data from both HIDS (login attempts, malware) and NIDS (port scans, intrusion attempts)

Security Score

9-factor scoring including both HIDS and NIDS health
NIDS Monitoring is one of the 9 scoring factors (10% weight)
Getting both working pushes your score above 80 (Grade B → A territory)

The Cost Argument

Here's what dual HIDS + NIDS monitoring costs at scale:

Vendor	HIDS + NIDS	Monthly Cost (50 devices)
Arctic Wolf	Managed SOC	$3,500+
Blumira	SIEM + IDS	$850+
SentinelOne + Darktrace	EDR + NDR	$2,500+
VRadar	Wazuh + Suricata + AI	$1,250

We can offer this pricing because:

Wazuh and Suricata are open-source — $0 licensing
AI triage via GPT-4o-mini — $0.15/1M tokens (we spend ~$2-5/tenant/month)
ClickHouse for log storage — handles millions of events on a single server
Solo operation — no sales team, no marketing department (yet)

Lessons for Other Builders

If you're building security tooling for SMBs:

Don't make users choose between HIDS and NIDS. They need both. Bundle them.
Auto-install everything. If setup takes more than one command, adoption drops to near zero.
AI triage is table stakes now. GPT-4o-mini costs almost nothing. Use it to reduce alert fatigue.
Suricata on Windows is possible but painful. Budget extra time for NPF device paths, rule-file compatibility, and threshold configs.
Log everything to a columnar DB. ClickHouse handles millions of events for $0 and queries complete in milliseconds.

Try It

VRadar is live at vradar.io — plans start at $25/device/month for dual HIDS + NIDS monitoring with AI-powered threat analysis.

If you're running an SMB with no security monitoring (or just antivirus), you're exactly who we built this for.

I'm Dong, a solo developer from Vietnam building affordable security tools. If you have questions about integrating Wazuh + Suricata or building security products for the SMB market — ask me anything in the comments.

Tags: #cybersecurity #wazuh #suricata #HIDS #NIDS #ai #SOC #startup #opensource #buildinpublic

DEV Community: Nguyen Dong

Wazuh custom rule never fires, and analysisd -t still exits 0: the file name decides

What we measured

What it means

Check yours in a minute

The fix

What we did not measure

Wazuh ms-graph: why Entra ID sign-ins never reach the indexer, and a one-processor fix

1. The stock ruleset has no rule for sign-ins

2. The stock template rejects every sign-in

Check yours in a minute

The fix: one script processor, by type

What we measured, and what we did not

The script

One field path, two shapes: how Wazuh alerts get dropped with a 400 nobody sees

All 4052 if_sid anchors in the Wazuh ruleset resolve, so that's not why your rule is silent

Sixteen detection vendors, one TLS check, and nobody is near the 47-day floor

Controls, because a measurement without one is a story

What this doesn't measure

How to run it yourself

Two coverage zeros, two different causes

What we ran

The Kubernetes zero

The OT zero

Why we are reporting the control, not just the finding

What this does not say

The question worth asking your own stack

I scanned 37 security job posts tonight. Zero were posted in the last 24 hours.

Your SIEM has never been asked a question it could fail

A rule that is present, enabled, and silent: what Wazuh 92900 shows about coverage reports

The discriminator, and why the obvious one is the wrong one

The general shape

We replayed 24 ATT&CK techniques against a default Wazuh install. Three raised an alert.

What it is

What it is not

The same technique, three SIEMs

Two more findings from the same lab — and two things withheld

Dates, because they matter

Why we can publish this and a vendor cannot

Run it yourself

In April, banking was the least post-quantum-ready sector we measured. It is now second from the top.

Global PQ Readiness Index — September 2026

In April, banking was the least post-quantum-ready sector we measured. It is now second from the top.

The number we trust, and why

By sector, same-host cohort

Why we are not publishing the host list

Three things this does not prove

Corrections wanted

HIDS + NIDS: Why Your SMB Needs Both (And How We Integrated Wazuh + Suricata in a Single Platform)

The Blind Spot in SMB Security

HIDS vs. NIDS: A 60-Second Primer

What We Built: Wazuh + Suricata → ClickHouse → AI

The Technical Integration (For the Engineers)

What You See in the Dashboard

HIDS Tab (System Alerts)

NIDS Tab (Network Monitoring)

Threat Map

Security Score

The Cost Argument

Lessons for Other Builders

Try It

The fix: one `script` processor, by type