Security Logging and Audit Trails
Records of who did what and when are the raw material for detecting attacks, investigating incidents, and establishing accountability.
If It Was Not Logged, It Did Not Happen
Logs are the memory of a system. Without them, an intrusion leaves no trace to detect, an incident cannot be reconstructed, and no one can be held accountable for an action. Security logging captures security-relevant events, authentications, authorization decisions, configuration changes, command execution, so that both automated monitoring and later investigation have something to work with.
What to Log
- Authentication attempts, successful and failed
- Authorization decisions, especially denials and privilege escalations
- Configuration and policy changes
- Access to sensitive data or safety-relevant commands
- System and security-tool events
Integrity of the Record
An audit trail is only trustworthy if it cannot be quietly altered. A sophisticated attacker's first move is often to erase their tracks. Logs should therefore be shipped promptly to a separate, protected store that the monitored system cannot rewrite, and ideally made tamper-evident so any alteration is detectable. Whoever can command a system should not also be able to delete the record of having done so.
Retention and Usefulness
Logs must be retained long enough to cover the time between a breach and its discovery, which can be months, and structured consistently so they can actually be searched. Overly verbose logging that no one can query is little better than none.
Fusion Context
In the Hyperion breeder and burner designs, security-relevant and safety-relevant actions are logged to a protected, append-only store separate from the systems that generate them, so that command authority and audit authority are held apart. This supports the design principle that no single credential can both issue a safety-relevant command and erase the evidence of it, and it feeds the plant's centralized security monitoring.