Skip to main content

Annex I, Part I, Req 2l: Security-Related Information Logging in Software

Understanding what happened after a security event, or detecting suspicious activity, often relies on good logs. The EU Cyber Resilience Act (CRA) states that products with digital elements shall, where applicable, "provide security related information by recording and monitoring relevant internal activity, including the access to or modification of data, services or functions, with an opt-out mechanism for the user" (Annex I, Part I, Point 2l).

What to Log for Security​

Your software should generate logs that are useful for security purposes. "Relevant internal activity" could include:

  • Access Events: Successful and failed login attempts.
  • Modification of Data: Who changed what data and when (especially for sensitive data or configurations).
  • Access to Services/Functions: Attempts to access critical functions or services within the software.
  • Administrative Actions: Changes to security settings, user permissions, etc.
  • Errors and Exceptions: Especially those that might indicate a security problem.
  • Security Control Events: Alerts from internal security mechanisms (e.g., intrusion detection if built-in).

Logging Best Practices​

  • Sufficient Detail: Logs should contain enough information (timestamps, user IDs, source IPs, event type, outcome) to be useful for investigation.
  • Integrity: Protect logs from tampering.
  • Availability: Ensure logs are available when needed for analysis (but consider retention policies).
  • Confidentiality: Logs themselves might contain sensitive information, so protect them from unauthorized access.

Monitoring​

"Monitoring relevant internal activity" implies not just generating logs but also having a way (even if it's manual review for smaller applications, or integration with security tools for larger ones) to look for suspicious patterns or specific events.

User Opt-Out Mechanism​

The requirement includes "an opt-out mechanism for the user." This is an interesting point. It suggests that for certain types of logging, especially those that might capture user activity in detail, users should have the ability to disable it. The specifics of this opt-out would depend on the nature of the software and the data being logged. It’s crucial that this opt-out doesn't compromise essential security logging needed for the product's own protection or critical incident response. This likely refers to user-activity specific logs rather than core system security logs.

Key Takeway​

Under Annex I, Part I, Point 2l of the CRA, your software needs to log relevant security events related to access and modification of data or functions. These logs help in monitoring and incident response. Users should have an opt-out for certain types of activity logging.