NIST CSF 2.0: A Deeper Dive into Middle-Earth
Samuel Lewis, Senior Security Consultant at CISO Global
Sequels, bah! Usually, they are never as good as the first. Do not even speak of prequels! This is less of a sequel, and rather should be considered a continuation of the first blog. In line with the original blog, there will be a few references to Tolkien’s Lord of the Rings. So, without further ado, you have my sword, and you have my bow, and my axe, or, at the very least, some of my NIST CSF 2.0 insights.
The first blog focused on major changes. This blog focuses on smaller, less pronounced changes that still have a large impact. The first change is how NIST worded the controls in 2.0. NIST writers have, in the past, left some items up for interpretation leaving readers as befuddled as Bilbo Baggins’ guest when he announced, “I don’t know half of you half as well as I should like; and I like less than half of you half as well as you deserve” The verbiage has changed, for the better, in NIST CSF 2.0. One clear example of this is RS.MI-2. In version 1.1 the control states “incidents are mitigated.” In the newly updated version, the same control states “incidents are eradicated.” Mitigation is defined as the action of reducing the severity, seriousness, or painfulness of something. Eradication is defined as doing away with as completely as if by pulling up by the roots. This sets a much clearer expectation that incidents are to be stopped and rectified completely, although that definition of eradication may give Treebeard nightmares.
NIST has augmented many of the categories with numerous new subcategories. Much like the elvish archers who arrived to bolster the army at Helm’s Deep, reinforcing these functions offers better protection to information systems. The change that stands out, after the addition of the Govern Function, is the additions to the Recover function. Specifically, to the Incident Recovery Plan Execution (RC.RP) category. NIST has added multiple subcategories to RC.RP. What was once a vague statement of “RC.RP-1: Recovery plan is executed during or after a cybersecurity incident” is now clarified as “RC.RP-01: The recovery portion of the incident response plan is executed once initiated from the incident response process.” There are five newly added subcategories of RC.RP-02 through RC.RP-06. These newly added subcategories ensure that the recovery actions are clearly defined through recovery scoping, backup integrity verification, critical mission functionality, system integrity verification, and ending the incident recovery based on preestablished criteria. Recovery has been changed from a nebulous requirement to a clearly defined set of expectations that can be tailored to meet an enterprise’s needs.
The Govern Function was discussed in the previous blog (linked above) but since this is a deeper dive, the focus will be on the Cybersecurity Supply Chain Risk Management (GV.SC) category. In Middle-Earth, the vetting processes are, well, less than ideal. The Ents once conferred for three days before establishing that Merry and Pippin were not Orcs. Gollum, well, he was the epitome of not being properly vetted and ended up costing Frodo a finger. [Sorry for the spoiler!] How does all this compare to cybersecurity supply chain risk management (C-SCRM)? By thinking of C-SCRM as just hardware and data, we are overlooking the leading cause of data loss — the human element. Much like the Ents, an enterprise needs to take time to vet potential vendors, service providers, and all other entities that will have physical and/or logical access to anything deemed important. This could, and sometimes does, range from janitorial staff to engineers. Cybersecurity best practices and CSF 2.0 state that: an enterprise needs documented and agreed upon policies and processes; roles and responsibilities documented for suppliers, customers, and partners; integrate C-SCRM into enterprise risk management; document and prioritize suppliers; include cybersecurity expectations in contractual documents; assess all third-party relationships from both a cybersecurity and an enterprise risk perspective; document all risks posed by a supplier; integration of supply chain security practices, incident response, and incident recovery plans must include relevant third parties; and finally, when the time comes, ensure that enterprise C-SCRM plans have documented conclusions of the partnership.
Even with this deeper dive, the surface is barely scratched. There are so many items that could be discussed and expanded upon. These were just a few examples of other changes introduced with NIST’s CSF 2.0. The ever-evolving security landscape means there will always be room for improvement in the cybersecurity framework. Gandalf said it best when he stated, “For even the very wise cannot see all ends.” While some elements of CSF 2.0 may currently require customization for individual organizations, and just as journeys often result in the discovery of new items, most likely there are best practices still waiting to be discovered.
“End? No, the journey doesn’t end here.” ~ Gandalf Need help navigating NIST CSF 2.0? Reach out to us for guidance.
About the Author
Sam Lewis is a Senior Security Consultant at CISO Global with a long history of keeping things secure. While serving as a U.S. Marine, and later in the Army National Guard, Sam gained experience in electronic warfare/military intelligence systems integration, maintenance, and systems administration on multiple systems. But his interest in cybersecurity sparked in 2008, when learning about encryption standards while working with NORAD, as part of the Joint Air Defense Operations Center. Sam is a Certified Information Systems Security Professional (CISSP) and holds a Master of Science in Cybersecurity from Southern New Hampshire University.