This section addresses Reqs. D1.2-2.17-AuditUntamp, D1.2-3.3-Dash, D1.2-6.10-Redress, and D1.2-7.21-Safe.
Log audit has several goals
In case of attempted repudiation, prove that events happened
For investigation, browse and visualize events so that a human investigator can get a relevant and sufficient overview.
On an ongoing basis automatically detect noncompliant events
On an ongoing basis ensure that the systems are functioning correctly
Provide statistics about users and their behaviour
Provide statistics about system use and behaviour
Provide baseline of information that allows trust, security, and access control mechanisms to be cross checked
Log audit raises several issues
Collection
Distribution
Privacy
Retention
Falsification
Omission
Denial of Service and overwhelming the logging system
The log audit could also be used for billing in some circumstances, but in general we recommend that billing systems be built separately so that they can be cross checked against the logging to detect errors.
A taxonomy of audit events is presented in Annex 8 "Enumeration of Audit Events".
Some design requirements for Audit Log Files are discussed in [TAS3D42Repo]. Further requirements include
Append mode of access: Only append mode of access should be allowed, so that users or applications cannot rewind an audit log file and delete or modify information that has already been stored there
Authorised writing: Only authorised parties should be able to append log records to the audit trail. Though unauthorised applications or attackers may gain access to the audit trail and try to append fake log records to the audit trail, or modify or remove the audit trail, this should be detected by the tamper detection mechanism.
Timestamps: Every record in the audit trail should be timestamped to provide a trusted record of when the audit data was received. We note that if the audit service is trusted to record the audit data without tampering with it, then it should also be trusted to append the correct time to the data. Therefore we do not require a secure time stamping service.
Secure communication: if the audit service operates as a web service then there should be secure communications between the clients and the server in order to ensure tamper resistance, data integrity and authorised connection.
Secure storage on untrusted media: Since an audit trail may be viewed on untrusted machines, the security mechanisms should ensure persistent and resilient storage of the audit trail, and ensure detection of tampering of the audit trail - modification, deletion, insertion, truncation, or replacement. If tampering is detected, the audit service should be able to notify the security auditor.
Support multiple simultaneous clients: The audit service should be easily and conveniently accessible and it should be able to serve multiple client applications simultaneously.
Logging efficiency: The computational work and the storage size required by the audit service should be as efficient as possible.
Contents transparency: the audit service should be able to record any digital content coming from any repository service.
Authorised reading: Since the audit trail may contain personal or sensitive information, then the audit service should ensure that only authorised applications or people have the privilege to read the audit trail. The audit trail may be encrypted to further protect confidentiality.