%20PNG.png)
With so much data being generated and the use of digital devices increasing exponentially in our personal and business lives, the need to log what’s going on, on your networks has become increasingly important. That’s what this ISO27001 control is focused on. Have you established the need for logging, and if so, what logs are you maintaining?
The whole purpose of this control is to record events, generate evidence, and ensure the integrity of log information. This is to prevent against unauthorised access and also identify information security events that could lead to an information security incident.
Ultimately the purpose of logging of information is so that the information can be used to identify any issues with your systems or help in future investigations and remedial actions.
What does the standard require?
The standard states that “Logs that record activities, exceptions, faults and other relevant events shall be produced, stored, protected and analysed.” (A8.15 – Logging)
Like many ISO27001 controls, this control is multi-dimensional, with a focus on three aspects;
Activities – What’s happening on your systems
Exceptions – Where failure of a process occurs (an ‘exception’ to the norm)
Faults – Errors and system issues that occur
The ISO27001 control also states that logs shall be;
Produced – Ensuring logs are produced somewhere in the device, network or system
Stored – Held in an accessible location and manner
Protected – Protected from alteration or deletion
Analysed – Someone (or some system) is responsible for analysing the logs
Why is this required?
Imagine the scenario that a system has failed, or there has been a security incident. Without some form of logging of activities, it will be incredibly difficult to know what happened prior to the incident occurring. Was the system failure an accident? Did someone do something deliberately to sabotage your business?
Without logging enable, you won’t be able to fully understand if it was a fault of the network, or indeed where the fault or issue occurred. With the increasingly complex infrastructures we rely upon, this could have occurred anywhere, and you have no way of knowing if it will happen again.
Logging of information helps in responding to, recovering, and learning from issues that occur in both your physical and digital infrastructure.
We worked with a client who repeatedly experienced an outage of a critical server that impacted their business. Looking through the system logs we could see the system was shutting down and rebooting around 11pm each evening. After assessing the physical access logs, we discovered that around 10:55pm, the office cleaner was accessing the room where the server was stored. After discussions with the cleaner we discovered they were plugging in their vacuum cleaner in the server room(!) This was enough to trip the power in the room, causing the system to shut down.
Without logging of both physical access and logical access, we wouldn’t have known what was happening.
What the auditor is looking for
For this ISO27001 control, the auditor will expect to see;
Access Control (so that logs are secured from tampering) (A5.15 – Access Control)
Information security event reporting process (A6.8 - Information security event reporting)
Security Incident and Event Management (SIEM) technology
Risk Register.
Management Review Meeting minutes and actions.
What do you need to do?
As with many aspects of ISO27001, this all comes down to risk and the sensitive of data that you’re involved with processing. For example, if you work within law enforcement, it is not permitted to use the systems you have access to, to look up friends and family. There have been cases where this has happened, and it can be a sign that someone is attempting to pervert the course of justice. In a more recent example, hospital staff attempted to access the health records of the Princess of Wales, Kate Middleton. Had logging of this access not been in place, then this information might never had come to light.
Speak to your IT team about what logs are currently being produced. It is likely that a lot of logs are being produced, but not being tracked or monitored centrally. This is something which is covered in ISO27001 Annex A control (A8.1 - Monitoring), but must be first addressed here.
Once you know what is being logged, you should look at your data classification scheme to determine what needs to be logged. For example, do you need to log who goes into and out of a particular part of the building, such as the server room? Perhaps you should log visitors to your premises? If so, how is this being achieved?
Looking at the more technical aspects of logging, do you need to log the number of failed login attempts on a system? If someone is repeatedly trying to gain access a system, perhaps it’s a sign that someone is trying to ‘brute-force’ their way into the system or network by guessing the password. Is this an early sign of an attempt to hack your network or system?
Logging is a relatively technical control and it relies on an understanding of what is possible, so speak to owners of specific systems to understand what logs are created, or can be created.
These might include;
Number of attempts to access a systems or information processing facilities
Failed logins
Inbound and outbound network traffic (e.g. data sent or received)
Access of specific software, systems and locations
Changes to systems, files or code
Creation, deletion or modification of users accounts
System failures or faults
Once these logs are in place you’ll need to understand how these logs are being managed and monitored, but that is the topic for ISO27001 Annex A Control (A8.16 - Monitoring).
Difficulty rating
We rate this a 2 out of 5 difficulty rating. This control requires some level of technical capability, but as with many aspects of ISO27001, it requires an understanding of is possible and therefore requires conversations with the system owner. Just don’t forget that logs can be created for most information processing facilities, including physical security controls. Don’t make the mistake of only focusing on IT systems.
Q&A
How long should we keep logs?
This depends on your requirements, and should be covered in your data retention policy and scheme which you developed as part of ISO27001 Annex A control (A8.10 - Information Deletion). What do you think is acceptable and necessary? For example, you might log access into or out of a particular location for a 30 days, then erase or overwrite the logs. It’s impractical to keep logs indefinitely, so you need to establish a log retention period, but ISO27001 does not stipulate what this is. Only you can decide, so speak to your Management Review Team and establish this as part of your data retention scheme.
How should we ensure integrity of logs?
Limit the access to logs to only a few trusted individuals or systems. Remember that logs might be used in a court of law, as they provide evidence of access, exfiltration, or tampering by trusted individuals or systems. You addressed the matter of segregation of duties as part of ISO27001 Annex A (A5.3 - Segregation of duties), so limit the ability to view or amend logs to a small, select group. Part of ISO27001 Annex A control (A5.15 - Access Control) and Annex A control (A5.18 - Access Rights) should also be understood in relation to this.
More questions?
You’ve probably noticed by now that nothing in ISO27001 sits in isolation, so you should review our FAQ to gain answers to other aspects of the standard. Follow the links in this control to see the relationship in other controls, but if you’re still confused about this control, then please get in touch.
For information on how to implement ISO27001, you might like to consider buying our book “The Real Easy Guide to ISO27001” which is available on Amazon.
Comments