This is a question on all of our minds – not just for the Framework but also cybersecurity more generally.
Executives have started to get on board, the press is paying attention, manufacturers are starting to include security in their ICS products, grass roots organizations such as I Am The Cavalry and others are forming to help to move Automotive and Medical Device security forward, the White House has issued the Executive Order, Congressional staff discusses cybersecurity regularly, and together we have created a common practice consensus "flag" with the NIST Framework, and this very forum now exists to help us collaborate more effectively.
So, how do we use this momentum to continue to move forward coherently toward sustained risk reduction?
I’ve heard a lot of good ideas here, at the 6th NIST workshop, and in many other venues about what to do next, but a lot of these ideas, thrown up into the air, fall down with no structure to catch them. There is no bigger picture into which to slot next step ideas and see how they relate to past work, need, and each other.
Without such a common reference structure, making progress from here on out will be increasingly difficult and I believe we need to learn from the very recently successful past and build a framework to do so.
The new framework I'm envisioning would, far from a "2.0" of what we've already built, have a completely different goal. Instead of collecting and organizing common solution elements into a document, this framework would identify the types of problems we face doing business in a hostile, ICT (Internet and Communication Technology) enabled world and provide a context in which to organize the existing NIST Framework solutions.
In other words, if we identify a common language and reference for the "cybersecurity problem space" - especially the areas outside of the CISO organization - it should be much easier to go back, find out where the Framework excels, where it needs help, and where it simply does not apply and, from there, allow us to organize future efforts effectively and sustainably.
Maybe we should have done this earlier, but maybe it took creating a Common Practice Framework to highlight the need to go back and create a “Problem Space Framework”. How many of us have looked at strategy documents that said things like “Will reduce cyber attacks” or “Improve Cybersecurity” and thought “But wait, what does that mean?” Shouldn’t there be goals, or non-security objectives for security to help frame, limit, and shape our efforts to some productive end?
When the executive order came out and I heard about how the NIST Framework was going to be used to support “Performance Objectives”, I thought, “Great! Finally, we’re going to have the electrical current that non-security-activity goals provide to security activities to drive them to defined, implementable, and effective ends”.
Unfortunately, that doesn’t seem to be happening and there doesn’t seem to be consensus that that was even the original intent. But that doesn’t mean we don’t still need to create that organizing current around security activities.
The “Tier” concept in the existing framework, as incomplete as it is, definitely speaks to the need for the application of a maturity model to what we’re doing, but even maturity models need to exist inside a larger context of “Why?” that is framed by all of the ways organizations – and those who work for them – introduce risk. If we don’t have a framework for risk introduction in a broad business and national context, how will we ever be able to tell ourselves, each other, our customers, or anyone else that we’ve applied the NIST Framework in some legitimately effective or helpful way?
This shouldn’t be a hard problem to solve. As with the Common Practices in the NIST Framework, we’re in a situation where a lot of different people have very different but valid views into the cybersecurity problem space. The material and knowledge exists, we just need to gather it, write it down, gain consensus, and begin to apply it.
From my own point of view, I think this begins by identifying (and documenting) how the major, common roles within organizations (and of organizations) introduce cybersecurity risk through legitimate, authorized means in the course of doing business. If we can nail this down across the entire business value chain – from Boards and CEO’s to CFO’s to Operations Managers to IT to Procurement to Sales and Marketing to HR to Industry Partners to Insurance Companies to Regulators all the way to the CISO shops that the NIST Framework already assumes solutions for – we will have a much better understanding of what we're solving for. This is because our cybersecurity risk profiles are, when it comes down to real root causes, exclusively the result of the series of decisions made by people in legitimate, authorized capacities. Whether or not the decisions are in your sphere of influence, knowing how they are influencing your cybersecurity risk profile over time is the first step in determining how to most effectively apply the controls from the existing NIST Framework. From there, that knowledge can be applied to contextualizing the maturity levels in models like the ES-C2M2 in a way that provides "Management Metrics" to those responsible for managing organizational behavior, and those maturity levels can then guide the scope, goals, metrics, and placement of those controls that exist in the NIST Framework.
Beyond the tactical benefits of the knowledge such a framework would give us, our ability to act strategically will improve. If we know how our CEOs and those who work for them are introducing risk, if we can find commonalities across organizations, then we can describe the goals, effectiveness, and mitigating controls in terms that are much less dependent on far too rapidly changing technology and external threat actors. This would provide a much more stable platform over time from which to begin doing sustainably successful risk management, maturity modeling, and NIST Framework implementation and adoption.
That said, this is just one way we might go about creating a "Problem Space Framework" - there are others. Regardless of which one we choose, I strongly believe building one will clarify, speed up, and make our way forward much more effective at reducing risks created by the use and operation of ICT's.