Audit and compliance

Find a change in the log and see who made it and what changed.

What you need

A sign-in to the appliance. Viewer can read the log, see Users and sign-in.
A time, username or object to investigate.

Find the change

Open Appliance › Log › Activity.
Narrow the list by user, action, object or From and To, then click Filter.
Open the row. Check the action, user and field values before and after.

Check that it works

The row shows the action and object you are looking for. The expanded details show the IP address and changed fields. Passwords and private keys are not written to the log.

If it fails

The list is empty → widen the time range and remove filters. The event may also have been deleted after the licence’s retention period.
Export is unavailable → use at least Operator and Professional or Enterprise, see Export the log.
No hash → the row is outside the hash chain. Do not treat it as chain-verified.
The syslog test fails → read the error on the page. It says whether the name does not resolve, the server does not answer or the certificate could not be verified.
The certificate could not be verified → paste the certificate of your own CA under CA certificate, and check that Host is the name the server’s certificate was issued to.
The test says sent but the recipient has nothing → check the recipient’s port, protocol and firewall. Sending a UDP message does not confirm receipt.
The chain check says a hash does not match sslbrain Cloud → see The chain’s hash in sslbrain Cloud.
The NIS2 package says incomplete → the log before a date was deleted after the licence’s retention period, or the appliance could not compare with the chain’s hash in sslbrain Cloud. The reason is on the first page of explanation.pdf and in audit-chain-check.json.
sha256sum -c prints FAILED → the file was changed after the appliance made the package. Make a new package, see Download the NIS2 package.

Send the log to your SIEM

The appliance sends every row of the audit log to your SIEM or log server over syslog as it is written. This needs Professional or Enterprise and an administrator sign-in. On Basic the page shows that it comes with Professional.

Open Appliance › Log › Forwarding and turn on Syslog forwarding.
Enter Host and Port. Choose TLS (RFC 5425) as Protocol; the default port is 6514.
If the server uses a certificate from your own CA, paste the CA certificate under CA certificate. A certificate from a public CA is verified without it.
Click Save, then Send test message.

Check that the server receives sslbrain syslog test message. The page then shows the last row sent and when.

Each row is sent as RFC 5424 with the chain number and hash in structured data, [sslbrain-audit@32473 chain="appliance" seq="…" hash="…" prev_hash="…"], so your SIEM can check for itself that no row is missing. Forwarding starts with the rows written after it is turned on.

If the server is down, the rows wait on the appliance and are sent in order when the connection works again. The page shows the error while it lasts. TCP and UDP are for collectors without TLS: both are unencrypted, and with UDP rows can be lost without notice.

Export the log

Click Export CSV or Export JSON above the log. This needs Professional or Enterprise and at least Operator. The file is named audit-log-<date>. CSV column headings are in Danish.

Download the NIS2 package

The NIS2 package is one signed ZIP file with your own documentation for the auditor. The auditor can verify it without sslbrain. It needs Professional or Enterprise and at least Operator. On Basic the card says that it comes with Professional.

Open Appliance › Log › Activity and find the card NIS2 package.
Choose From and To, and click Create NIS2 package.
Confirm your login. The package contains user names and IP addresses.
Wait while the card shows the progress. A large log takes a few minutes.
Click Download the NIS2 package. Only the person who created the package can download it. The appliance deletes it after a day.

File	Contents
`explanation.pdf`	Explanation for the auditor with references to NIS2 Article 21, the verification command and the fingerprint of the appliance’s key
`audit-log.csv`, `audit-log.json`	The audit log for the period with chain number and hash for every row
`audit-chain-check.json`	The hash chain check, run when the package was made, and the comparison with the chain’s hash in sslbrain Cloud
`certificates.csv`	The certificates on the day: names, CA, key type and size, issued, expires, and where they are installed
`renewals-and-installations.csv`	Renewals and installations in the period, failures, and when a failure was resolved
`policies.json`	Policies on the day: users and roles, login source, private key export, domain lock, scripts per server, update mode and forwarding to SIEM
`versions.json`	Versions of the appliance, modules and service agents, and whether their signatures are valid
`manifest.json`, `SHA256SUMS`, `SHA256SUMS.sig`, `installation-public-key.pem`	Table of contents, checksums, signature and the appliance’s public key

The policies are as they were on the day the package was made. Changes during the period are in the audit log. The package contains no private keys, passwords or tokens.

Your own documents

The package also holds the documents you would otherwise write yourselves, filled in with the appliance’s settings on the day the package was made. Each comes as a PDF to read and as a Word file or spreadsheet you edit. You fill in owner, approver and dates, and change what is your choice. A value the appliance does not know is shown as unknown or as an empty field.

