CALL US 1-888-553-2256
CountryCountry

The ISO 27001 & ISO 22301 Blog

Antonio Jose Segovia

Logging and monitoring according to ISO 27001 A.12.4

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 section A.14.2 in ISO 27001:2013 is all about. ISO 27001:2013 provides control A.12.4, which contains more details related to logging and monitoring.

Comply with information security legislation

blogpost-banner-consultants-en

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 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:2013 has the subsection A.12.4 Logging and monitoring, to help us to manage most of the issues mentioned so far in this article:

  • 12.4.1 Event logging: Register information about access and actions of users, errors, events, etc. in information systems. In this case, 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.
  • 12.4.2 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.
  • 12.4.3 Administrator and operator logs: Privileges of administrators and operators of systems are different from the normal user privileges, which means that they can perform more actions on systems. In some cases, such activity by default is not registered – and that is a mistake because if an attacker gains access to an unauthorized system, he will probably try to acquire administrator permissions, and perform all actions with this administrator’s user rights. Therefore, systems should register information about all users, regardless of the privileges that they have on the systems.
  • 12.4.4 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.

Use our free  ISO 27001 Gap Analysis Tool to see compliance of your ISMS with the standard’s requirements.

If you enjoyed this article, subscribe for updates

Improve your knowledge with our free resources on ISO 27001/ISO 22301 standards.

OUR CLIENTS

OUR PARTNERS

  • Advisera is Exemplar Global Certified TPECS Provider for the IS, QM, EM and AU Competency Units.
  • ITIL® is a registered trade mark of AXELOS Limited. Used under licence of AXELOS Limited. All rights reserved.
  • DNV GL Business Assurance is one of the leading providers of accredited management systems certification.