ISO 27001 Annex A 8.8 Management of Technical Vulnerabilities

ISO 27001 Management of Technical Vulnerabilities

The focus for this ISO 27001 Annex A Control is being aware of technical vulnerabilities you have and the addressing them as is appropriate to you. As one of the ISO 27001 controls this is about assessing vulnerabilities and managing them.

You will learn what ISO 27001 Annex A 8.8 is, how to simply and easily implement it for ISO 27001 certification and I will show you some common gotchas so you can avoid them.

What is ISO 27001 Annex A 8.8 Management of Technical Vulnerabilities?

ISO 27001 Annex A 8.8 Management of Technical Vulnerabilities is an ISO 27001 control that looks to make sure you understand what vulnerabilities exist in your technology and make informed decisions to manage them.

ISO 27001 Annex A 8.8 Purpose

The purpose of Annex A 8.8 Management of Technical Vulnerabilities is to ensure information and other associated assets are protected from the exploitation of technical vulnerabilities.

ISO 27001 Annex A 8.8 Definition

The ISO 27001 standard defines Annex A 8.8 as:

Information about technical vulnerabilities of information systems in use should be obtained, the organisations exposure to such vulnerabilities should be evaluated and appropriate measures should be taken.

ISO 27001:2022 Annex A 8.8 Management of Technical Vulnerabilities

How to implement ISO 27001 Annex A 8.8

With management of technical vulnerabilities there are a couple of things to consider and the complexity of the control will be based on what you do and how complex your environment is.

Let’s consider first what you do. If you create software or hardware then there is a chunk of extra stuff that you are going to have to do here ranging from how you manage releases, patches, updates and communications. Remembering that this is guidance, take a common sense approach to your releases. I am not going to delve too deeply into this as for the majority this use case won’t apply but suffice to say you will need a strong, documented process and consider things like:

• Vulnerability reporting – when people find them in your stuff how do they report them
• Vulnerability management – what you do when someone tells you they found something
• Vulnerability communication – what and how you tell people that there is a vulnerability in your stuff
• Vulnerability roles and responsibilities – who is doing what

In more general terms let us now look to the things that impact everyone.

Know what technology you have

We start at the beginning by knowing what we have. Why? Because we cannot protect what we do not know. You will need asset registers that record what you have and we have covered this elsewhere in

• ISO 27001 Annex A Control 5.9 Inventory of information and other associated assets 
• ISO 27001 Annex A Control 5.10 Acceptable use of information and other associated assets 
• ISO 27001 Annex A Control 5.11 Return of assets
• ISO 27001 Annex A Control 5.12 Classification of information
• ISO 27001 Annex A Control 5.13 Labelling of information
• ISO 27001 Annex A Control 5.14 Information transfer

The basic guide for this step is know what assets you have.

Configure your assets properly before use

Solid technical vulnerability management is part of the standard and links to this control by removing services that are not needed, blocking those not needed that cannot be removed and having solid configuration and technical management practices in place.

Know what vulnerabilities you have

When you implement your vulnerability management process you need to put in place the identification of those vulnerabilities. There are varying degrees of depth that you can go into here. Let us take a look at some ways we can identify vulnerabilities.

Vendor Alerts

Vendors as a rule will continually release patches and updates to address vulnerabilities that are found in their products. They will either alert you in the technology itself and / or send you communications such as emails or updates on their websites. Be sure you have included this in your process. It is a simple and quick win.

Specialist forums

It really depends here but for some technologies there are communities and forums that are set up. Some are official, some unofficial, but these can be great sources of information and early warnings and remediations.

Penetration Tests

Penetration tests are an old school way of identifying vulnerabilities. There are different approaches, from annual tests to on going or periodic tests. These usually address configuration vulnerabilities, ie the way you have set the technology up and are using it, but they are can on occasion find more fundamental flaws. Include these if they are appropriate to you.

Vulnerability Scanners

There are technologies that you can consider that will do continuous or periodic scanning of your environment for vulnerabilities. We are moving up the tiers of complexity and cost here, but based on risk this maybe something that you would want to implement.

Threat Intelligence

With the introduction of ISO 27001 clause 5.7 threat intelligence having access to bulletins, news letters and sources of information on emerging malware threats should be incorporated into processes and risk planning so that you can have a process of continual improvement and vulnerability management that will seek to mitigate those threats.

Assess Vulnerabilities

Once you know what vulnerabilities there are, your process should be to assess them. In assessing them we are doing a risk assessment to understand the risk the vulnerability poses. Once we know the risk of the vulnerability we can then prioritise it and plan our mitigation. Use good risk management practices. It maybe that you can accept the risk. The output of this step should be a risk score, prioritisation and risk decision.

Address the Vulnerability

Once you have made a decisions on what to do about the vulnerability then put in place a plan and action it. It maybe that you accept the risk, and therefore follow your risk management process for risk acceptance. Alternatively, it maybe that you need to address the vulnerability directly by implementing a patch or configuration change. Using your change management process you complete your remediation. There are things to consider here which are covered more in change management but we raise them for awareness being things like the timings, the need to test the change, the ability to back it out, the communication of it, the acceptance of it. This will be built into your processes but the point of this step is that once you have identified and assessed a vulnerability, you will address it.

ISO 27001 Templates

ISO 27001 templates have the advantage of being a massive boost that can save time and money so before we get into the implementation guide we consider these pre written templates that will sky rocket your implementation. This ISO 27001 Toolkit has been specifically designed so you can DIY your ISO 27001 certification, build your ISMS in a week and be ISO 27001 certification ready in 30 days.

How to pass an audit of ISO 27001 Annex A 8.8

Top 3 Mistakes People Make for ISO 27001 Annex A 8.8

The top 3 mistakes people make for ISO 27001 Annex A 8.8 are

1. Penetration Testing

The act of a penetration test is not actually a mistake but conducting it annually is. A point in time audit once a year maybe the bare minimum you can get away with but it is not best practice and usually tests are conducted in test environments or controlled environments that do not reflect reality. Sure you want to do them but think carefully what you are trying to achieve with it. If it is to tick a client need then great but if you truly want it to add value to the vulnerability management process and protecting you then engage your supplier with THAT requirement and follow their guidance.

2. You never apply patches

Patches and patch management is the most simple and straightforward way to meet the control but not having it work or patches not applied is the biggest mistake we see that fails people come audit. Do not assume you have patched and it works before the audit happens, check it. You may be surprised.

3. Your document and version control is wrong

Keeping your document version control up to date, making sure that version numbers match where used, having a review evidenced in the last 12 months, having documents that have no comments in are all good practices.

Get the Help of the ISO 27001 Ninja

Book your FREE 30 Minute ISO 27001 Strategy Call and let me show you how you can do it 30x cheaper and 10x faster that you ever thought possible.

Controls and Attribute Values

Control type	Information security properties	Cybersecurity concepts	Operational capabilities	Security domains
Preventive	Availability	Protect	Threat and vulnerability management	Protection
	Integrity	Identify		Defence
	Confidentiality			Governance and Ecosystem