File	Document
`crypto-policy.pdf`, `crypto-policy.docx`	Cryptography policy and key procedure after Commission Implementing Regulation (EU) 2024/2690, annex point 9: algorithms, your profiles and certificate sources, and the 12 key management points with what sslbrain does, your setting and your task
`risk-register.pdf`, `risk-register.xlsx`	Certificate risk register: expiry, compromised key, a distrusted CA, mis-issuance, sslbrain Cloud down, appliance lost and backup copied, with suggested likelihood and impact, residual risk and fields for acceptance
`incident-procedure.pdf`, `incident-procedure.docx`	Incident procedure for a compromised key and a distrusted CA, and a worksheet with your deadlines under NIS2 Article 23
`responsibilities.pdf`, `responsibilities.docx`	Split of responsibilities under NIS2 Article 21(2), points (a) to (j), with your settings
`mapping.pdf`, `mapping.xlsx`	How Article 21, the regulation’s annex and ISO/IEC 27001:2022 Annex A line up
`effectiveness.pdf`, `effectiveness.docx`	When recovery and alert delivery were last tested, if the appliance knows, otherwise a field for your date

Regulation 2024/2690 binds only the entities in its Article 1, such as cloud and DNS service providers, data centres and managed service providers. For others it is a good reference. The documents support your NIS2 work and are not legal advice. Each document has a version number in manifest.json and is covered by the signature.

Verify the package

Unpack the ZIP file and run the command in the folder. It works on Linux and Git Bash on Windows. On macOS use shasum -a 256 -c instead of sha256sum -c.

openssl dgst -sha384 -verify installation-public-key.pem -signature SHA256SUMS.sig SHA256SUMS && sha256sum -c SHA256SUMS

The command prints Verified OK and OK for every file. If a file has been changed, it prints FAILED. A file that is not listed in SHA256SUMS is not part of the package. An older installation with a P-256 key uses -sha256; the first page of explanation.pdf always shows the right command.

Then check that the key is the appliance’s:

openssl pkey -pubin -in installation-public-key.pem -outform DER | sha256sum

The fingerprint must be the same as Identity key (SHA-256) on the installation’s page in sslbrain Cloud and on the first page of explanation.pdf.

The signature proves that the files are unchanged since the appliance made them. It does not prove that the appliance was uncompromised when it made them.

How the log’s rows connect

Each row has a hash of its contents and the preceding row’s hash. Chained means the row belongs to the chain; No hash means it does not.

The appliance checks the chain nightly for changed, deleted and inserted rows. The result is written to the log and shown on the Chain check card under Appliance › Log › Activity.

A log that someone with access to the database file has rewritten entirely is consistent again. It is detected with the chain’s hash in sslbrain Cloud or in your SIEM.

The chain’s hash in sslbrain Cloud

On Professional and Enterprise the appliance sends the chain number and hash of the latest row to sslbrain Cloud (EU) every hour. Cloud stores them with the time they arrived. Only numbers and hashes are sent, nothing from the log’s contents.

If the appliance reports a different hash for a number Cloud holds, or a lower number than before, the account’s recipients of security alerts get an e-mail. A restore from a backup under Backups is reported by the appliance itself and sends no e-mail.
The nightly chain check compares the appliance’s rows with the hashes in Cloud and writes the result to the log.
For an auditor: open the installation in sslbrain Cloud, tab Audit log hash, and download the list as CSV or JSON. Export the log from the appliance. The row with the same number must have the same hash.

Cloud keeps the hashes as long as the licence’s log in sslbrain Cloud, see the table below.

How long the log is kept

Licence	On the appliance	In sslbrain Cloud (EU)
Free	30 days	7 days
Basic	90 days	90 days
Professional	730 days	365 days
Enterprise	2555 days	1095 days

The Audit log card under Appliance › Licence and status › Status shows the appliance’s retention period. When the period becomes shorter, the appliance waits 30 days before deleting and shows the date.

Find a console session recording

A root shell from the virtual appliance’s console needs a response from sslbrain Cloud and is recorded. Cloud logs who retrieved the response and receives the recording. The recording is also stored on the machine. Choose 9 Danger zone and 3 View recorded shell sessions for the last 10 sessions, see Console menu.

See who can download private keys

An Owner controls this under Appliance › Users and login › Login and sessions › Private key export. Downloads are logged, see Private key export.

Limit who can issue for the domain

CAA is a DNS record specifying which CAs may issue certificates for the domain. Use the CAA generator under Certificates › Tools, see Tools. The account’s domain limit is described under Policy and audit.

See what the appliance does automatically

Appliance › Licence and status › Operation mode shows the automation settings. Changes are made under Updates and written to the audit log. Renewal always runs; the installation plan’s Install on renewal decides whether the certificate is installed automatically.