By Jack Whitsitt
Now that the NIST Cybersecurity Framework has been out in the wild for some time, it’s worth evaluating how it has begun to play out in the real world. A good place to find out was October’s 6th Framework Workshop in Tampa, FL. Industry, government, and academic representatives were out in force to talk about the Framework, how they’re using it, lessons learned, and what the next steps might be. With a mix of folks new to the process and those who have been to all of the conferences (and really did receive the T-Shirt for it), I found the conference to be genuinely positive and informative.
In particular, a panel early on presented case studies of the Framework by three different organizations, including the relatively small Silver Star Communications. They each were using the Framework in very distinct ways. One focused on enhancing existing risk management practices, another was using it to help determine their cyber-specific risk posture, and the third was working through conformance determinations. Of particular note was Silver Star, whose CFO was using historical Bond risk measures to help determine an appropriate cyber risk profile distribution. It wasn’t a perfect approach but, lacking more topical data, I thought it was creative and likely effective. It was also nice to see an actual CFO on stage talking about cybersecurity. This is where we all need to be moving.
What the real takeaway is here, though, is that each of these companies had to add their own perspectives, their own tools, and their own links to their business processes to make the most effective use of the Framework. The Framework is really a simple mode of common information security practices which also contains stubs to link it into your broader cybersecurity and business practices (such as risk management). There is nothing particularly new in it, but having a shared model of common practices allows for more standardized language while allowing individual organizations the freedom to tailor the actual use and implementation of those practices to their specific needs. The downside is that the Framework provides very limited assistance on its own for doing things like risk management, goal setting, and business integration.
Of course, this isn’t lost on NIST. They know that the Framework is meant to be (in their words) “additive”. It is meant to elevate, highlight, and communicate common practices that are already in use. It is not meant to change the state of the art or even to provide a full package view of either cyber or info security.
This “additive” nature is reflected in some of the clearly intended and (now) actual use cases. Inside of organizations, the Framework can help identify standards gaps, errors, and future work for existing Information Security programs.
When looking across organizations (and especially across the public/private partnership divide), the nature of the Framework can most easily be described as a cybersecurity flag. It is a rallying point for discussion between organizations, it provides a baseline for perspective, and the process itself has already demonstrated effectiveness at progressing old impasses that have often found themselves moving, for lack of a flag, in constant circles. At the workshop, this role of the Framework was reflected in several conversations. Chris Boyer of AT&T, for instance, said that (and this may not be a word for word quote) one of the values of the Framework has been the supply chain conversation it has created/enhanced. Separately, we heard both AGA and the Finance Industry say that the Framework is helping them to coordinate efforts across multi-sector and multi-regulatory environments. While the regulators are clearly not yet savvy on the broader business-risk driven approach advocated by the Framework (and NIST), they now clearly have a common vehicle in which those questions can be asked, answered, and discussed.
Along those lines, the Framework’s role as a “Flag” is also being seen more and more often in the insurance and contracts spaces, as we heard at the workshop. This is a pretty new space and the right balances have yet to be found (in any respect), but at least many of the insurance and contracts folks (well, the ones in attendance) seem to be well aware of the limitations of the Framework and are working to extract what value they can from it. This may not be true outside of the “choir” of folks who have been part of the discussion so far, but it’s a start.
Despite this progress as a flag, however, and the true maturation of many of the longstanding cybersecurity and information security discussions participants have been having, there are still hurdles to overcome. One of those hurdles comes in the form of “compliance as a tool for denial.” Several folks, in a number of the breakout sessions, mentioned that their executives and boards were still – despite every effort made in the language of the Framework itself – using it as a checklist. “Yes, we know that it says use risk management, but go ahead and implement all of it.” For those who really understand either information or cyber security, this is a fairly nonsensical and unsupportable position, but it’s an easy one for an outsider to have and it removes from them the responsibility of really thinking through the problem space or taking deeper action.
There are a couple of ways to solve this problem, neither of which seems to resonate with NIST as a function they should support. First, the Framework could be broken up into its component elements (Categories, Sub-Categories, etc.) and have its narrative form broken up entirely. This would force organizations to think a little bit more about what they want out of the Framework before using it. Still, elevating the visibility of the inherent complexity of doing cyber and information security “for real” may, as a side effect, reduce the willingness of the target audiences to participate.
An alternative solution would be to add additional narratives and stories about how the Framework can and should be used. Anyone who has read “The Phoenix Project” (Kim, Behr, Spafford) – a book on DevOps – will have a very clear idea of how narratives and stories can be used to broaden comprehension, increase receptiveness, and aid in effective implementation practice development.
In either case, there remains the question of responsibility. Is this something NIST should do? Is it something sectors should handle? There are any number of iterations of possibility, but NIST seems to be the only organization available who can take ownership in a sufficiently authoritative way as to keep the focus on the Framework in a way that it retains its value as a “flag” and a tool for consensus. Many sectors and organizations might feel that they can do better and more specifically handle the nuances of their environments, but that perspective is only true so far. Ultimately, there are fundamental technology and business independent truths underlying the disciplines of information and cyber security – whether or not we have managed to articulate them or not – and going too far down a sector focused approach would hinder, not help, the process which the Framework is intended to support.
Speaking of disciplines, the workforce development breakout session highlighted several interesting gaps and focus areas. Most of this (second-session) discussion centered on the need for a cybersecurity “profession” (in an engineering sense, not in a “he’s a real professional!” sense). Someone put it this way: “A plumber usually can’t work on electrical systems, an electrician usually can’t work on plumbing, but both can work on your firewall.” To some extent, that was a truly valid point. We do need mechanisms, eventually, to hold people accountable for their work. We do need standards to which to train to. But, are we mature enough in our knowledge of what works sustainably and efficiently to create those standards, to create that profession? The consensus was “no.” What seems to be missing is a scientifically informed discipline (or disciplines) on which to base professions and more technical job descriptions. Further, there are at least two distinct types of disciplines which need to be evolved: Cyber Security and Information Security. Information Security would include the common practices of building, maintaining, operating, and defending information systems. Cyber Security can be considered the creation, maintenance, and management of the environment in which Information Security practices can be sustainably, efficiently effective at achieving individual, business, sector, and national goals. In Framework terms, the discipline of “Information Security” would be concerned with the content of the Framework. The discipline of “Cyber Security” would be concerned with the development of, consensus on, and socialization of the Framework. An example used in the discussion was that someone with “security” in their job title, no matter how well trained, may be hamstrung by someone making a “risk based decision” to “accept a risk” without having any real cyber or information security knowledge.
Although the distinctions outlined here aren’t necessarily reflective of the opinions of those at the workshop, there did seem to be consensus on the need for the discipline gap to be bridged before real progress can (or should) be made on professionalization.
Generalizations aside, though, is there a specific role for the Framework in workforce development? Maybe. There are quite a few private sector, non-profit, and academic organizations, including EnergySec, looking to assist in that area, so perhaps the government does not need to take a strong role. Still, it would be nice to see a list of common “Information Security” and “Cyber Security” roles (CEO, CFO, Senior Operations Manager, Developer, User, Sales, Procurement Manager), what types of risks they can introduce into an organization, and how those risks can be managed by elements of the Framework – including a more nuanced perspective on “training” than the “basic hygiene” activities we commonly associate with “training.”
After workforce development, one of the final general sessions was given by a variety of policymakers from the U.S., the U.K., and Europe. The panel didn’t offer many new perspectives, but the European Commission representative, Aristotelis Tzafalias, had several thoughts that provided useful food for thought. First, coming from Europe, where there are more than 20 languages, he suggested that words matter, but concepts matter more. His advice was, paraphrased, that we consider whether something we are stuck on with the Framework would still be something we were stuck on if we had to translate it to those 20+ languages, or are we focusing too hard on a grammatical or syntactical artifact of the English language? For example, is the heart of the “Implement/Adopt/Conform with” discussion really a conceptual disagreement, or are we using those words to hide real underlying complexity that we have not yet directly addressed?
Tzafalias’s other, related, point was that we assume a lot about language, scope, and perspective when we talk about cyber and information security. He urged us to be aware of when we are abstracting concepts up and to be very clear, especially when so many perspectives and backgrounds are at hand, on what the underlying scopes and contexts are supporting those abstractions. This might not seem like it’s that important to Information Security, but it may be the essential component of Cyber Security. If we can’t communicate clearly, quickly, and directly, making progress on creating a sustainably efficient environment for Information Security to be effective will continue to be difficult.
In the end, though, regardless of any of the details of the Workshop or what was said, what really matters is that there is now a process – and a flag – that appears to have been successful in moving the ball forward and that may, with support, continue to be successful.
If there is one gap in the process that really resonated throughout the Workshop and which really needs a resolution it is the problem of “outreach to non-participants.” In particular, small and medium (or “low maturity”) organizations. How do we help them? How do we get them involved? How do we even reach them systematically? At EnergySec, we hope to help out where we can – we’ll be, for instance, teaching a class on the Framework and DOE’s C2M2 this year – but there needs to be a more strategic plan coming out of multi-stakeholder consensus building processes, like this one. It would be to everyone’s benefit if the next Framework Workshop NIST convenes focuses on this specific issue. For more discussions with us on the topic, follow @and @EnergySec and use the #eschat hashtag on Twitter, or email us.