Evidence for NIS2 and BSI

Go to the contents

NIS2 and the IT-Grundschutz of the German BSI require not only that backups run, but that this can be proven. For this every target keeps an evidence log that cannot be changed afterwards without it being noticed, and creates a signed monthly report from it as a PDF.

12.1 What is recorded#

• every incoming backup and every mirror with client, address, amount of data transferred and result, refusals because of the quota
• every restore with its result
• every job of the target scheduler: what started it (schedule, event, other job, by hand with token and address), what it waited for, how it ended
• every check restore per backup and step
• interventions in the data: deleted runs, changed retention, cleanups with the space freed, damage found, actions through the target API
• the server clock: daily whether it is synchronized with NTP, and every jump of more than 5 minutes

Configuration changes and logins are not in it; they stay in the server's journal.

12.2 How the log is protected#

• Chain: every line contains the SHA-256 checksum of the one before it, across all days. Changing or deleting a line breaks the chain.
• Seal: every day is sealed after its end (00:05) with the target's Ed25519 key and checked right afterwards. If something differs, the operator gets a mail.
• Copy in a second place: every entry at once to a syslog server or a SIEM and/or every sealed day to another target. If the copy fails, nothing is lost; the failure is itself in the log.
• Retention: 10 years (keep-years=), never shorter than up to the oldest run the stores still have. A signed anchor keeps the chain verifiable when old days are deleted.

Section [audit] in /etc/bkp/bkp_target.cfg

[audit]
keep-years=10
syslog=tls://siem.example.net:6514
syslog-ca=/etc/bkp/siem-ca.pem
copy-target=https://backup-muc1.example.net:9991
copy-token=file:/etc/bkp/audit-copy.token
copy-ca=/etc/bkp/backup-muc1.crt
target-id=backup-fra1
report=monthly

The receiving target stores the days under /var/lib/bkp_target/audit-remote/<target-id>/, only if they match the stored public key (/etc/bkp/audit-remote/<target-id>.pub, the audit.pub of the sending target), and never replaces a stored day. bkp_target --sched-validate recommends a copy as long as none is set up.

12.3 Checking, exporting, reporting#

The report sums up a month: backups per backup with successes and failures, restores, check restores, interventions, damage, the jobs and expired waiting periods, the state of the log (chain, seal, copy, fingerprint of the key) and the mapping to the requirements. With report=monthly (default) the target creates it on the first of the month by itself, keeps it for 13 months and mails it with its signature to the operator; customers with report = yes in target-customers.cfg get their own about their backups. report=weekly delivers it on Mondays for the previous week.