Logging

What the requirement asks

Logs recording activity, exceptions, faults and other events of interest are to be generated, kept, protected and analysed. Purpose: record events, produce evidence, keep log information intact, block unauthorized access to it, spot security events that could become incidents and support investigations. Guidance: a topic-specific logging policy documents why logs are created, what is collected and any protection and handling requirements. Each log entry should, as applicable, contain user IDs, system activities, dates, times and details of events such as log-on and log-off, device and system identifiers and location, and network addresses and protocols. Events to consider logging include successful and rejected attempts to access systems and to access data or other resources; system configuration changes; use of privileges; use of utilities and applications; which files were accessed and how, including removal of important files; alarms from access control systems; switching security systems such as anti-virus or intrusion detection on or off; creating, changing or deleting identities; and user transactions in applications, including those run by third parties. Synchronized time sources (8.17) are essential for correlating logs. Protection: nobody, including privileged users, should be able to delete or disable logs of their own activity; because administrators can tamper with logs on systems they control, logs must be protected and reviewed to keep them accountable. Protect against changes to what message types are recorded, editing or deletion of log files, and failure to record or overwriting of old entries when storage fills, using techniques such as cryptographic hashing, append-only read-only files or public transparency logs. Some logs must be archived for retention or evidence purposes (5.28). Before sending logs to a vendor for troubleshooting, de-identify usernames, IP addresses, hostnames or the organization name where possible (8.11), and protect PII in logs (5.34). Analysis: interpret events to find unusual or anomalous behaviour that may indicate compromise, considering the skills needed, a defined analysis procedure, the attributes each security event needs, exceptions flagged by predefined rules (SIEM, firewall, IDS, malware signatures), comparison of known patterns and normal traffic with anomalies (user and entity behaviour analytics), trend and pattern analysis, and threat intelligence. Support this with monitoring such as reviewing access attempts on protected resources such as name servers, portals and shared folders; checking DNS logs for outbound connections to malicious servers such as botnet controllers; examining provider usage reports and invoices for unusual activity; including physical entry and exit logs; and correlating logs. Suspected and actual incidents, such as malware infection or firewall probing, are investigated further (5.25). Other information: filtering tools help find significant events in voluminous logs; logging underpins automated monitoring (8.16); SIEM tools store, correlate, normalize and analyse logs and need careful source selection, rule tuning and use-case development; transparency logs help detect tampering; cloud logging responsibilities are shared (ISO/IEC 27017). In the ISMS the control is compared with the controls determined in risk treatment and recorded in the Statement of Applicability as included or excluded, with the reason and the implementation status.

What the guidance adds

Logging needs a purpose, a retention and a reviewer. The guidance asks for the source, the content, the protection and the use.

What good looks like

Put the control in the Statement of Applicability with an owner, a status and the risk it treats. Then keep the topic-specific logging policy defining purposes, events to be logged, fields captured, retention and protection and one live sample together.

Evidence an assessor asks for

• Logging policy and coverageThe topic-specific logging policy defining purposes, events to be logged, fields captured, retention and protection
• Logging policy and coverageLog source inventory showing which systems send which event types to central logging or SIEM
• Logging policy and coverageConfiguration evidence that logs are tamper-protected (append-only storage, hashing, restricted deletion) and that administrators cannot erase their own activity
• Logging policy and coverageSIEM correlation rules, use cases and alert tuning records, and evidence of regular log review
• Logging policy and coverageInvestigation records for suspicious events identified from logs
• Logging policy and coverageProcedures for de-identifying logs before sharing with vendors and protecting PII in logs

The question an assessor will ask

An assessor will ask for the topic-specific logging policy defining purposes, events to be logged, fields captured, retention and protection, then trace it to the system it protects. For A.8.15 the test is whether that record ties to a live sample, not whether the control is named in a policy.

Common gaps

• Critical systems or cloud services are not sending logs to central collection
• Administrators can delete or disable logging on systems they manage
• Logs overwrite themselves when storage fills, losing evidence
• Logs are collected but nobody analyses them until after an incident

Before the next audit

Before the next audit, check one live sample for this gap: critical systems or cloud services are not sending logs to central collection.