Watch, Detect, Respond: Tips for Logging & Monitoring Activity on your system with ISO 27001:2022 Controls A.8.15 and A.8.16

A.8.15 Logging

Logging aims 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.

Your approach to logging of information and interactions within your systems should be documented in a policy on how your business collects information, for what purpose and how they are protected. 

There are three main things to consider with logging:

1. What information to log and when to log it
2. Protecting the logs
3. Analysing the logs

What Information to log and when to log it.

When determining what information and events should be logged, as mentioned above, it is important to determine the purpose the event is being logged for.

Things to consider including in the log for each event:

• User ID – who performed the action
• System activities – what they did
• Dates, times of relevant events. Ensuring clock synchronisation between your systems and environments allows you to correlate logs from different systems for analysis. This is outlined in control A.8.17 – when they did it
• Device identity, system identifier and location – where they did it from
• Network addresses and protocols – how they did it

These will allow you to know who performed an action, when it was performed, where it was performed from, to give you all of the relevant information you need.

The other part of this is to determine what events you want to log information for. Events to consider, and think about include

• Attempts, both successful and unsuccessful, at gaining access to a system. This will help both know who is logged into a system at a given time. By logging attempts, you can see if malicious users are attempting to access your system using “brute force” or denial of service methods and allow you to prevent these attacks through monitoring and having enough information to appropriately link the attempts and block them.
• Attempts to access resources. Again, logging both successful and unsuccessful attempts will allow you to monitor attempts to gain access to different information resources within your systems.
• Changes to system configuration, allows you to track who and where changes are made to configuration of your systems. This can be used to identify and track any bugs or other errors, or potentially identify malicious actors trying to change configurations to get data out of your system.
• Use of any privileges and privileged accounts. By nature these give more access to your systems and hence have a higher risk of more significant data they have access to being breached.
• Data accessed, including files and the type of access. This should include deletion of important data files. Logging this allows you to know which users accessed what data and when, and who interacted with it. 
• Use of utility programs and applications. Similar to the above point, this will allow you to know when the utility programs were used, and by whom. 
• Alarms raised by access control systems. This is important, as it will create records when users try to access or alter data which they may not have access to. Logging this allows you to monitor for suspicious activity by potentially breached accounts, and potentially helps you monitor the access which is required by staff to do their job.
• Any alterations, including creation and deletion of identities. This allows you to see when identities are changed, potentially granting more access, or created, and ensure that they all have appropriate access. It also allows you to monitor for the creation of any accounts by malicious actors, which can include internal staff.
• Transactions executed within applications. 

Protecting the logs

Logs are created to record interactions and events within systems. Once created, they should be protected from alteration or deletion to preserve the integrity of the records. Even privileged users should not have access to interact with logs within the systems they control. 

To achieve this, controls should be in place to protect logs from unauthorised changes including:

• Changes to the message type being recorded, to prevent any major issues which may cause monitoring alarms from being recorded as less severe.
• Log files being edited or deleted.
• Failure to record events, or over-writing of past events if storage media size is exceeded.

When storing logs, often PII or other private data are included, you will want to consider protecting them using cryptographic techniques, recording in a read-only, append-only file if you are logging to a file. Alternatively, you may want to log to an SIEM Log Management system to store all logs within the same system.

Other things to consider, is whether your logs need to be retained for debugging or regulatory purposes and may need to be archived.

If you need to send log information to third parties for debugging or troubleshooting any system errors or issues, you should consider controls including de-identifying the data using data masking techniques for any PII or other identifiable data including IP addresses, host names, usernames, organisation details among others.

Log Analysis

What is the purpose of collecting all of this system information if you are not going to do anything with it?

Logs should be analysed and interpreted to help identify any unusual activity or anomalous behaviour which can be indicators of system compromise.

When analysing the logs, you should consider the following:

• A procedure for log analysis.
• Any exceptions which are identified through any configured predetermined rules eg. SIEM or firewall rules, intrusion detection systems, or malware signatures.
• The latest threat intelligence.

A.8.16 Monitoring activities

This clause aims to detect anomalous behaviour and potential information security incidents.

There are many different things to monitor to try and protect your data. You should consider your monitoring activities based on your business and information security requirements, as well as relevant laws and regulations. Things to consider monitoring include:

• Inbound and outbound network traffic… this will allow you to monitor for any attacks such as denial of service attacks or monitoring access for any unusual access.
• Access to systems and infrastructure including servers, networking equipment, critical applications, and monitoring equipment. Any data leakage or malicious data extraction will have to leave your network! Additionally, any malicious actors will have had to access the network in order to get any data out of it. Monitoring this, will allow you to determine any compromised accounts, or other accounts used to access your system.
• Event logs and logs from security tools, as outlined in the previous control A.8.15.
• Resource use, including CPU usage, hard disks, memory, bandwidth. As well as monitoring the performance and health of your resources, this will also allow you to monitor any anomalous activity. This could be used to monitor for excessive use, should a malicious actor be attempting to extract a database full of data out of your system, which if monitored, should trigger anomalous behaviour.

When monitoring activity, you should analyse the information and determine what normal activity for each system you are monitoring looks like, and then you can monitor and analyse what is anomalous behaviour and then create alerts based on this, and then investigate the behaviour for maliciousness.

Information to include in the monitoring baselines and anomalous behaviour:

• Unplanned or unexpected termination of services or applications.
• Activity typically associated with malware or other malicious activity including malware or originating from malicious networks or IP addresses. This should include considering where your usual, expected traffic to your system originates from and considering limiting access to these, or limiting access from botnet commands.
• Characteristics of known attacks, using the latest threat intelligence including denial of services 
• Unauthorised access, both actual and attempted to systems or other information, and protected resources including DNS servers, web portals and file systems.
• Bottlenecks and overloads on parts of your system.

Any monitoring records should be maintained and possibly archived for defined retention periods which also consider regulatory requirements.

Other Posts

• Other posts in the series can be found at: A Strategic Approach to ISO 27001 Implementation
• View the previous post in the series: Data Resilience: Protecting Against Leaks, Loss, and Downtime with Controls 8.12 – 8.14