7.3 KiB
#iso27002/2022/EN
8.15 Logging
| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains |
|---|---|---|---|---|
| #Detective | #Confidentiality #Integrity #Availability | #Detect | #Information_security_event_management | #Protection #Defence |
Control Logs that record activities, exceptions, faults and other relevant events should be produced, stored, protected and analysed.
Purpose To record events, generate evidence, ensure the integrity of log information, prevent against unauthorized access, identify information security events that can lead to an information security incident and to support investigations.
Guidance
General
The organization should determine the purpose for which logs are created, what data is collected and logged, and any log-specific requirements for protecting and handling the log data. This should be documented in a topic-specific policy on logging.
Event logs should include for each event, as applicable: a) user IDs; b) system activities; c) dates, times and details of relevant events (e.g. log-on and log-off); d) device identity, system identifier and location; e) network addresses and protocols.
The following events should be considered for logging:
a) successful and rejected system access attempts; b) successful and rejected data and other resource access attempts; c) changes to system configuration; d) use of privileges; e) use of utility programs and applications; f) files accessed and the type of access, including deletion of important data files; g) alarms raised by the access control system; h) activation and de-activation of security systems, such as anti-virus systems and intrusion detection systems; i) creation, modification or deletion of identities; j) transactions executed by users in applications. In some cases, the applications are a service or product provided or run by a third party.
It is important for all systems to have synchronized time sources (see 8.17) as this allows for correlation of logs between systems for analysis, alerting and investigation of an incident.
Protection of logs
Users, including those with privileged access rights, should not have permission to delete or de-activate logs of their own activities. They can potentially manipulate the logs on information processing facilities under their direct control. Therefore, it is necessary to protect and review the logs to maintain accountability for the privileged users.
Controls should aim to protect against unauthorized changes to log information and operational problems with the logging facility including:
a) alterations to the message types that are recorded; b) log files being edited or deleted; c) failure to record events or over-writing of past recorded events if the storage media holding a log file is exceeded.
For protection of logs, the use of the following techniques should be considered: cryptographic hashing, recording in an append-only and read-only file, recording in a public transparency file.
Some audit logs can be required to be archived because of requirements on data retention or requirements to collect and retain evidence (see 5.28).
Where the organization needs to send system or application logs to a vendor to assist with debugging or troubleshooting errors, logs should be de-identified where possible using data masking techniques (see 8.11) for information such as usernames, internet protocol (IP) addresses, hostnames or organization name, before sending to the vendor.
Event logs can contain sensitive data and personally identifiable information. Appropriate privacy protection measures should be taken (see 5.34).
Log analysis
Log analysis should cover the analysis and interpretation of information security events, to help identify unusual activity or anomalous behaviour, which can represent indicators of compromise.
Analysis of events should be performed by taking into account:
a) the necessary skills for the experts performing the analysis; b) determining the procedure of log analysis; c) the required attributes of each security-related event; d) exceptions identified through the use of predetermined rules [e.g. security information and event management (SIEM) or firewall rules, and intrusion detection systems (IDSs) or malware signatures]; e) known behaviour patterns and standard network traffic compared to anomalous activity and behaviour [user and entity behaviour analytics (UEBA)]; f) results of trend or pattern analysis (e.g. as a result of using data analytics, big data techniques and specialized analysis tools); g) available threat intelligence.
Log analysis should be supported by specific monitoring activities to help identify and analyse anomalous behaviour, which includes:
a) reviewing successful and unsuccessful attempts to access protected resources [e.g. domain name system (DNS) servers, web portals and file shares]; b) checking DNS logs to identify outbound network connections to malicious servers, such as those associated with botnet command and control servers; c) examining usage reports from service providers (e.g. invoices or service reports) for unusual activity within systems and networks (e.g. by reviewing patterns of activity); d) including event logs of physical monitoring such as entrance and exit to ensure more accurate detection and incident analysis; e) correlating logs to enable efficient and highly accurate analysis.
Suspected and actual information security incidents should be identified (e.g. malware infection or probing of firewalls) and be subject to further investigation (e.g. as part of an information security incident management process, see >5.25>).
Other information
System logs often contain a large volume of information, much of which is extraneous to information security monitoring. To help identify significant events for information security monitoring purposes, the use of suitable utility programs or audit tools to perform file interrogation can be considered.
Event logging sets the foundation for automated monitoring systems (see 8.16) which are capable of generating consolidated reports and alerts on system security.
A SIEM tool or equivalent service can be used to store, correlate, normalize and analyse log information, and to generate alerts. SIEMs tend to require careful configuration to optimize their benefits. Configurations to consider include identification and selection of appropriate log sources, tuning and testing of rules and development of use cases.
Public transparency files for the recording of logs are used, for example, in certificate transparency systems. Such files can provide an additional detection mechanism useful for guarding against log tampering.
In cloud environments, log management responsibilities can be shared between the cloud service customer and the cloud service provider. Responsibilities vary depending on the type of cloud service being used. Further guidance can be found in ISO/IEC 27017.