The rule set
A rule in Safi is a plain text file that names what it catches and what it decides. Nothing is hidden in a binary, nothing is a vendor's judgement you cannot inspect, and every one of them can be changed · which is the point of the process below.
Precedence is the order the pipeline wires the files in, and it is deliberately not the order the filenames sort in. A rule that runs later overrules one that ran earlier, so reading the chain top to bottom is reading what actually happens.
One gate worth knowing about.
The file that drops events only ever sees an event some earlier rule has
already moved off keep. That is deliberate: it means nothing is
dropped by omission. An event has to be named twice · once as low
value, once as noise · before it can be discarded.
42 rules across 15 rule files and 104 patterns. Open any one and the event it catches runs through the real chain in front of you.
A rule you can edit but cannot test is not a feature, it is a risk. Each of the seven steps below exists because changing a classification rule changes what a SOC can see, and that has to be provable before it reaches a collector · and reversible after.
A plain text file on the collector. It states what it matches and what class it assigns. No compilation, no vendor console.
One log that hits it, and the near miss that must not. Both go into the catalogue · there are 18 near misses in it today, and they exist because a rule that catches too much is the failure nobody notices.
The whole catalogue is run and each case must reach the rule it claims. A case that reaches a different rule fails the build. This is the check running in this page.
The real pipeline is laid out and validated by Vector itself. Reading a configuration and asking the engine are not the same act, and three releases confused them before this step existed.
The raw archive is run back through the chain as it stands with your change, and every event whose verdict moved is reported · with the volume each change adds to or takes off the indexer. You see the effect of a rule change on real traffic before anyone is affected by it.
The rule set travels as a versioned config pack. The collector reloads and proves itself by testing its sinks again rather than by reporting that a file was written. Nobody opens an ssh session to change a rule.
The previous pack is still there, every rule change is in the audit trail with who made it, and the raw archive is untouched by any of it · so a change you regret costs a reload, not a reconstruction.
The rule set was not written in isolation. Every event id in it was gone through with the customer's own SOC team in their workbook, and each case in the catalogue therefore carries two verdicts: what the chain as written produces, and what was agreed it should produce. The build compares the two on every case, every time.
Cases where the chain does exactly what was agreed in the workbook.
Cases where it does not, reported as divergences rather than as failures, and reported on every build until somebody fixes them.
All five run the same way: the workbook asked for the event to go and the chain keeps it. None runs the other way, so no event the workbook asked to keep is ever dropped by the chain.
Which direction a disagreement runs in is the whole of it. A pipeline that drops something the customer asked to keep has lost evidence and nobody finds out until they go looking for it. A pipeline that keeps something the customer asked to drop has cost a little money and said so. These five are the second kind, and the page below names each one.
What this page does not do. It compares against the agreed positions as recorded in the case catalogue, which is what the build checks. It does not re-read the spreadsheet. Rows added to the workbook after a case was written would not appear here until a case is written for them, which is why a workbook change and a rule change go through the same process.
Each case carries two verdicts: what the chain as written
produces, and what the rule's own comment says it should. Where those differ
the case is a divergence · reported separately from a
failure, and reported every single build until somebody fixes it. There are
5, and they share one cause: the file that drops
events is gated so that an event still on keep never reaches it.
Why show these at all. A pipeline that reduces volume and reports nothing wrong is asking to be trusted. One that names the five places its own rules do not do what their authors intended is telling you what it is actually doing, which is the only basis on which a SOC should accept any of this. These are findings, not test failures, and hiding them inside a passing suite would be the worse of the two.
Reducing log volume is only defensible if you can say what you kept and why. These are the published references the rule set is built to sit inside. Nothing here is a claim of certification · they are the texts a reviewer can hold the design to.
| Reference | What it asks for | Where it lands in Safi |
|---|---|---|
NIST SP 800-92Guide to Computer Security Log Management |
Plan what is logged, prioritise by value, and manage the volume deliberately rather than by collecting everything or nothing. | The whole premise. A rule names what an event is worth, and the decision is written down beside the event. |
NIST SP 800-53 Rev. 5AU family |
AU-6 review and analysis, AU-11 retention, AU-12 generation: records have to exist, be kept long enough and be reviewable. | The raw archive keeps every event whatever the verdict, so retention is independent of what the indexer was sent. |
CIS Controls v8Control 8 · Audit Log Management |
8.2 collect audit logs, 8.3 ensure adequate storage, 8.9 centralize, 8.10 retain, 8.11 conduct reviews. | 8.3 is the one volume reduction actually serves: adequate storage is cheaper to provide when the expensive tier carries only what needs to be there. |
ISO/IEC 27001:2022Annex A 8.15, 8.16 |
8.15 Logging and 8.16 Monitoring activities: produce, keep and protect logs, and monitor for anomalous behaviour. | Logging is the collector and the archives; monitoring is the hub, and the Normality and anomaly add-ons on top of it. |
PCI DSS v4.0Requirement 3.4.1 |
"PAN is masked when displayed, such that only personnel with a legitimate business need can see more than the BIN and last four digits of the PAN." | The card mask keeps the last four and replaces everything before it, including the BIN · stricter than the minimum, and applied on the collector before any archive or index exists. |
MITRE ATT&CKdata sources and components |
Which telemetry a detection actually needs: process creation, logon session, service and account changes. | The keep list is built from exactly those. Process creation, logon, privilege use, service install and account change are never reduced by any rule in the chain. |
RFC 5424 · RFC 3164
syslog |
The wire formats a syslog source has to accept. | What the collector listens for on its syslog port, beside raw newline-framed tcp on leg 1. |
RFC 5737documentation addresses |
Address blocks reserved for use in documentation. | Every address in the sample events on these pages was moved into those blocks before publication, and the move was checked to change no verdict. |
And the components underneath. Safi is built on open-source parts, each given the role it was designed for: Vector for the pipeline, OpenSearch for the hub, Wazuh for the embedded SIEM add-on. Safi itself is Alin Li's product, not an open-source project.
The other page puts a single event through all 9 stages and shows what each one did to it, with 97 sample events to choose from.