CryptoCurrency Security Standard (CCSS) – Audit Logs

In this series we will review each of the core Aspects in the CCSS and provide our interpretation for each of the Aspect’s requirements and what possible evidence could provide assurance to the auditor that a requirement is in-place. Make sure to read our other in-depth articles on the CCSS Aspects:

• Key / Seed Generation (CCSS Aspect 1.01)
• Wallet Creation Requirements (CCSS Aspect 1.02)
• Key Usage Requirements (CCSS Aspect 1.03)
• Key Storage Requirements (CCSS Aspect 1.04)
• Key Compromise Requirements (CCSS Aspect 1.05)
• Keyholder Grant / Revoke Policies & Procedures (CCSS Aspect 1.06)
• Security Tests / Audits (CCSS Aspect 2.01)
• Data Sanitization Policy (CCSS Aspect 2.02)

CCSS Aspect 2.04 Audit Logs

In this article we will explore how an auditor could interpret the CCSS Aspect 2.04 Audit Logs.

Aspect 2.04 Audit Logs addresses audit log management processes to provide a record of events that have taken place within the in-scope environment. The aspects objective defined within the CCSS is provided below.

This aspect covers the information system’s maintenance of audit logs that provide a record of all changes to information throughout the system. In the event of unexpected behavior or security incidents, audit logs are an extremely valuable tool that can help investigators understand how the unexpected symptoms occurred and how to resolve the inconsistencies to return the information system to a consistent state. The maintenance of audit logs significantly reduces the risks associated with operational awareness and increases the information system’s ability to correct any inaccuracies.

Aspects Controls

There are two controls to this aspect.

• 2.04.1 Application Audit Logs
• 2.04.2 Backup of Audit Logs

In this article we will address each control.

CCSS Levels

CCSS provides three levels of compliance – Level 1 being the base level of implementing CCSS requirements up to Level 3 being the most in-depth implementation of CCSS requirements. We shall review each compliance level and provide our thoughts on what evidence an auditor should seek to provide assurance that the requirements are in-place.

Recommendation: Log Event Data to Capture for Each Event

Before we review each requirement a discussion on what data should be recorded for each log event record is required since the current version of the standard (version 8.0) does not provide this information. We recommend reviewing NIST SP-800-92 for more information on recommendations on logging

The data captured in a log record for an event is critical as the captured data must provide enough information to assist auditing, incident response and forensic activities. We propose the following data that must be captured for each log record.

1. Source of event – by recording what device/system and user/service account initiated the event, the log reviewer can identify “ground zero” of the compromise and other compromised assets.
2. Date and time of event – recording the date and time of each event is critical in ensuring the timeline of events is accurate. It is important to note that all systems which generate log events must use the same time source and time zone. If even one system that generates log events is not using the same time source and time zone then the timeline of events can be inaccurate and possibly miss important events.
3. Event code and description of event – most systems which log events will provide an event code and a brief description of the event. This is important information for the log reviewer. Ensure all systems which generate log events provide at least an event code and a brief description of the event.
4. Impacted resource – the log event should record the device, system, data or resource the event impacted. For example, “user account X changed the administrative privileges of user account y”.
5. Success or failure indication – the log event should provide a success or failure indicator for an event. For example, “failed login event for user account y”.

Assembling log events to create a timeline of events in our opinion, requires all of the data above.

Recommendation: Access to Log Event Records

Access to log event records should be restricted to a need-to-know basis. Careful attention as to how the log event records are stored is also an important consideration. As an example, if the log event records are stored on the file system then the user account restrictions should also be applied to the file system folders in which the log event records are stored. This is also relevant when the log event records are stored within a database.

Recording access to the log event records whether via the log management software or directly via the file system folders or database should be recorded for audit, incident response and forensic purposes.

Level 1 Compliance

Audit trails exist for a subset of actions that are performed within the information system.

This requirement leaves the decision as to what type of events to record to the assessed entity since no definition of events to be recorded has been provided by the CCSS, apart from specifying that all events that deal with withdrawals and deposits must be logged. We recommend that the following events are also recorded for CCSS Level 1 compliance.

1. Any key management processes undertaken such as use of keys for signing all types of transactions, addition / removal / modification of keys, rotation of keys and changes to user account privileges to keys / seed phrases.
2. Changes to any device and system configuration data that impacts the protection and use of keys / seed phrases. For example, changes to time configuration of device managing keys, changes to number of participants required for multi-signature tasks.
3. Critical events related to in-scope software within the production environment. For example, a new version of wallet software has been uploaded to production.
4. Any events which could expose malicious activity such as failed login attempts, URL and input manipulation, D/DOS attacks etc.. The assessed entity should have completed a threat modelling process in order to define the threats to the in-scope environment which will then assist in defining what events to log in order to detect a threat.

NOTE: CCSS Level 1 does not provide any log retention period. However, requirement 2.04.1.2 which is a CCSS Level 2 requirement has defined 1 year for audit log retention. We recommend that this retention period is also enabled in CCSS Level 1 certified entities.

Level 2 Compliance

This CCSS Level 2 requirement will impact the amount of storage required to retain logs for a reasonable amount of time to provide relevant data for auditing, incident response and forensic activities.

Depending on the number of devices and systems that are in-scope, the number of log event records generated by BAU activities will be significant and may contain events that provide no real value for auditing, incident response and forensic activities. For example, a service account with no administrative privileges and read-only access to a non-critical report which is used hourly by service desk personnel may not be considered critical to auditing, incident response and forensic activities. In future we hope that the CCSS Committee provides more detailed guidance as to what the standard deems as events to be captured for auditing, incident response and forensic activities. This will assist in reducing the amount of storage required for log retention by the assessed entity.

Requirement: 2.04.2.1 In addition to recording all actions performed within the system, this audit information is periodically backed up to a separate server.

The CCSS Glossary defines “periodically” as “As determined to be sufficient by the auditor”. To assist the CCSSA in the determination of the period we suggest that the assessed entity defines their own schedule to backup log event records to a centralized log management solution based of the assessment of risk that log event records could be corrupted or altered at the point of data origin.

Backing up log event records to a separate server decreases the risk of a malicious actor altering log event records in order to remove traces of activities undertaken. The CCSSA should review the security controls implemented to protect log event records not only at the point of origin but also the log management solution providing a centralized storage of log event records.

The processes that manage the copying of log event records from source of origin to the centralized log management server should be reviewed so the CCSSA can identify any risks associated with the protection of log data at-rest and in transit. For example, if the log event records from source of origin are not copied instantly upon creation to the centralized log management server then the protection of the log event records at the source of origin is especially important as the delay provides opportunity for the malicious actor to alter existing log event records before they are copied to the centralized log management server.

Level 3 Compliance

This requirement has the same objective as requirement 2.04.2.1 but logs are continually backed up. The CCSSA should ensure that the mechanism used to copy log event records to the centralized log management solution addresses the scenario of when the copy mechanism is not working. For example, are log event records queued at the point of data origin and when the mechanism is operational again the queued log event records are sent to the centralized log management solution.

Summary

Aspect 2.04 Audit Logs focuses on logging of events within the CCSS Trusted Environment in order to assist audit, incident response and forensic activities. The protection of log event records while at-rest and in transit is critical as log event records can provide data that can identify how the malicious actor initially gained access to the in-scope environment and what assets have been compromised. The retention period on log event records should also be carefully considered as deleting log event records too soon can remove critical data that will assist audit, incident response and forensic activities.