Integrate Monitoring into Your ISMS
ISO 27001 cites security monitoring as an essential security control
We know that cyber security isn’t just about operational controls. Instead, it’s a business process that lays down the foundational activities of how we manage security risks. The international standard for security management, ISO 27001, covers eighteen separate control areas, from high-level governance and risk management to asset management, access control, cryptography, operational security and business continuity. Operational security includes four controls that relate to logging and monitoring, each useful in protecting you from attackers. Let’s analyse these controls and see what they could mean to your business.
Event logging is the collection and utilisation of the valuable security information produced by operating systems, network devices and applications. You need to understand how your organisation’s ICT systems provide security information and events. ISO 27001 says, “Event logs recording user activities, exceptions, faults and information security events shall be produced, kept and regularly reviewed.” Put simply, you need to ensure your technology systems are recording user and system activity and that this logging information is available to be reviewed retrospectively as part of an incident response activity or forensic investigation or used proactively as a component of operational security monitoring.
But what does this mean? Every system and application in your business logs what it is doing, some events being relevant to the overall security picture, while others are not. In many cases, the file or local database used to store this information has limited size to save disk space. Consequently, if a lot of information is flowing into it, it can be quickly overwritten.
To review such distributed logs across a large estate is time-consuming. To meet these requirements security teams are resorting to systems that take relevant security information from log sources and transfer them to a central analysis tool, known as a security information and event management (SIEM) solution.
Protection of Log Information
When an intruder breaks into your network, one of the first things they do is look for ways to cover their tracks. This involves flushing audit logs from compromised systems, thus rendering your investigation blind. The second logging and monitoring requirement in ISO 27001 says, “Logging facilities and log information shall be protected against tampering and unauthorised access.”
Organisations without a SIEM are more reliant on endpoint log sources being resilient to attack. However, these logs on endpoints are also prone to attack.
Nevertheless, it is worth using carefully constructed access control lists to protect the log sources, since an investigation that ends up in court might see the opposing council’s technical advisors asking for original data rather than data from the SIEM.
Administrator and Operator Logs
When hackers break into networks, they often try to hijack administrative accounts since these have the most rights and privileges in your organisation. Most importantly, it is the administrative accounts that have the privileges to cover their tracks.
ISO 27001 says, “System administrator and system operator activities shall be logged, and the logs protected and regularly reviewed.” This isn’t just about keeping an eye on your own administrative staff. Insider attacks are much harder to spot, so even if you have not been hacked by an outsider, how do you know your team of a few hundred sys admins doesn’t have one bad apple? Keeping an eye on the logs relating to administrator and operator activity can yield a lot of valuable intelligence for the keen-eyed security operations analyst. Group or permission changes, for example, without an appropriate service request, are things worth investigating. This example could be indicative of an external attacker trying to gain privileges for a compromised account or could indicate an internal member of staff colluding with another user (or a second account of their own) to gain access to somewhere they shouldn’t be. Obviously, this could be a false positive, where the administrator simply forgot to raise a service request and have the change authorised, but even then, it’s an event worthy of investigation.
This (Annex A.12.4 – Logging and Monitoring) is necessary to keep security systems in synch. This requirement states, “The clocks of all relevant information processing systems within an organisation or security domain shall be synchronised to a single reference time source.”
When you investigate an incident, you are looking for a timeline of what happened. If clocks are not properly synchronised, one system might report an event occurred before another one, where in fact it happened in the reverse order. When you come to piece that information together to figure out what happened, the story won’t make sense. When this out-of-sync information is ingested into a central SIEM, it makes querying the database almost impossible, since you are often looking for events after a certain time, so events out of sequence might not appear in the results. This can mean the difference between finding out what happened and not.
Furthermore, timelines are critical in criminal cases. If you are hacked and you intend to take the perpetrator to court, you will need your story to make sense. If the timestamps for events are out of sequence and the story doesn’t make sense, this is grounds for the opposing council to claim your electronic evidence is inadmissible.
Logging and monitoring is a critical activity that falls to your organisation’s operational security team to maintain. They should begin with the log sources and ensure they produce the right information to assist with an investigation. Without this information, a SIEM won’t help and your operations centre will run blind. However, once you have tuned these log sources to produce the right information, gathering and protecting logs into a central location, usually under the control of the security operations centre, is imperative.
The vast quantity of information that requires normalising and categorising means you need a tool (a SIEM) to help your analysts make sense of it. Analysts should be profiling attacks, from the perspective of external hackers, insiders and administrative staff, using their knowledge of how systems are compromised to flag event sequences that could indicate something nefarious.
Remember that your information systems to be synchronised with a central time source. It is vital for both internal and criminal investigations that the timeline is cogent, thus monitoring the availability of the time source and ensuring it’s protected is very important.