Table of Contents
- ISO 27001 Management of Technical Vulnerabilities
- What is ISO 27001 Annex A 8.8 Management of Technical Vulnerabilities?
- How to implement ISO 27001 Annex A 8.8
- How to pass an audit of ISO 27001 Annex A 8.8
- Top 3 Mistakes People Make for ISO 27001 Annex A 8.8
- Get the Help of the ISO 27001 Ninja
- Controls and Attribute Values
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
DO IT YOURSELF ISO27001
STOP SPANKING £10,000s
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.
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.
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 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.
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.
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.
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
Time needed: 1 day
How to comply with ISO 27001 Annex A 8.8
- Have effective asset management and know what assets you have
Have an asset management process that includes an asset register.
- Configure your assets appropriately before use
Implement an asset management process that configures assets before they are used. You will document what your configuration standards are and apply them.
- Have steps in place to identify vulnerabilities
Put in place the ability to identify vulnerabilities. Examples include using threat intelligence, vulnerability scanners, penetration tests, being part of specialist groups and forums and vendor newsletters and alerts.
- Risk assess and priorities found vulnerabilities
When you identify a vulnerability perform a risk assessment of it.
- Action risk acceptance or vulnerability mitigation management to address them
Based on the assessment follow your risk mitigation plan.
- Implement controls proportionate to the risk posed
The vulnerabilities will be prioritised based on risk and controls implemented proportionate to that risk.
- Keep records
For audit purposes you will keep records. Examples of the records to keep include changes, updates, monitoring, review and audits.
- Test the controls that you have to make sure they are working
Perform internal audits that include the testing of the controls to ensure that they are working.
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
|Threat and vulnerability management
|Governance and Ecosystem