Testing the Audit Trail

As I prepare to go to OWASP BeNeLux Day 2009 tomorrow to speak about compliance driven vulnerabilities in web applications, the aspect of auditability came to mind.

Audit logs record user-initiated activity (human or otherwise) in a system or application. They are a trail to establish accountability and responsibility for processed transactions i.e. what, when, where and who. Some form of audit trail is often specified in a web site's requirements, but this is often incorrectly seen as independent to other requirements. All software test cases should also identify the expected audit trail outputs and check they are being generated correctly:

• It is not sufficient for the user functionality to match the requirements alone.
• The generated audit trail must match the tests undertaken.
• It must be possible to determine the original actions from the audit trail.
• Mis-use cases should generate appropriate trails as well.

In-built audit hooks (embedding code in applications for the examination of selected transactions) and continuous auditing (near real-time auditing logic) must not introduce their own vulnerabilities:

• The extra complexity of audit code in an application requires additional security verification.
• Identify the trust boundaries around these parts of the application.
• Ensure the audit code cannot be used by malicious users to circumvent other controls such as authentication and authorisation.

Test cases will also need to be prepared to verify the protection and management of the audit trail. Ensure the integrity of the audit trail:

• The trail must be protected from subsequent modification (alteration and deletion).
• Even if the amount of logging is configurable, the default should provide sufficient detail for the business's needs.
• It should not be possible to completely inactivate all audit trail generation.

NIST have a useful document SP 800-92 on management of security logs—many of the considerations are similar for the protection of audit trails.

The extraction and examination of audit trail data must be controlled:

• Audit trails may contain personal and other sensitive information.
• The data may give away information regarding the application's code and logic.
• Consider whether parts of the data may need to be excluded, masked or encrypted.
• The privileges to read audit trails should be restricted and reviewed periodically.
• All access to the audit trail must be recorded and monitored by a separate manager.
• Audit trail data must not be destroyed before the duration of its required data retention period, and not kept beyond this time.

Remember that in some jurisdictions, capture of any personal data or monitoring of employees may need particular approval and safeguards, and some data may not be allowed to be stored at all. Happy verification!