DEV Community

Cover image for πŸ’ŽπŸ’ŽπŸ’ŽπŸ” Security Logs: Cryptographically Signed Audit Logging for Data Protection
Cossack Labs
Cossack Labs

Posted on • Originally published at cossacklabs.com

πŸ’ŽπŸ’ŽπŸ’ŽπŸ” Security Logs: Cryptographically Signed Audit Logging for Data Protection

Audit logs should provide security-relevant information, but they are just logs, who will protect them? Here we bring up to speed on cryptographically signed security logging for data protection.

We implemented crypto-signed audit logs in Acra, our database protection suite, and would like to share our findings and tips in a new engineering blog post. Read it in full, or get up an appetite for audit logging with an abstract.

Cut through complexity!


Audit log, aka β€œaudit trail”, is a set of security-relevant log records in a chronological order, which identifies a source and a reason of a log, and provides relevant context for further investigation.

The purpose of the audit log is to provide documentary evidence of the sequence of activities and help to reconstruct what happened (as a response to an incident or regulator inquiry). As audit logs become the security source of truth, they require protection.

However, as logs are just text messages, they require a set of security procedures (see NIST SP 800-92) and often become an easy target to manipulate and tamper.


Security requirements towards cryptographically signed audit logs

While studying various secure logging systems (β€œA New Approach to Secure Logging” paper had a significant influence on us), we gathered a set of security requirements for crypto signed audit logging:

  1. Log messages in each log entry should be protected against tampering (symbols editing).

  2. The structure of the log chain should be protected against modification: adding, removing separate log entries.

  3. Log chains should be protected against truncation attacks when logs are truncated from the end of the chain.

  4. Crypto signed audit logs should be initialised as early as possible at startup of logging service, to reduce the number of unprotected log entries in the log chain.

  5. Service restart/shutdown should not lead to inconsistent audit logs. If service was shut down due to the emergency, audit logs should be verifiable.

  6. Key security: a cryptographic key (used for computing integrity checks) should be stored in dedicated key storage, and reside minimum time in service’ memory take a look at aes-finder utility that scans memory for AES keys).

  7. Acceptable performance: the ability to verify production volumes of protected logs in seconds. Performance directly affects incident detection and reaction time (MTTD, MTTR), if verification of audit logs is an automated monitored procedure.

  8. Log rotation friendliness: audit logs should be compatible with log rotation policies typical for distributed systems.


Click to learn in detail what cryptographically signed audit logging is, when and why you might need crypto signed audit logs, as well as about implementing secure audit trail (in particular, in Acra), a cryptographic scheme for secure audit logging, producing and verifying secure logs, open sourcing audit logging module, etc.

Top comments (0)