ISO 27002:2022 – Control 8.15 – Logging

Purpose of Control 8.15

Logs – whether in the form of application logs, event logs or general system information – form a key part of obtaining a top-down view of ICT events and employee actions. Logs allow organisations to establish a timeline of events and scrutinise both logical and physical patterns across their entire network.

Producing clear and easily obtainable log information is an important part of an organisation’s overall ICT strategy, and accompanies numerous major information security controls contained within ISO 27002:2002.

Logs should:

• Record events.
• Collect evidence.
• Protect their own integrity.
• Secure log data against unauthorised access.
• Identify actions and events that could lead to an information/security breach.
• Act as a tool to support internal and external investigations.

Attributes Table of Control 8.15

Control 8.15 is a detective control that modifies risk by adopting an approach to logging that fulfils the above objectives.

Ownership of Control 8.15

Control 8.15 deals with ICT operations that are performed using system administrator access, and fall under the umbrella of network management and maintenance. As such, ownership of Control 8.15 should rest with the Head of IT, or organisational equivalent.

Guidance – Event Log Information

An ‘event’ is any action performed by a logical or physical presence on a computer system – e.g. a request for data, a remote login, an automatic system shutdown, a file deletion.

Control 8.15 specific that each individual event log should contain 5 main components, in order for it to fulfil its operational purpose:

• User ID – Who or what account performed the actions.
• System activity – What happened
• Timestamps – Date and time of said event
• Device and system identifiers, and location – What asset the event occurred on
• Network addresses and protocols – IP information

Guidance – Event Types

For practical purposes, it may not be feasible to log every single event that occurs on a given network.

With that in mind, Control 8.15 identifies the below 10 events as being particularly important for logging purposes, given their ability to modify risk and the part they play in maintaining adequate levels of information security:

1. System access attempts.
2. Data and/or resource access attempts.
3. System/OS configuration changes.
4. Use of elevated privileges.
5. Use of utility programs or maintenance facilities (see Control 8.18).
6. File access requests and what occurred (deletion, migration etc).
7. Access control alarms and critical interrupts.
8. Activation and/or deactivation of front end and back end security systems, such as client-side antivirus software or firewall protection systems.
9. Identity administration work (both physical and logical).
10. Certain actions or system/data alterations carried out as part of a session within an application.

As explained in Control 8.17, it is vitally important that all logs are linked to the same synchronised time source (or set of courses), and in the case of third party application logs, any time discrepancies catered to and recorded.

Guidance – Log Protection

Logs are the lowest common denominator for establishing user, system and application behaviour on a given network, especially when faced with an investigation.

It is therefore vitally important for organisations to ensure that users – regardless of their permission levels – do not retain the ability to delete or amend their own event logs.

Individual logs should be complete, accurate and protected against any unauthorised changes or operational problems, including:

• Message type amendments.
• Deleted or edited log files.
• Any failure to generate a log file, or unnecessary over-writing of log files due to prevailing issues with storage media or network performance.

ISO recommends that, in order to improve information security, logs should be protected using the following methods:

• Cryptographic hashing.
• Append-only recording.
• Read-only recording.
• Use of public transparency files.

Organisations may need to send logs to vendors to resolve incidents and faults. Should this need arise, logs should be ‘de-identified’ (see Control 8.11) and the following information should be masked:

• Usernames
• IP addresses
• Hostnames

In addition to this, measures should be taken to safeguard personally identifiable information (PII) in line with the organisation’s own data privacy protocols, and any prevailing legislation (see Control 5.34).

Guidance – Log Analysis

When analysing logs for the purposes of identifying, resolving and analysing information security events – with the end goal of preventing future occurrences – the following factors need to be taken into account:

• The expertise of the personnel carrying out the analysis.
• How logs are analysed, in line with company procedure.
• The type, category and attributes of each event that requires analysis.
• Any exceptions that are applied via network rules emanating from security software hardware and platforms.
• The default flow of network traffic, as compared to unexplainable patterns.
• Trends that are identified as a result of specialised data analysis.
• Threat intelligence.

Guidance – Log Monitoring

Log analysis should not be carried out in isolation, and should be done in tandem with rigorous monitoring activities that pinpoint key patterns and anomalous behaviour.

In order to achieve a dual-fronted approach, organisations should:

1. Review any attempts to access secure and/or business critical resources, including domain servers, web portals and file sharing platforms.
2. Scrutinise DNS logs to discover outgoing traffic linked to malicious sources and harmful server operations.
3. Collate data usage reports from service providers or internal platforms to identify malicious activity.
4. Collect logs from physical access points, such as key card/fob logs and room access information.

Supplementary Information

Organisations should consider using specialised utility programs that help them search through the vast amounts of information that system logs generate, in order to save time and resources when investigating security incidents, such as a SIEM tool.

If an organisation uses a cloud-based platform to carry out any part of their operation, log management should be considered as a shared responsibility between the service provider and the organisation themselves.

Supporting Controls

• 5.34
• 8.11
• 8.17
• 8.18

Changes and Differences from ISO 27002:2013

ISO 27002:2002-8.15 replaces three controls from ISO 27002:2003 that deal with the storage, management and analysis of log files:

• 12.4.1 – Event logging
• 12.4.2 – Protection of log information
• 12.4.3 – Administrator and operator logs

27002:2002-8.15 largely corroborates all the guidance points from the above three controls into one clear protocol that deals with logging, with a few notable expansions, including (but not limited to):

• An expanded set of guidelines that deal with the protection of log information.
• Additional guidance on the various event types that should be considered for scrutiny.
• Guidance on how logs should be both monitored and analysed in a joint effort to improve information security.
• Advice on how to manage logs produced by cloud-based platforms.

New ISO 27002 Controls

How ISMS.online Helps

The ISMS.Online platform helps with all aspects of implementing ISO 27002, from managing risk assessment activities through to developing policies, procedures and guidelines for complying with the standard’s requirements.

With its automated toolset, ISMS.Online makes it easy for organisations to demonstrate compliance with the ISO 27002 standard.

Contact us today to schedule a demo.