¶ Why Compliance Reporting Matters
Most security appliances detect attacks. Far fewer can prove they did — in a way an auditor will accept months or years later. Regulations like the EU's NIS2 Directive (Article 21), SOC 2, ISO 27001 and Cyber Essentials all require evidence that is signed, timestamped against a trusted time source, and tamper-evident.
The Defend-O-Tron records that evidence continuously while it protects your network. Every day, the device signs a manifest of the day's logs with an Ed25519 key anchored to NTP-attested time. When an auditor asks for proof, you produce a single signed ZIP covering whatever period they ask about — events, threat decisions, configuration snapshot, NTP attestation, and the daily chain of signed manifests, all in one package.
This is the kind of capability you'd typically pay extra for as a SIEM add-on on Cisco, Fortinet or Sophos. On the Defend-O-Tron it's built in and runs automatically.
¶ What Gets Captured for Audit
The audit subsystem aggregates evidence from every defense component on the device:
- Network intrusion events from Suricata — every alert, with timestamp, source IP, signature, severity, and protocol detail.
- Threat decisions from CrowdSec — who was blocked, when, why, for how long, and which scenario triggered it.
- Firewall packet counters from nftables — proof that blocks were actually enforced, not just logged.
- Ransomware indicators (audit-deb 1.3.0+):
- DNS anomalies (NXDOMAIN/SERVFAIL bursts that suggest a DGA or C2 callout)
- File transfers with SHA256 hashes (cross-reference against known dropper or ransomware samples)
- Suspicious TLS handshakes (self-signed or freshly-issued certs — the classic Cobalt-Strike C2 fingerprint)
- Rotated log files — suricata, ulogd, chrony NTP, auth, syslog, kern, and the Linux audit subsystem.
Every event is timestamped against the device's NTP-attested clock. The daily manifest hashes every log file the device ships and signs the hash list, so any tampering after-the-fact is detectable.
¶ Live View — The NIS2 Evidence Dashboard
The Defend-O-Tron ships a pre-built Grafana dashboard that summarizes the audit evidence in real time. It's titled NIS2 Evidence Pack and reads from a read-only snapshot of the audit event store — so your auditor can sit beside you and watch the same numbers go in.
Where to find it:
- Open the admin interface and click Dashboards in the Cockpit Tools menu (this opens the Grafana web UI).
- Pick NIS2 Evidence Pack from the dashboard list, or browse directly to:
https://dashboard.protected.lan/grafana/d/nis2-evidence-pack/
What you'll see, top to bottom:
- Continuity row — proof the audit subsystem is healthy and on time: when the last daily manifest was signed, how far behind the live Suricata log cursor is, and how recently the event collector last ticked.
- KPI row — operational outcomes for the period you're viewing: events ingested, decisions issued, decisions expired, decisions currently active.
- Trend graphs — events per minute by severity, nftables blocked-packets rate.
- Incident-level tables — the most recent events, currently-active CrowdSec decisions, DNS anomalies, suspicious TLS handshakes, and file transfers with their SHA256 hashes.
- NIS2 Article 21 control mapping — a reference table at the bottom showing which device features satisfy which Article 21 subclause. This is the table your auditor will read against the KPI summary.
¶ Producing an Evidence Pack for the Auditor
When an auditor asks for evidence covering a period — say last quarter — you produce a single signed ZIP with the do-audit-report command from the admin terminal.
The admin terminal is built into the Cockpit interface — open the admin web UI, click Tools → Terminal, then enter the command below. You do not need to SSH separately.
¶ The command
sudo do-audit-report --from 2026-04-01 --to 2026-06-30 --out /home/admin/q2-evidence.zip
--fromand--toare inclusive UTC dates inYYYY-MM-DDformat.--outis the destination path. If you omit it, the ZIP is written next to where you ran the command and nameddefend-o-tron-audit-FROM-to-TO.zip.
Useful flags:
--no-pdf— skip the rendered PDF of the NIS2 dashboard. Use this ifgrafana-image-rendererisn't deployed on your fleet (it's optional).--no-config-snapshot— skip the configuration archive. Useful if your auditor only needs the events.
¶ What's inside the ZIP
| File | What it is |
|---|---|
events.csv |
Every IDS event in the period |
decisions.csv |
Every CrowdSec decision in the period |
dns_events.csv / file_events.csv / tls_events.csv |
Phase 6 ransomware indicators (audit-deb 1.3.0+) |
config-snapshot.tar.gz |
The device's Suricata, CrowdSec, nftables, ulogd, chrony, and node-exporter configuration as it was at report time |
manifests/MANIFEST-YYYY-MM-DD.json |
The daily signed manifest for every day in the period (the chain-of-custody anchor) |
chrony-logs/ |
NTP attestation — proof the device clock was disciplined |
report.pdf (optional) |
Rendered snapshot of the NIS2 dashboard |
manifest.pubring.json |
The device's signing-key ring, so the auditor can verify everything offline |
chain-of-custody.json |
Ed25519-signed SHA-256 manifest of every other file in the ZIP |
The ZIP itself is written with mode 0640, root-owned. It's safe to copy to a USB drive, attach to a ticket, or upload to your compliance portal.
¶ Verifying the Evidence Pack
Anyone with the ZIP can verify it — your auditor doesn't need access to the device. The signing-key ring travels inside the ZIP, so verification works completely offline.
¶ Verifying a single daily manifest
From an extracted ZIP, on any Linux system with Python 3 and the cryptography package, run:
do-audit-verify manifests/MANIFEST-2026-04-15.json
What success looks like:
signature OK (Y8nM3R9...)
files: 142 listed, 0 mismatched, 0 missing
What a tampered manifest looks like:
BAD signature on manifests/MANIFEST-2026-04-15.json (key Y8nM3R9...)
What a tampered log file looks like:
signature OK (Y8nM3R9...)
MISMATCH /var/log/suricata/eve-ids-2026-04-15.json
files: 142 listed, 1 mismatched, 0 missing
Useful flags:
--skip-files— verify the signature only, skip the per-file re-hashing. Faster for spot checks.--pubring /path/to/manifest.pubring.json— verify against the pubring shipped inside this ZIP instead of the one on a live device. Auditors should always use this option when working from an evidence pack on a separate system.
¶ Why this works even if the device is later compromised
The signing-key ring keeps every key the device has ever used, each marked with valid_from and retired_at timestamps. Verifying any manifest looks up the key that was active when it was signed — not the key active today. So manifests signed before a compromise can still be proven authentic after the compromise, as long as you have a copy of the pubring from before the incident (which you do, in every evidence pack you've ever produced).
¶ Key Rotation
The audit signing key can be rotated at any time. Reasons you might rotate:
- Suspected key compromise (e.g. someone with root access you can no longer trust).
- A scheduled rotation policy (yearly is common for high-assurance environments).
- A new device deployment milestone where you want a clean cryptographic boundary.
¶ The command
sudo do-audit-key-rotate
What you'll see:
rotated: retired Y8nM3R9..., active is now A4kP7w2... (at 2026-05-15T18:00:00+00:00)
What happens behind the scenes:
- The currently-active key gets a
retired_attimestamp in the pubring. - A fresh Ed25519 keypair is generated.
- The new public key is added to the pubring with
valid_from = nowandretired_at = null. - The new private key replaces the active signing key on disk.
Key rotation does not invalidate past evidence. Every retired key stays in the pubring forever. Old manifests remain verifiable — they reference the key they were signed with, and that key entry never disappears.
The next daily manifest (and every one after) is signed with the new key. The pubring travels inside every evidence pack, so auditors verifying a multi-year period transparently see all the rotations in sequence.
¶ Retention and Backup
The audit subsystem keeps 365 days of detailed events by default. The daily signed manifests, signing keys, and the underlying event store all live under a single directory:
/opt/data/auditor/
├── keys/
│ ├── manifest.key ← current private signing key (0600 root)
│ └── manifest.pubring.json ← public ring of every key ever used
├── manifests/
│ └── MANIFEST-YYYY-MM-DD.json ← daily signed manifest, one per day
├── events.sqlite ← live event store (WAL mode)
└── share/
└── events.sqlite ← read-only snapshot for Grafana
For a full backup of the audit history, copy /opt/data/auditor/ and its contents. Everything you need to produce or verify evidence packs lives under that one tree.
The audit state lives on the data partition (
/opt/data), separate from the OS image. Firmware updates do not affect audit history.
¶ Notes and Limitations
- Evidence-grade, not alert-grade. The audit subsystem is built for post-incident defensibility, not sub-minute SOC alerting. For real-time threat alerts use the Cyber-Threat dashboard and CrowdSec's own notification channels.
- Phase 6 dashboard panels are partial. As of audit-deb 1.3.0 the DNS / file-event / TLS data is collected and exported in evidence packs, but the corresponding Grafana panels are still landing in service-deb. The CSVs in your evidence ZIPs are complete regardless.
- The optional PDF render needs
grafana-image-renderer. If your deployment doesn't include it, usedo-audit-report --no-pdf. - Auditor verification needs Python 3 + the
cryptographypackage on the verifying machine. Both ship in every modern Linux distribution.
¶ Related Pages
- Dashboards — overview of every dashboard, including NIS2 Evidence.
- External Log Ingress — forwarding logs from other firewalls/routers into the Defend-O-Tron so they're captured for audit alongside the device's own events.
- Honeypot — the bruteforce-detection rules that generate many of the CrowdSec decisions recorded for audit.