ISO 27001:2022 – 8.16 Monitoring Activities

Logging and Monitoring in ISO/IEC 2701:2013

In ISO/IEC 27001’s recent 2022 update, eleven new controls were added to bring the standard up to date with the current threat landscape and the risks organisations face. One of these new controls addresses the need for monitoring activities within networks, systems and applications to identify anomalous behaviour so that an organisation can take swift action and address a potential incident.

But wasn’t monitoring part of the 2013 version of ISO/IEC 27001? How is this a new control?

Technically, it was, but not really. Let me explain what I mean. ISO/IEC 27001:2013 has a section titled ‘12.4 Logging and monitoring‘, but when it comes to monitoring, it’s VERY sparse. ‘12.4.1 Event logging‘ states:

“Event logs recording user activities, exceptions, faults, and information security events should be produced, kept and regularly reviewed.”

‘Regularly reviewed’. That’s the extent of monitoring in the old standard. I’m not even sure I would call that ‘monitoring’. If we dig into ISO/IEC 27002:2013 for more information, at the end of 12.4.1, it also states:

“Event logging sets the foundation for automated monitoring systems which are capable of generating consolidated reports and alerts on system security.”

So they did set the stage for some type of automated monitoring and, I guess, hint at it being a good idea, but it’s not defined nor required. So technically, all 2013 says is you need to review your logs.

What changed in ISO/IEC 27001:2022?

Like many of the other structural changes in the new 2022 version, ‘12.4 Logging and monitoring’ has now been split into two sections:

• 8.15 Logging
• 8.16 Monitoring activities

8.16 is listed as a new control because, face it, based on the above, monitoring didn’t really exist in the 2013 version.

What is the expectation of ISO 27001 Annex A 8.16?

As per usual, ISO/IEC 27001 gives us a very short one-sentence requirement, setting up what I still call a control objective. It takes a broad stance so you can implement the right controls based on your risks and your business requirements that satisfy 27001’s objective. It states:

“Networks, systems and applications shall be monitored for anomalous behaviour and appropriate actions taken to evaluate potential information security incidents.”

As we know, it is intentionally broad and vague, so let’s disassemble it.

‘Networks, systems and applications’ doesn’t state which assets. This is what I love about taking a risk-based approach to security. If ISO prefaced that sentence with ‘All’, the cost, resource and time investment would cripple a small business. You get to choose what assets are in scope based on their classification, confidentiality, integrity, availability and other ratings. Not all assets are equal, and you should focus your security controls on those that pose an actual risk to the business. You have this information in your information asset register, so use it and get a greater return on your security investment.

‘Anomalous behaviour’ could be anything, but it’s stated this way because based on your technology stack, how you use that technology, the data that resides within each system, who has access and your identified risks, this will vary greatly from business to business. And these are just a few parameters that will impact what anomalous behaviour is relevant to your business. Again, take a risk-based approach.

‘Appropriate actions’ will be taken when anomalous behaviour is identified. Again, very broad. What actions you take is up to you. These actions could be automated, for example, locking out an account, or they could be manual, where human intervention and assessment are required.

Let’s take a look at ISO/IEC 27002 for more details on what 27001 actually wants.

ISO 27002 monitoring activities implementation advice

As a reminder, you are not required to use 27002 and can choose other control frameworks, but 27002 does provide us insight into what ISO 27001 really wants.

Firstly, it provides the purpose:

“To detect anomalous behaviour and potential information security incidents.”

Ok. Not much from that. It just reiterates what the control description gave us. The Guidance section starts with:

“The monitoring scope and level should be determined in accordance with business and information security requirements and taking into consideration relevant laws and regulations. Monitoring records should be maintained for defined retention periods.”

Firstly, there is a discussion of laws and regulations. This comes into a lot of ISO controls and also controls from other standards and frameworks. Many laws and regulations require you to perform specific tasks or have certain controls in place. You need to know which ones are relevant to your business and ensure you address them.

‘Monitoring scope and level‘ just refers to what you will monitor e.g. which assets and what level or how much logging you will perform. You don’t necessarily need to log every single interaction within a system. It will depend on the system, who uses it and what it’s used for. Make sure it is commensurate to the asset, based on what you have defined within your information asset register, which should be defined off the back of performing business impact assessments (BIAs).

It also discusses the retention of monitoring records. I talked about this a lot in recent articles, specifically 8.12 Data leakage prevention and 8.10 Information deletion. But to reiterate, only keep data as long as you need it for a valid business purpose. Once it is no longer needed, securely destroy it. This reduces your attack footprint and the potential amount of data that can be exposed during a cyber breach. Logs can hold a lot of sensitive data, so holding them longer than needed is a risk. Define your retention periods for these logs and other data within your Data Lifecycle Policy and implement manual or automated processes for removing them when their valid lifetime has expired.

ISO/IEC 27002’s guidance defines a number of areas that ‘should be considered‘, so check the list and see what fits with your requirements and risks. ISO provides a list to ‘consider‘ in a lot of controls. It’s a great way to ensure you have addressed all potential areas and sometimes has things you may not have thought of. In this control, ISO lists:

