The new version of the federal Cybersecurity Framework being drafted at the National Institute of Standards and Technology will be “backwards compatible,” a workshop at the agency’s Gaithersburg, Maryland, headquarters was told Tuesday.
It means organizations already using version 1.0 will be able to seamlessly adopt the new draft, NIST’s Matthew Barrett told attendees.
As a result, he said, there would be less flexibility to tinker with the higher level concepts in the framework, like the five key functions that make up its core: identify, protect, detect, respond and recover. But each function is divided and subdivided and there’s more flexibility to add or delete concepts at those levels, Barrett explained.
Adding or removing is fine, but “moving items to a different place in the conceptual framework” will break most implementations, he said, because companies or other organizations using it will have aligned their business processes with the structure in 1.0.
Nonetheless, attendees of the workshop session — at which Barrett introduced the first draft of version 1.1 and discussed some of the feedback the agency already got from industry and cybersecurity practitioners — heard that some pretty high-level questions would be discussed as part of the drafting process.
One of them, said Barrett, was “should we eliminate the phrase ‘critical infrastructure’ [from the title] to reflect the broader applicability” it now has? he asked.
The document is formally titled Framework for Improving Critical Infrastructure Cybersecurity, but is widely used beyond the 16 industry sectors that the government deems “critical.”
Barrett highlighted several other issues that had received a lot of feedback, including identity management.
“This is daunting but it’s also really important,” he said, noting that the key question was about whether to specifically refer to multi-factor authentication. “Should it be mentioned, should it not?” he said.
Other concerns: whether NIST was trying to cram too many changes in, and whether there should be one more draft before a final version is issued.
Barrett joked about the most controversial proposed change — the addition of a section on measuring cybersecurity outcomes.
“Measurement!” Barrett exclaimed, “Holy Cow! Measurement!” NIST got “A lot of feedback” on that topic, he said. “Certainly many deem it very important.”
Earlier, Marilyn Zigmund Luke, the vice president for special projects at America’s Health Insurance Plans — the trade association for health insurers —echoed the concerns of many business leaders that the use of metrics could become a one-size-fits-all approach.
“The only thing we would caution against is focusing so much on metrics that that somehow becomes the main focus of cybersecurity,” she said. “Metrics are useful for internal implementation, but fixating on them” is not a good idea.
Cybersecurity is “a highly evolving and somewhat volatile area to slap some metrics into,” she said, adding that framework needed to maintain flexibility.
“What we’ve learned from implementing the HIPAA security rule is that companies know their own environments best. … The metrics for one organization may be quite different from the metrics for another organization. … Each company is unique and so setting up a process where you have a standard set of metrics” would not be the best way forward, she said.
“We definitely support not only the current revisions, we look forward to working with NIST, providing them with any assistance or information they need,” in the future, she concluded.
Barrett said drafters had not been “clear enough in our language that we meant the section to be [used] for self-assessment.”
Many business groups had complained that the section could turn into a de-facto cybersecurity score that would have to be shared with regulators and investors — or worse, the general public. This would taint the framework’s risk-based foundation in favor of a compliance mentality where companies would tick the boxes needed to get the best score, but not actually think about how to defend their networks from real, adaptive attackers.
“We have to avoid the compliance-based reading of a risk-based document,” said Barrett.