What a Real SIEM Taught My Detection Rules: India Threat Tracker, Phase 2

Last week I launched the India Threat Tracker: an open feed of the exploited vulnerabilities, fake-APK campaigns and state-nexus actors that matter for defenders in India, plus five detection rules to go with them.

The honest gap in that launch was the step after reading. A list of exploited CVEs tells you what to worry about. It doesn't tell you whether your firewall is on it, it doesn't plug into the tools a CTI team already uses, and five detection rules with green unit tests aren't the same as five rules that fire in a SIEM.

Phase 2 is about closing those three gaps. It's a research preview, and I've tried to be exact about what each piece has and hasn't been tested against.

1. The detections, in a real Wazuh

My detection tests used to run the rules against an emulator: Python code that applies the rule logic to test events. Every rule passed. Then I installed a real Wazuh 4.14.9 manager in CI, loaded the rules unchanged and replayed the same events through it as raw logs.

It found three bugs the emulator could not have found, because each one lives in how Wazuh decodes a log, not in the rule logic:

• The PAN-OS rule could never fire. Wazuh's Palo Alto decoder captures each CSV field up to the next comma. A PAN-OS admin-login description contains commas, so the decoded description field is cut off before the From: <address> part the rule needed. The rule now matches the full log line.
• wazuh-logtest can't test Windows rules at all. Logtest always uses the generic decoder and never calls the Windows eventchannel decoder. Replay a Sysmon event through it and it decodes as plain JSON, so no Windows rule can fire. A "pass" for a Windows rule in logtest proves nothing. The test harness now sends Sysmon events the way a real agent does, through the manager's queue.
• Doubled backslashes broke the DNS rule. The eventchannel decoder JSON-encodes the event before parsing it, so HKLM\System\... arrives as HKLM\\System\\.... My DNS resolver rule expected single backslashes between registry keys and would never have matched on a real manager. It now accepts one or more.

After the fixes, all 29 test events behave as expected on the real engine. The validation report has every event, expected versus observed, and the commands to reproduce it. Splunk and Elastic still aren't run against a live instance, and the docs say so.

The lesson I'm taking away: a detection is only tested once the real decoder has seen the raw log. Everything before that is testing your understanding of the decoder.

2. An exposure matcher that never sees your data

The Exposure Matcher takes an asset inventory as a CSV (vendor, product, version, and whether it's internet-facing) and checks it against every CVE on CISA's Known Exploited Vulnerabilities list.

Two design decisions matter more than the feature itself.

Your inventory never leaves the browser. The file is read and matched on your device. The page downloads two public data files and nothing else, and I verified that with a browser test that records every network request. There's also an offline CLI that runs the same engine.

It refuses to guess. Affected versions come from the official CVE records, as the vendor wrote them, and vendor version data is messy:

• Palo Alto lists hotfix fixes per maintenance branch (12.1.4-h12, 12.1.7-h8). Read naively, 12.1.5 would look fixed. It isn't listed as fixed, so the matcher calls it uncertain.
• Citrix sometimes writes 13.1 < 49.15, which means builds of 13.1 below 49.15, not versions 13.1 to 49.15. Read naively, a patched 14.1 box would be flagged.
• Some records just say "All other versions" or give nothing at all.

So every result is one of three things: affected version (the record's own data puts your version in an affected range), candidate (the product matches but the version can't be settled), or insufficient evidence. About 40% of KEV CVEs have version data clean enough for a confident answer. The rest come back as candidates to check against the vendor advisory, and the page says exactly that. A matcher that turned the other 60% into confident yes-or-no answers would look better and be worse.

Priority isn't a hidden score either. P1 means an affected version on something internet-exposed or critical, or a CVE with known ransomware use. Every result explains its tier.

3. STIX 2.1, for the tools CTI teams already use

The campaigns, actors, indicators, ATT&CK techniques and monthly assessment now ship as one STIX 2.1 bundle: 121 objects with sources and confidence attached. It passes the official OASIS validator in CI, and object ids are stable, so re-importing updates objects instead of duplicating them.

What I wanted to get right was what doesn't go in. Hosting providers and platforms a campaign abused (GitHub, Firebase) are never indicators; they're described as context with a "do not block". Attribution stays a reported qualifier, never a hard relationship. Dates the sources don't give aren't invented.

I also ran the bundle through misp-stix, the library MISP uses for STIX import. Every object and all five indicators survive. One thing doesn't: the 54 "uses" links between actors and the techniques or malware they use, because MISP flattens them onto the event. That's documented. A full import into a running MISP is automated in CI, and OpenCTI is still untested.

Try it, break it

• The tracker, now with compact cards you can expand.
• The Exposure Matcher: try the synthetic sample first.
• The repository, with the changelog and every validation level spelled out.

If you run Wazuh, MISP or OpenCTI and something doesn't behave the way the docs say, or the matcher gets a version wrong for a product you know well, I want to hear about it. That's exactly the kind of evidence this phase is missing.