Comparing NIST’s Cybersecurity Framework with ISO/IEC 27001

This week, NIST published Version 1.0 of its Framework for Improving Critical Infrastructure Cybersecurity (aka Cybersecurity Framework). I reviewed the last draft for the framework here on the blog a while ago, and also sent some minor comments back to NIST. (Along with the major one to not try and reinvent the wheel. ;-))

Now that Version 1.0 is out there, I decided to spend a bit of time analysing how it compares to the approach of ISO/IEC 27001 (in short: 27001). 27001 provides industry-agnostic requirements for information security management, has been around for a while, and continues to gain traction. Read on if you are already using 27001 for managing information security in a critical infrastructure context, are contemplating it, or are just curious.

Cybersecurity Framework 1.0

Since its last draft, the Cybersecurity Framework (CSF) has seen a lot of polishing, and I mean this in a positive sense: Inconsistencies have been sorted out, language has been improved, etc.

The Executive Summary has some points that are worth stressing, notably that the framework is a voluntary one, and that it doesn’t replace proper risk management:

The Framework is not a one-size-fits-all approach to managing cybersecurity risk for critical infrastructure. Organizations will continue to have unique risks – different threats, different vulnerabilities, different risk tolerances – and how they implement the practices in the Framework will vary. Organizations can determine activities that are important to critical service delivery and can prioritize investments to maximize the impact of each dollar spent. …

Along with the framework, NIST also published a roadmap outlining where it plans to take the framework from here, and US-CERT has bundled many of its cybersecurity tools and initiatives into a new Critical Infrastructure Cyber Community Voluntary Program. Good stuff!

Mapping 27001 Requirements and Controls to CSF Subcategories

One of my comments on the draft was that it provided “informative references” to (amongst others) the previous version of ISO/IEC 27001:2005, rather than to the recently published ISO/IEC 27001:2013. I was happy to see that this has been addressed in Version 1.0.

I took the liberty of reverse-engineering the mapping of CSF Subcategories to 27001 control objectives provided in the “Informative References” column of the CSF’s Framework Core. I also added 27001’s control objective statements (but not the text describing the control) for easier reference, and the “other” requirements from 27001 in the standard’s clauses 4 through 10. 

The resulting Excel spreadsheet can be used to sort requirements one way or the other, and is hopefully of use to some of you:

What follows is a bit of analysis:

24 CSF Subcategories Do Not Map to Any 27001 Control Objectives

However, ISO/IEC 27001 does not just provide a list of controls in its Annex A, just as the CSF does not simply provide a list of requirements in it’s Framework Core in Appendix A. Clauses 4 to 10 in 27001 constitute actual requirements for an organization’s information security management system in addition to the list of controls in the annex. I added a mapping of those requirements (on the lowest level of available section headers) to applicable CSF subcategories in my spreadsheet.

As a result, the remaining major areas where the CSF provides more detailed requirements than 27001 can be summarized as follows:

• The DE.AE and DE.CM categories contain more concrete controls for the monitoring of infrastructure for anomalies and other potential security events. 27001’s requirements for logging and monitoring are more generic.
• RC.CO categories provide more details about communication and PR as part of incident management than 27001’s requirements in A.16 do.
• RS.CO-5 stresses the “voluntary information sharing” with external stakeholders that is a central element of the CSF.

(When looking at the detail of requirements, though, it should be noted that ISO/IEC 27002:2013 is available to break down the normative (but short) controls from 27001’s Annex A into more detailed best-practice control activities.)

19 Control Objectives Have No Corresponding Subcategory

27001 contains a number of control objectives that are more specific than what the CSF offers, such as the requirements for a mobile device policy, acceptable use standards, regular review of access rights, provisions to be put into supplier agreements, etc. Many of them could arguably be mapped to higher level Subcategories in the CSF’s Framework Core, but are not specifically implied by any Subcategories. Curiously, this contains requirements for the documentation of how cryptographic controls are used (A.10.1.1) and how keys are managed (A.10.1.2) — a topic that is not addressed in the CSF at all.

Requirements from clauses 4 to 10 in 27001 that have no corresponding requirements in the CSF’s Framework Core mostly relate to aspects of running a well-documented (security) management system, including requirements for competent resources, clear objectives, documentation, internal audits, management reviews, and continual improvement. Some of this is, however, addressed by the four Framework Implementation Tiers loosely defined in CSF’s section 2.2 to measure an organization’s maturity in implementing the CSF categories. (As far as 27001 is concerned, besides setting a minimum baseline for a functioning management system process maturity is addressed in other standards and out of scope.)

Conclusions

The “gap analysis” of correspondence between 27001 and the CSF performed above could easily be extended to review cross-references with COBIT 5, NIST SP 800-53, etc. (Maybe the Cloud Security Alliance’s Cloud Control Matrix will pick up another column for the CSF Subcategories now?)

What the analysis really shows is mainly this: Now we have yet another set of security controls to deal with (at our disposal, is what I meant to say ;-)), mostly overlapping with those suggested by already existing standards, and with only minor specifics that make it special for critical infrastructure cybersecurity. (Although there is certainly one major advantage that the CSF has over 27001: It’s free!)

Unsurprisingly, the recommended approach for managing information security thus stays the same: Develop a risk and security management system that addresses your organization’s particular risks. Create mappings from your processes to whatever standards and frameworks you desire (or have) to demonstrate compliance to. Circle back and address any compliance/control gaps in your system.

(For 27001 and the CSF, the tools suggested by the standards for providing conformance statements are actually somewhat compatible: The CSF introduces, on a superficial level, the concept of a Framework Profile, suggesting that an organization create Current and Target Profiles outlining which of the framework’s control Categories and Subcategories have been selected based on “business drivers and a risk assessment” (pg. 5). This is somewhat similar to the concept of a Statement of Applicability (SoA) required by 27001. Neither of the standards provides a detailed outline or template for these statements, 27001 being a bit more specific about minimum contents. This presents an opportunity to align demonstration of conformance with control statements from both standards by generating a joint SoA & Current Profile. Somebody should go ahead and create a template!)

Edits:
2014-03-06: Fixed a hyperlink.