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).
This control maps to 196 controls across 43 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.
Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.
ISO 27002:2022 8.15 is one control. If you already hold one of the frameworks below, a reviewed crosswalk already says how much of ISO 27002:2022 your existing evidence covers. Hold NIST SP 800-53 Rev 5 and 79 of 93 ISO 27002:2022 controls already carry evidence.
Each report names every control your existing framework evidences, every one it does not, the reasoning behind each claim, and the claims that were argued against and rejected. 180 were rejected on the NIST SP 800-53 Rev 5 pair alone.
The graph holds this control, the 196 it maps to, and the evidence behind each claim, over MCP and REST.