Read Part One All Infrastructure and the NIST Framework. In this series I will take a close look at the Framework for Improving Critical Infrastructure Cybersecurity which NIST first published in February of 2014.
Is that news? No, of course it isn’t. In fact, deterrence (fear) may seem like an odd concept for cybersecurity. Arguably, except for highly visible physical access controls, virtually all other cybersecurity controls are designed to keep an incident from happening (i.e. protective/preventive) or detect and then respond/recover when it has.
A guard with a gun. That’s deterrence. An armed guard standing next to a metal detector between the thief and the elevators to your office may convince the thief to try the building down the street. But as anyone who has looked at the logs of what hits an external facing firewall on a daily basis knows, “they” never stop trying to get past that wall and “they” are not deterred just because you have a good, well managed firewall installed. So, deterring attackers is not at the forefront of cybersecurity efforts.
Individual controls can be described as protective, detective and/or responsive. A framework itself, however, should serve some other purpose. Deterrence would be really great. Imagine putting a seal on your web site saying you were “protected by the NIST Cybersecurity Framework” and having that keep hackers away.
But it doesn’t work that way. As Frank O’Hara pointed out in 1961:
If someone’s chasing you down the street with a knife you just run, you don’t turn around and shout, “Give it up! I was a track star for Mineola Prep.”
You can implement every control in a framework without implementing the framework itself. So, if implementing the framework is not a deterrent, then what justifies the overhead of putting a framework in place?
There is definitely overhead in implementing a framework. The example that the NIST framework provides of using the framework (section 3.2) lists 7 steps. Each requires resources.
1.Prioritize and Scope.
2.Orient.
3.Create a Current Profile.
4.Conduct a Risk Assessment.
5.Create a Target Profile.
6.Determine, Analyze, and Prioritize Gaps.
7.Implement Action Plan.
Other methodologies limit themselves to 4, 6 and 7. This is either because the framework is “baked” into a regulation that tries to not be too proscriptive (i.e., the HIPAA Security Rule) or because controls are listed separately from implementation (PCI DSS is mostly that).
Some organizations will outsource step 6 (and the entity they outsource to will either implicitly or explicitly perform step 4). Once they have a list of prioritized gaps, the organization sometimes appoints a project manager as their CISO to carry out step 7 (I vehemently argue against this approach in an earlier Security Current article: No Book to Be By).
We will look at the specific 7 steps in a later article. Here, let’s concentrate on why do we need a framework (and briefly why this one?) and what is a framework anyway?
Here are the short answers followed by some explanations:
Why do we need one? We need a framework to win arguments and answer specific questions.
Why do we need this one? There’ll be a more substantive answer at the conclusion of this series. For now, here’s a brief, if superficial one: the President said we had to have it and made supporting it “voluntary” (Section 8. Executive Order 13636, “Improving Critical Infrastructure Cybersecurity,” issued on February 12, 2013).
What is a framework? We don’t know but we know one when we see one.
Why do we need a framework?
I. To win arguments
Anyone who leads a cybersecurity effort at an organization is familiar with the two most common types of resistance to their efforts that are not directly related to budget: “it will impact performance/service delivery” and “show me where it says we have to do that.”
I have had large application vendors tell me they cannot encrypt sensitive, regulated, personal data because it will make performance unacceptable. When asked for any measurement to back up that claim, they demur. When asked how fast a CPU would need to be to compensate for this encryption caused “performance hit,” they explain they do not have that level of detail.
The CISO’s push back to the “performance hit” argument against security controls is to reduce it to real measurement. The “performance hit” argument gets validated or debunked pretty quickly in the face of data.
The same argument for encryption holds true when there are “performance hit” arguments against process changes, logging, filtering and monitoring. The successful CISO answers those with patience and with reliance on actual metrics.
But the “show me where it says we have to do that” argument against a security control is a bit trickier to respond to. With the exception of specific regulatory requirements, mapping a detailed control to a standard usually takes some explanation, research and collecting standards from various sources.
The NIST Cybersecurity Framework describes its role in making sense of this as follows:
The Framework relies on a variety of existing standards, guidelines, and practices to enable critical infrastructure providers to achieve resilience. By relying on those global standards, guidelines, and practices developed, managed, and updated by industry, the tools and methods available to achieve the Framework outcomes will scale across borders, acknowledge the global nature of cybersecurity risks, and evolve with technological advances and business requirements. (NIST Cybersecurity Framework, page 4)
Without a framework to help out, mapping a whole collection of controls to “a variety of existing standards, guidelines, and practices” would be a nightmare/quagmire.
And it is not just the CISO that needs help responding to the “show me” argument. CISO’s have allies in an organization these days. Supportive executives and managers outside of the security organization are most effective at helping the CISO when they have external validation to back them up.
These partners in building a security aware culture are often general counsel and facility managers, but they can also be board members, executives and managers that have thought through the risks and want to avoid them. They want to support the CISO. They do not want to get “that phone call” notifying them of a breach. They need help.
They find themselves in meetings being asked why we need to spend money and/or change the way “we’ve always done things” and it is best if not every justification comes down to a mixture of “because the CISO said so” and “we don’t want to be the next headline.”
Frameworks serve as an effective document to structure the argument. Those who might resist the implementation of a particular security standard find it difficult to argue against the idea being thorough. It is useful to have an externally validated document to work from in justifying the program. The NIST framework is that kind of document.
To put it another way: in an organization that accepts the mission of security, a thorough, externally vetted approach such as the NIST framework is hard to argue against.
II. To answer specific questions
One question a framework answers is “can you show me where it says we have to do that?” — that question is usually asked as an argumentative challenge by someone resistant to a security control. The next question a framework helps you answer, however, is usually asked more from a sincere desire to know the answer. Executives and Boards are asking this question with increased regularity.
That harder question is “are we secure?”
Security personnel at all levels stumble on this one all the time. Answering “no” is a tempting mistake—after all, if you say “yes” then you risk looking wrong if your organization is breached. Answering “it depends on what you mean by secure?” is at best career limiting and at worst will be seen as a passive aggressive equivalent of “talk to the hand”. You need something else.
You can tell the story that Gregory of Tours told in the 6th century. The fortress of Vitry was secure. King Theuderic wanted to defeat the nobleman Munderic, who was barricaded inside it. But no one could breach the walls. So the King just had someone promise Munderic that they would not kill him if he came out. And just like a too-trusting user clicking on a malicious link that makes unrealistic promises, Munderic came out and was promptly killed.
Perhaps the best answer to the question “are we secure” is this: “we can measure how comprehensive and responsive our security program is but security is like health, you do what you can to maintain it but you are still at risk for incidents despite your best efforts.”
You cannot give that answer, however, if you are not prepared to provide a comprehensive framework against which to measure what you’re doing. In fact, as we will see in the next article, this is where the NIST framework steps 1, 2 and 3 are the most valuable.
What is a framework anyway?
Look up the word “dictionary” in a dictionary and you will find something more than the phrase “you’re looking at it.” But look for a definition of a framework among the NIST world and you will be hard pressed to find much more than that.
In the NISTIR 7298 Revision 2 Glossary of Key Information Security Terms (2013) we find only one definition of one particular type of framework:
Risk Management Framework – A structured approach used to oversee and manage risk for an enterprise.
Like many of the definitions in NIST’s glossary, that definition originates from the Committee on National Security Systems National Information Assurance (IA) Glossary (CNSS Instruction No. 4009, 26 April 2010). The word “framework” is not itself defined.
Is that all a framework is: a “structured approach”?
In the Executive Order of 2013, the President and his advisors came close to a functional definition of the framework they expected:
The Cybersecurity Framework shall focus on identifying cross-sector security standards and guidelines applicable to critical infrastructure. The Cybersecurity Framework will also identify areas for improvement that should be addressed through future collaboration with particular sectors and standards-developing organizations. To enable technical innovation and account for organizational differences, the Cybersecurity Framework will provide guidance that is technology neutral and that enables critical infrastructure sectors to benefit from a competitive market for products and services that meet the standards, methodologies, procedures, and processes developed to address cyber risks.
A framework is, in fact, more than a structured approach. It is the structure itself. A conceptual framework is, as its physical counterparts are to components, a way to arrange a set of ideas in such a manner so as to clearly describe their relationships. In the next article, we’ll look at how the NIST framework, by introducing “tiers” and “profiles” has created a comprehensive set of relationships and how those can be used as the central tool in securing the enterprise.