Companies often grapple with security frameworks as if it were a deeply theological question.
Maybe you are a US multinational that has inherited NIST based controls but your clients want a certification of compliance which the NIST 800-53 cannot provide. Maybe you are an organisation who’s deeply technical experts reject broad-based controls in favour of highly specific and applicable ones.
But the theological discussions on which is best and most appropriate for an organisation expose a basic misunderstanding in the scope of these two frameworks.
ISO 27001 and NIST 800-53 are not mutually exclusive. In fact, quite the opposite is true.
You can adopt both and get the best from both worlds by exploiting the synergy between these two frameworks and many other frameworks and control sets besides.
Frameworks are not equal
ISO 27001 is not about controls. It is about creating and managing an ISMS. An Information Security Management System. It is a framework for managing a set of controls to mitigate security risks. A method for ensuring that the organisation is constantly on top of its game, regardless of the detailed controls that actually sit within the framework.
As a result, the 114 generic controls in Appendix A of the ISO 27001 are designed to be broad and essentially applicable to all, in some shape or form.
NIST 800-53 on the other hand is a set of security controls that constitute best practice, that has been collected and evolved over time. Over 250 security controls sit within the NIST 800-53r4 framework, so it is clearly at a more detailed level of construction than the Appendix A controls.
NIST 800-53 is however a voluntary scheme and has no certification or accreditation basis. Much of the demand for security controls is not just to mitigate the security risks of an organisation, but to be seen to be mitigating the security risks as an organisation, to your clients and regulators.
Not one or the other, but both
What if you could take the certification and assurance of external review provided by ISO 27001, but marry it with the deeper control sets of NIST 800-53 and others (OWASP, SANS, etc)?
Well you can. There is absolutely nothing stopping you doing that.
This is the basis of the misunderstanding with ISO 27001. Organisations and practitioners assume that they are wedded to the 114 controls, and must comply with them regardless of their applicability to the organisation’s requirements.
On the contrary, expanding the 114 controls to add specific, detailed controls that are required to mitigate security risks is exactly the intended purpose of ISO 27001. The ISO 27001 is very clear that by completing the Statement of Applicability (SoA), you can remove controls that are not in scope for your organisation. What is less clearly defined is that you can do the exact opposite as well. You can add custom controls to the SoA, that you believe are required to mitigate a risk uncovered by your risk assessments.
In this way, you can add whatever controls you want into the SoA, from any source, on the basis that you believe it is the correct control to mitigate the risk presented to you in the risk assessments.
Peace treaty at hand
To get the best out of both frameworks, you should create an ISMS under ISO 27001 and certify it. This provides your organisation with externally validated assurance of your controls environment. Underneath this ISMS, you can insert any applicable controls that you believe to be required to mitigate your risks. From any source. You will need to update your SoA to explain why controls are in and why controls are out, but this is all that is required.
This will allow you to add controls from OWASP top 10, SANS, the CMMC, the NIST CSF, NIST 800-53 and the list goes on and on.
Time for an Example: Access Control
Let’s assume your organisation delivers a number of web services and develops its own web service applications. Your security experts like more specific controls and you want to incorporate some of those mitigating controls into your ISMS.
- Within NIST 800-53r4 that would be: AC-1 to AC-25 (Access Control)
- In OWASP top ten: C7 (Access Control)
- In NIST CSF: PR.AC-1 to PR.AC-5 (Protect/Access Control)
OWASP C7 (5) is an explicit control that requires that access roles are not hardcoded within applications.
This control has no direct mapping within the 114 Appendix A controls in ISO 27001. We want to add this control because this risk was flagged as requiring mitigation in our risk assessment.
Simply add a new control under A.9 (Access Control) within your ISO 27001 Statement of Applicability to make 115 controls in total. Explain in the SoA why this new control is there and what it is intended to control.
It is really that simple. No security fundamentalism. No compromises. Everyone gets their requirements for controls put in place. The management get a certificate that they can wave at clients and regulators that their security framework has been externally tested and assured. The security experts get their favourite controls added.
As long as your risk assessment deems a control to be required to mitigate a risk, you can add whatever control you want to the SoA. From any source.
