Antonio Jose Segovia Updated: January 21, 2023, according to ISO 27001:2022 revision.
It’s easy in “peaceful” times, but when security incidents arise – you need to start from somewhere. And you need to start by finding out what exactly has happened, where, who caused the incident, etc. This is why logs are needed, and you need to monitor them – this is what control A.8.15 in ISO 27001:2022 is all about.
ISO 27001 requirements for logging and monitoring:
- Event logging
- Log storage
- Protection of logs
- Analysis of logs
Comply with information security legislation
To have a system without an event log is a serious mistake, which may in some cases involve penalties for breach of legal regulations concerning protection of personal data. Generally, countries that have regulations regarding protection of personal data require the registration, at a minimum, of the identification of any user who is accessing those data. See the article Laws and regulations on information security and business continuity by country to help you get familiar with the regulations related to information security that apply in your country.
The idea is simple: if an incident or event occurs, we need to determine what was happening: e.g., the time/date of the incident, etc., the people involved, the origin and causes, etc. For example, what do the authorities do when there is a criminal act? They capture the recordings of security cameras. Or, consider also the existence of the black boxes in airplanes, ships, and trains.
Prevent fraud and other incidents
Logs are records about system access, incidents, user activities, etc., so it is also interesting to review the logs on a regular basis, regardless of whether there is an incident or not. This is because they can help us to analyze trends or detect possible fraudulent activities before any major incidents occur. For example, if there are many failed attempts to access a certain critical system (which will be recorded in a log file) of the organization, it could mean that someone is attempting unauthorized access. Or, if in the firewall logs we detect external connections trying to access certain resources, we can identify signs of possible attempted external attacks.
By the way, this article about security incidents might be interesting for you: How to handle incidents according to ISO 27001 A.16.
Ultimately, this information is useful to monitor the system – that is, to know what happens or what is going on in the operation of information systems – and can be used to get information about the origin of an incident, or to identify trends and make decisions to avoid problems.
The importance of logging and monitoring is such that the majority of applications provide the option to register this type of functionality. In some cases, it’s even active by default. This information is also very important in the forensic analysis, because it can be used as evidence in legal proceedings.
ISO 27001 requirements for logging and monitoring
Annex A of ISO 27001:2022 has the control A.8.15 Logging, to help us to manage most of the issues mentioned so far in this article:
- Event logging: Register information about access and actions of users (including systems’ administrators and operators), errors, events, etc. in information systems.
- Log storage: If you have multiple applications, it can be interesting to send the logs generated by each one to a central server. To do this, you could configure a syslog server (syslog is a standard for message logging and can operate over a network with a client-server application structure), which will basically allow you to centralize all the logs on a unique server.
- Protection of log information: The logs must be protected, because they cannot be removed or modified by unauthorized persons. Generally, when an attacker gains access to an unauthorized system, he removes all the information generated in the logs, to remove evidence of any actions he carried out. Therefore, you must set the rules that permit modification of these logs only by certain people, and on the other hand, obviously, the access control measures of the system should be fortified.
- Log analysis: The logs must be analyzed at regular intervals to ensure that unusual behavior and errors are properly detected and investigated in a timely manner.
It is also important to mention in this article the control A.8.17 Clock synchronization. All systems should be configured with the same time and date; otherwise, if an incident occurs and we want to carry out a traceability test of what has happened in the different systems involved, it can be difficult if each one has a different configuration. Therefore, the ideal scenario would be that systems have a synchronized time, and this can be achieved in an automated manner with time servers (technically known as NTP servers, where “NTP” stands for an internet protocol for the synchronization of systems clocks).
Focus on the most sensitive systems
We have seen that it is very important to maintain logs, because they can help us to monitor our systems, and in some cases it is even obligatory. But, beware: going too far with this would be bad, because logs of all information that generate all systems in an uncontrolled way can involve capacity problems.
What is recommended? Identify the critical systems, and limit the information that is logged: user access, failures, errors, etc. It may also be advisable to delete certain logs that were recorded a long time ago and are no longer important, or you can store them in backup systems. Simply stated, it is important to record logs, but it is not important to store all logs indefinitely.
To learn how to become compliant with every clause and control from Annex A, and to get all the required policies and procedures for controls and clauses, sign up for a free trial of Conformio, the leading ISO 27001 compliance software.
