NIS2 Directive: Incident Evidence Preservation Failure on Volatile Crashlogs
Unpreserved FortiOS kernel and daemon crashlogs overwritten after system panics or hardware watchdog reboots prevent critical infrastructure operators from satisfying mandatory 24-hour and 72-hour incident evidence disclosure under EU NIS2 Article 23.
Technical Root Cause Analysis
The European Union NIS2 Directive (Directive 2022/2555) imposes binding obligations on essential and important entities across energy, healthcare, water, and transport sectors. Under Article 23, entities must furnish national CSIRTs (Computer Security Incident Response Teams) or competent authorities with an initial notification within 24 hours and a detailed forensic update within 72 hours of detecting an incident that causes severe operational disruption or suspected exploitation.
When a FortiGate suffers an active exploitation attempt—such as heap overflow attacks against sslvpnd or memory corruption inside wad—the Linux kernel or daemon panics. Critical execution telemetry (instruction pointer registers, stack frames, call parameters, and initiating socket descriptors) is written solely to the internal flash crashlog partition. If the unit automatically reboots, or if a watchdog timer forces a power cycle, subsequent service startups generate hundreds of benign initialization lines. Within 6 to 12 hours, the circular crashlog wraps around, purging the original zero-day exploit signature. Forensics teams are left unable to prove whether memory corruption led to remote code execution (RCE) or simple process denial of service, exposing the organization to statutory fines of up to €10,000,000 or 2% of total worldwide turnover.
Affected Firmware & Compliance Blast Radius
| FortiOS Branch | Crashlog Buffer Type | Wrap-Around Retention | NIS2 Compliance Risk |
|---|---|---|---|
| FortiOS 7.4 / 7.6 | NVRAM / Flash (Circular 256KB) | 4–12 hours under active load | High without automated export stitch |
| FortiOS 7.2 | NVRAM / Flash (Circular 128KB) | 2–6 hours under active load | Critical (Fast overwrite risk) |
| FortiOS 7.0 | NVRAM / Flash (Circular 128KB) | 2–4 hours under active load | Critical (Fast overwrite risk) |
Platform Impact: Essential and Important entities operating within the European Union across energy grids, water systems, transport, financial market infrastructures, and digital providers.
Step 01: Free Verification CLI (Safe Read-Only)
Execute these commands immediately following any unexpected firewall failover or reboot to extract volatile crashlog telemetry before it is overwritten:
Diagnostic Commands
# 1. Read the raw crashlog partition to extract panic traces and timestamps
diagnose debug crashlog read
# 2. Inspect kernel build, compiler version, and system uptime
fnsysctl cat /proc/version
get system status
# 3. Check historical crashlog entries summary
diagnose debug crashlog history
# 4. Verify whether crashlog streaming to FortiAnalyzer/syslog is enabled
show log setting | grep -i "event"Remediation & Workaround Steps (Teaser Preview)
Follow the complete step-by-step remediation guide in the Ferrite interactive platform:
Frequently Asked Questions
NIS2 Directive Article 23 requires essential and important entities to submit an 'early warning' within 24 hours of becoming aware of a significant incident, an 'incident notification' within 72 hours with initial assessment and indicators of compromise (IoCs), and a final report within one month containing technical root cause evidence.
FortiOS writes crash events into a dedicated flash/NVRAM partition. However, if a hardware watchdog resets the unit, or if multiple worker processes crash repeatedly during a DDoS or exploitation loop, the circular buffer wraps around and overwrites the original exploit stack trace within hours.
Yes, by configuring event logging under 'config log eventfilter' with 'set event enable' and setting up an automation stitch triggered by LogID 0100022001 (system crashlog recorded).