So, I’ve recently written up two separate pieces talking about Business Security, Frameworks, Cybersecurity. One is for <UNDISCLOSED>, the other is for CForum (hey, I was the next highlighted blog post after Ron Gula’s!). Let me know what you think of them, they’re below. (Also, two posts more directly about the new NIST Framework and the DHS Voluntary Program are HERE and HERE)
SCOPING FRAMEWORK USE
Cybersecurity is, broadly, the enablement of an environment in which business objectives are sustainably achievable in the face of continuous risk resulting from the use of cyber systems.
The risks from using cyber systems usually take the form of actors desiring to use those systems as a means of repurposing business value chains to alter the value produced, inhibit the value produced, or producing new value in support of actor objectives.
Managing these risks involves two focus areas:
- Creating a business environment which limits the window of opportunity provided to actors in which to achieve their objectives
- Executing a security-specific program that is able to identify, mitigate, and respond to actor activity which is occurs within the remaining window of opportunity.
Leaving the business environment unmanaged provides a large continuous window of opportunity which is, at best, not cost effective for security-specific programs to effectively respond to. At worst, the window of opportunity created by an unmanaged business environment leaves the window of opportunity too wide for security-specific programs to protect, even with excessive financial investment.
On the other hand, no organization can manage its business environment and reduces actor opportunities sufficiently to remove the need for security-specific programs.
Both focus areas must be addressed for sustainable, effective, cost-limited cybersecurity and the NIST Framework can help with both.
Cybersecurity Frameworks, generically may provide business value to an organization in three ways:
- Scope and Completeness Assessment
- Coverage Validation
- Efficacy Testing
In the case of security-specific programs, the NIST Framework can be used directly as a positive model for determining program scope and completeness, it can (using the tier model) be augmented with additional information to assist with security program coverage validation, and it can play a role within a larger model in testing efficacy of security program efforts.
Within the business environment focus area, the NIST Framework can also play a supporting role as a negative model to help determine areas which must be better controlled by the business before security-specific programs can effectively manage residual cybersecurity risk flowing down from that environment.
While XYZ is focusing specifically on the former, security-program specific, focus area, its resulting efforts can, with forethought, go a long way to providing a foundation for the less-well explored area of cybersecurity risk reduction through business environment management and lead us toward the kind of comprehensive cybersecurity risk management approaches that will, over time, reduce our risk across organizations, the sector, and the nation sustainably, cost effectively, and independent of increases in complexity and changes in actor behavior.
FRAMING THE FUTURE (From CForum)
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 problemswe 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.