In May last year, Morrisec Co-CEO Dr Sarah Morrison wrote an insightful article on how ISO/IEC 27002 and NIST CSF can be used interchangeably when certifying to ISO/IEC 27001. It’s now 2023 and we decided to revisit this topic but go a bit deeper, and also because new versions of ISO/IEC 27001 and ISO/IEC 27002 were released last year making it even easier and more relevant for organisations that have multiple compliance obligations or are asking that age-old question of ‘Which security standard is best for my organisation?‘. There is also a new version of NIST’s Cybersecurity Framework on the way, which we also touch on.
This article aims to clarify some of the misconceptions surrounding the controls framework of ISO/IEC 27001 and demonstrate that both ISO and NIST provide more flexibility than many people realise.
Although it turned out longer than I planned, stick with me to the end as it contains valuable information that is rarely discussed. So bear with me, grab a coffee and let me take you on a magical compliance journey…
ISO/IEC 27002 in 2023 and beyond
Both ISO/IEC 27001 and ISO/IEC 27002 underwent significant updates in 2022, resulting in a more streamlined approach that is better aligned with the current threat landscape. This is a much-needed improvement over the previous version, which was released back in 2013.
In the 2013 version of ISO/IEC 27001, Annex A, the section that addresses controls, is titled ‘Reference control objectives and controls’ and the 2022 version has changed to ‘Information security controls reference’. The wording in both these titles is critical in understanding the intent of 27001 when it comes to controls. The keywords are ‘control objectives‘ and ‘controls reference‘.
Annex A of ISO/IEC 27001 is not intended to be prescriptive, meaning it does not provide a list of exact controls that must be implemented. Such an approach would undermine the fundamental principle of ISO/IEC 27001 as a risk-based approach to information security. The implementation of ISO/IEC 27001 must be adapted to the specific needs of each organisation, based on factors such as size, industry, business operations, threat landscape, and risk profile. Many organisations and consulting firms assisting in certification run into problems and often give up because they fail to grasp this critical concept. It’s why you’ll hear people make comments about ISO/IEC 27001 being too hard or too costly, or comments around how their organisation is too small to be certified. These are all untrue. Make sure you take a look at our ISO/IEC 27001 article, which addresses many of these common misconceptions.
Annex A serves as a guide for possible controls to mitigate identified risks and outlines the expected outcomes or objectives that can be achieved by implementing these controls. This is where ISO/IEC 27002 comes into play. ISO/IEC 27002:2013 is titled ‘Security techniques – Code of practice for information security controls‘ and 27002:2022 has been changed to just ‘Information security controls‘. I prefer the old title from Annex A in 27001 that has ‘control objectives‘ as it makes the intent clearer. While 27001 Annex A provides the objective you want to achieve to reduce an identified risk, 27002 provides implementation advice on how to actually achieve that objective.
Using an example, in Annex A of 27001:2022, ‘6.1 Screening’ states:
“Background verification checks on all candidates to become personnel shall be carried out prior to joining the organization and on an ongoing basis taking into consideration applicable laws, regulations and ethics and be proportional to the business requirements, the classification of the information to be accessed and the perceived risks.”
This is pretty vague, but that’s the whole point. The objective is you want to ensure adequate background checks are performed to reduce the risk you hire someone that ends up becoming an insider threat. But at the same time, it uses words like ‘proportional to the business‘. This is because it doesn’t want to be prescriptive and enforce unwieldy processes and procedures on a company beyond what they need to address their level of risk. Background checks, such as state or federal police checks, are costly and time-consuming. There is no point enforcing this for low risk hires. Implement a control that is relevant to the job role, the information they have access to and the potential risks posed by that hire.
The accompanying section in 27002:2022 under the title ‘Guidance’ (which again is not prescriptive) states:
“A screening process should be performed for all personnel including full-time, part-time and temporary staff. Where these individuals are contracted through suppliers of services, screening requirements should be included in the contractual agreements between the organization and the suppliers.”
By the way, I’m only copying part of this as it’s more than a full A4 page.
So 27002 is providing plenty of implementation advice or ‘Guidance‘ on what to include in your HR onboarding process to address this risk, such as:
- Make sure it addresses full-time, part-time and temporary staff
- Make sure it addresses individuals contracted through suppliers as well (a commonly missed area)
- Include screening requirements in supplier contracts
That last one is a critical one that’s commonly missed and if you were just reading the 27001 control objective, you wouldn’t think of it when it says ‘all candidates‘. You may put in great processes to screen your staff on hire, but without addressing suppliers you end up with support staff from a supplier that has full access to all your data with zero background checks 😔
The critical takeaway here is ISO/IEC 27001 defines an objective it wants from a specific control area. Neither Annex A nor ISO/IEC 27002 provide a prescriptive list of specific controls or dictate how they should be implemented. Rather, ISO/IEC 27002 offers guidance to ensure that all necessary areas are covered to achieve the desired objectives.
NIST Cybersecurity Framework
The NIST Cybersecurity Framework (CSF) is a framework that provides guidelines for organisations to manage and reduce cybersecurity risks. As some background, it was developed by the National Institute of Standards and Technology (NIST) in response to Executive Order 13636, which called for the development of a framework to improve cybersecurity across critical infrastructure sectors. The framework provides a common language to communicate about cybersecurity risk management and includes standards, guidelines, and best practices.
In the past, organisations with operational technology (OT) environments have often relied on NIST due to the perception that it specifically addresses cybersecurity in critical infrastructure sectors more comprehensively than other standards. While this is partially true, it’s important to note that the NIST Cybersecurity Framework is primarily intended to assist organisations in mitigating, responding to, and recovering from cybersecurity risks in any environment, not just critical infrastructure. It doesn’t help the perception when the current version, while labelled ‘Cybersecurity Framework’ on each page of the standard, has the actual standard’s title defined as ‘Framework for Improving Critical Infrastructure Cybersecurity’. Thankfully, according to the draft version 2.0, it’s now titled ‘NIST Cybersecurity Framework’.
The NIST CSF comprises five core functions that serve as the foundation for the framework. These include.
- Identify: This function involves identifying and understanding the organisation’s cybersecurity risks, assets, systems, and data. The purpose of this function is to develop a comprehensive understanding of the organisation’s cybersecurity posture and identify potential vulnerabilities.
- Protect: This function involves implementing safeguards and measures to protect the organisation’s systems, assets, and data from cybersecurity threats. The purpose of this function is to reduce the risk of a successful cybersecurity attack.
- Detect: This function involves implementing processes and tools to detect cybersecurity events and incidents as they occur. The purpose of this function is to enable timely response and mitigation of cybersecurity incidents.
- Respond: This function involves developing and implementing plans to respond to cybersecurity incidents when they occur. The purpose of this function is to contain the incident and minimise its impact.
- Recover: This function involves developing and implementing processes to restore normal operations after a cybersecurity incident. The purpose of this function is to ensure that the organisation can resume its business functions as quickly and efficiently as possible.
The functions are then broken down further into categories that are similar to ISO domains, but there is a distinct focus on incident management in the CSF, with three out of five functions covering this domain, being Detect, Respond and Recover. Categories are also broken down further into subcategories which are basically controls and similar to ISO/IEC 27001’s Annex A control objectives. Like ISO, the objectives are intentionally vague. Going back to our 27001 example around screening, NIST CSF has PR.IP-11:
“Cybersecurity is included in human resources practices (e.g. deprovisioning, personnel screening)”
You could say its even more vague and open to interpretation than 27001 😆
What NIST does provide with each subcategory is references to other standards. It varies by subcategory but for this example it references CIS CSC, COBIT 5, ISA 62443-2-1:2009, ISO/IEC 27001:2013 and NIST SP 800-53 Rev. 4. So like ISO/IEC 27001 leveraging ISO/IEC 27002, NIST CSF is meant to leverage a supporting controls framework for implementation advice. The great thing around NIST CSF is it recognises that you may have other standards you want to use, like ISO, but it gives you actual references. If you wanted to only use NIST frameworks, you would use the NIST SP 800-53 Rev. 4 references. NIST SP 800-53 Rev. 4 describes itself:
“This publication provides a catalog of security and privacy controls for federal information systems and organizations and a process for selecting controls to protect organizational operations.”
Very similar to ISO/IEC 27002 isn’t it? 😉
Small note. If using NIST CSF, NIST SP 800-53 Rev. 4 was superseded by v5 September 23, 2021 but as NIST CSF was published before 2021, it references the older version.
So why doesn’t ISO/IEC 27001 reference other frameworks?
‘So why doesn’t 27001 reference frameworks like NIST CSF does?’ I hear you ask. As of 2022 it does! Sort of. But you need 27002 to reference them. And it only works for NIST. Sort of. But you can pivot from NIST to other frameworks which is neat.
So the workflow is ISO/IEC 27001 > ISO/IEC 27002 > NIST CSF > Other controls frameworks. Ok, let me explain that. It’s not as bad as it sounds.
With the release if ISO/IEC 27002:2022 in February 2022, a whole swathe of additional reference information was added to each control. I go through these in more detail in an article I’m releasing Thursday so stay tuned. But for this discussion, one component they added was what they have called “Cybersecurity concepts”. The standard states:
“Cybersecurity concepts is an attribute to view controls from the perspective of the association of controls to cybersecurity concepts defined in the cybersecurity framework described in ISO/IEC TS 27110. Attribute values consist of Identify, Protect, Detect, Respond and Recover.”
Look familiar? These five cybersecurity concepts align with NIST CSF’s five core functions. So this makes it easier to reference controls back to NIST. It still doesn’t give you the NIST CSF subcategory for an exact match, but at least puts you in the right area. You can then find a relevant subcategory that then has references for other standards including NIST SP 800-53. This will make it much easier for your ISO/IEC 27001 Statement of Applicability (SoA) and justifying your reasoning to auditors if you are certifying to ISO/IEC 27001 but using NIST for your controls, but I’ll talk about certification later.
I should also mention before someone pulls me up on it, you could always link them even in the past with the 2013 versions of the ISO standards, by going backwards from NIST CSF. Each NIST CSF references the associated ISO/IEC 27001 Annex A control objective, so you could search NIST CSF for your required Annex A control and find the associated subcategory. You can download the NIST CSF Framework Core 1.1 in Excel format to make this even easier.
So what’s the real difference between 27002 and NIST?
Short answer, not a lot in 2023. With the planned NIST CSF 2.0, they have even added a 6th function, ‘Governance’, which highlights the importance of this function within cybersecurity risk management and brings it further inline with ISO/IEC 27001. The same goes with NIST’s expanding of supply chain risk management, and ISO/IEC 27001 adding ‘Information security for use of cloud services’ in the 2022 version, which we will be discussing further in coming weeks.
One key difference is NIST CSF includes more detailed controls for managing suppliers and incident response compared to ISO/IEC 27001. Specifically, the NIST CSF recommends conducting incident response exercises with critical suppliers, which is more comprehensive than the requirement in ISO/IEC 27001 to assess suppliers who have access to data and assets. We discussed this earlier when I mentioned CSF has a deeper focus on incident management.
Probably the biggest and most important differences is you can be certified to ISO/IEC 27001. No certification exists for NIST CSF. You can align, comply, get someone like Morrisec to audit you and give you a great report telling you how well you comply, but you can’t get that shiny certificate and put that ISO/IEC 27001 Certified badge on your website and marketing materials. I discuss the benefits of certification in my ‘What is ISO 27001?’ article, so have a read if you want to know what these benefits are and why it could be beneficial for your business.
Can I certify to ISO/IEC 27002?
This is a touchy one with me and I’ll confess, one of my triggers. If you tell me you are certified to ISO/IEC 27002 you’ll see me lose it 😂 In my many years traversing this fragile cybersecurity wasteland, I don’t even want to think about how many times I’ve seen things like ‘certified to ISO/IEC 27001/27002’. Sorry. You can’t do that buddy.
When you certify against ISO, you are certifying against ISO/IEC 27001, not against ISO/IEC 27002. As we have discussed at length, 27002 provides implementation advice you may or may not decide to use. Clause 6.1.3 of 27001 which addresses information security risk treatment has a note that states:
“Organizations can design controls as required, or identify them from any source.”
So as you can imagine, you can’t certify to ISO/IEC 27002 as you may not have used a single control from that standard. As long as you have reduced your risk using controls commensurate to your business and your risk, and satisfied the control objectives outlined in ISO/IEC 27001, you can use any controls from any framework, or design your own. But you can’t certify to those controls frameworks, and this includes 27002.
In closing, and a last word on mergers and acquisitions
So hopefully after reading this you’ve come to the realisation that ISO/IEC 27002 and NIST CSF are very much interchangeable, and picking one doesn’t exclude you from using the other. When engaging new clients, a very common question we get asked is what cybersecurity framework is best suited for their organisation and their type of business. It’s a case by case response and there is no default answer, but the most important thing we discuss with them is that they don’t have to pick one or the other. You can combine the best of both worlds and use what works best for your business.
We have worked with a lot of clients that have acquired other businesses or have been part of a merger where security frameworks don’t align. One business uses ISO/IEC 27001, the other NIST. The flexibility of these frameworks means you don’t have to throw one out the window and all use the same one, which can be both a political and implementation nightmare. The two can work in harmony and you can still get your whole organisation certified to an established and trusted international standard without much effort.
Reach out if you have any questions as these are simple problems we’ve successfully solved time and time again for our clients.
0 Comments