• Outbound and inbound connections to networks, systems and applications
• Access to assets
• Critical or admin level configuration files
• Logs from security tools
• Event logs
• Checking code is authorised to run on a system
• Use of resources and performance

The guidance section also discusses established baselines for normal behaviour. It’s critical to understand what normal behaviour looks like if you want to monitor for abnormal behaviour. It’s hard to do one without the other.

The control also states:

“Continuous monitoring via a monitoring tool should be used. Monitoring should be done in real time or in periodic intervals, subject to organizational need and capabilities.”

And

“Automated monitoring software should be configured to generate alerts (e.g. via management consoles, email messages or instant messaging systems) based on predefined thresholds. The alerting system should be tuned and trained on the organization’s baseline to minimize false positives.”

Note it says ‘should‘ in both sentences, so it is not required, but to be honest, in 2023, with the amount of data and noise you will see on any network or heavily used system, it’s just not feasible to perform this manually and gain any benefit from your investment. Automated tooling can extract what you need and provide it to you. With AI being integrated into most platforms, we will see this become even easier and better.

Don’t aim for 100% from day one!

One thing I always advocate in information security is don’t try to do everything at once. You don’t need the Rolls Royce of controls from day one. It’s cliché, but security is a journey, and you develop maturity over time. I’ve seen this countless times in my career, where organisations never get anywhere because they never really start. There is so much time and money invested to get the ‘gold standard’ of controls that they never get there, or it appears so daunting that they never start. Start small and grow over time. Getting even the most basic level of controls in place puts you ahead of other organisations.

ISO/IEC 27002 even hints at this in the last section of this control titled ‘Other information’. It states:

“Security monitoring can be enhanced by”

27001 then provides areas to look into when you want to mature and enhance your monitoring capabilities. It talks about threat intelligence and leveraging machine learning and artificial intelligence capabilities. That last one will be huge for this area but is something to discuss another day.

No, you don’t need a SOC to comply!

I’m going to put this out there and hopefully save someone a tonne of time and money. You do not need a security operations centre (SOC) to satisfy this requirement. Could you use one? Yes, of course. Do you need one? No. If you already have one, then great, you can definitely leverage it for this requirement.

I’m sounding like a broken record, but ISO takes a risk-based approach to security, including logging, monitoring and alerting. If you look at other standards, be it PCI DSS, APRA’s CPS 234, SOCI or NIST, none specify that you must have or need a SOC to satisfy their requirements.

I’m not saying SOCs don’t have their place, but the choice to have one needs to be a business decision based on risk and must provide a real return on investment and tangible results, not be a black box where you have no idea of what they are doing or the services they provide. The decision to have a SOC can’t be based on some vendor saying (incorrectly) that you need it to satisfy a compliance requirement or that ‘everyone should have a SOC to be secure’. This is a much bigger discussion, so feel free to reach out if you want some free advice.

How do I comply with ISO 27001:2022 Annex A 8.16?

So, how do you comply with this requirement?

As this control is heavily based on your individual business requirements and risks, there are a few areas that need to be addressed to both satisfy the requirement and gain value out of it. After all, we aren’t just ticking a box here. We want tangible value and real risk reduction.

• Information Asset Register: We have discussed an information asset register before, and if you don’t have one, we have a great article on what it is, its structure and how to create one. I met with a client a couple of weeks ago that had leveraged that article to build out their first information asset register, and they did an amazing job. It was perfect and now provides real value and supports making informed security decisions. The asset register will identify your critical systems, the ones you need to defend and, thus, the ones you need to monitor. This will help you work out the scope of your logging and monitoring mentioned earlier.
• Compliance register: Everyone has some sort of legislative, regulatory or contractual compliance obligations, but few businesses that don’t have a dedicated compliance or risk manager have these documented. To ensure you address any compliance requirements around monitoring and alerting, you must identify and document your obligations. That way, you can ensure you comply. Again, this will dictate additional scope.

Once you have these defined and have your scope of what systems, networks and applications will be monitored, you need to work out what you will be monitoring for. We discussed the various areas to be considered above, and these also need to include specific compliance obligations. For example, APRA’s CPS 234 looks for logging of administrator accounts and activities performed by those accounts.

One thing to be aware of if you are doing this for ISO certification because the control requires you to make the decision on what should be logged and monitored and at what level, you need to be able to justify why you made those decisions. This comes back to your information asset register and compliance register. Without these, you can’t answer that question.

Monitoring and Surveillance

Before I close this article, there is one legal implication to be aware of. Under the Australian Workplace Surveillance Act, an employer may monitor employees in the workplace, including installing monitoring software on their computers, but only if a formal notice and monitoring policy is in place. And these need to be in place before any monitoring takes place.

With this control, which looks at monitoring, depending on what you are monitoring, you may fall under this Act. Ensure you have a policy in place, or it is included within a policy such as an Acceptable Use Policy, and that your employees are made aware. I would suggest having them sign off on your policy to be safe.

Hopefully this gives you some guidance for this new control. If you have any questions about 8.16 Monitoring activities or any other controls, please reach out.