Unless you were off-planet last week, you've probably heard about President Obama's latest Executive Order, directing various agencies to step up their game on "critical infrastructure" cyber security. As part of this directive, NIST will be building a new framework oriented toward critical infrastructure that will help document processes, standards, best practices, etc, etc, etc. Gah!
The 1980s called and they want their lousy idea back. The 1990s also called, but they just repeated the prior point. The 2000s called and said "What is this, the '80s?!"
If frameworks were going to get the job done, then the job would be done. If securing data and operations was really such a simple task, then we would not be having this conversation, nor would we be reading reports, like Mandiant's big "APT1" blow-out from yesterday (you know, the big shocker that revealed that China is, in fact, hacking everyone... ok, not a shocker... or even really news... since we pretty much already know all that, right?).
Here are three (3) major problems with the President's proposed direction
1) Frameworks and "best practices" don't work.
This point doesn't even need explanation (I hope). Well, it does, but to an audience that's almost certainly not reading this blog. Plus, if I were explaining this to a politician, it would use a much different language construct and context. Instead, as proof, allow me just to point out:
- FISMA mandates this approach, and yet the USG is pwnd (hard).
- PCI mandates this approach, and yet companies still have been breached (big time).
- The NSA has abandoned the illusion that a framework alone will save them, and operate under an "always breached" assumption, changing their practices accordingly.
2) The mandated approach is too "old school."
I'll be writing more about this overall topic soon (probably post-RSA), but in a nutshell you have these contexts:
"old school" - based on frameworks, "best practices," putting resources in silos, not aligning IT to the business, not doing risk management
"new school" - risk-based approach, generating metrics and data to support good decisions, but still typically putting resources in silos, and often failing to align to business priorities and objectives
"DevOps style" - the future (I believe) for all IT, security, development, etc... starts from business objectives, recognizing that IT is a fundamental competency for all businesses... then incorporating a reasonable risk management approach that aligns business values to operational risks (which are disproportionately influenced by IT risk)... streamlining dev and ops and security... loosely coupled, highly aligned... responsibility is key... as is continuous testing of failure modes... fail fast, evolve faster...
Of these approaches, a framework and the use of the phrase "best practices" firmly puts this directive into the "old school" category. It's regressive, and it will only serve to make life more difficult for businesses without "solving" whatever "problem" they think needs addressing. It would be far better if they would simply revise negligence and liability laws so that businesses and executives were on the hook (financially and criminally) for the results of making bad decisions around how to protect their IT environments. For that matter, I could even see levying fines (or even declaring a firm an "accomplice" to a crime) for allowing their resources to be compromised for an unreasonably long period of time, such as having servers and workstations rolled-up into a botnet of some sort.
3) Time is of the essence.
Even if a framework were a good idea, there's no way one will be completed through the government bureaucracy in a timeframe that is even remotely reasonable. DOE was able to slam out a couple draft initiatives last year in short order (ES-C2M2 and RMP), but this is the exception, not the rule. More importantly, those were pilot initiatives that were more representative than anything. Yes, they're being used, but the value and impact is yet to be understood (or clearly documented/stated).
IF businesses were serious about critical infrastructure protection, then they would already be making sweeping changes. Unfortunately, it seems clear that either IT risk isn't being adequately factored into operational risk analyses, OR... maybe the asserted risk levels really aren't there. In either case, what is clear is that these businesses have not been properly incentivized to make necessary changes (likely due to a fundamental human resistance to change - humans only change if they want to or they're forced to do so due to trauma).
Whatever the reasons, what's clear here is that a) a meaningful framework will almost certainly take a year or more to write and enact, and b) it's impact will be negligible at best unless there are major legal penalties for failing to change. If the US Government really wanted to get the ball moving here, then they would put in massive penalties (monetary and criminal) and give businesses 90 days to show a plan AND progress. Failing that, pull the trigger to demonstrate the seriousness of the situation. The alternative is waiting for a traumatic event to naturally occur, which is something we likely can't afford to wait on. Instead, it seems far preferable to inflict a bit of trauma to shock the recalcitrant out of their staid ways.
---
Suffice to say... it's 2013... and a framework is the wrong approach. We don't need politicians to tell us how to ensure the confidentiality, integrity, or availability of systems and data. There are plenty of known practices and well-established technologies to significantly improve the state of things. Unfortunately, the incentives are not there... yet. Unbalance the equation, though, and I think we'll very quickly see people sitting up, taking notice, and instituting reform... or so one can hope.
Ben - while you're correct in almost all of your general assertions, the pieces of context you are missing are that of the dialogue around the EO in the background leading up to its release and the public messaging from the government since. Starting with the "standards" described, the framework to be developed by industry and facilitated by NIST (I'm making the distinction intentionally here, is it is one that has been explicitly made) is one focused on the use of the word that implies interoperability and harmonization. not performance (ie used in the sense that USB is a standard, not a fire code). Further, framework will be more driven by the "DevOps" future style that you describe (this can be found in most of the post-release messaging from NIST, the WH, and DHS as well as in the work leading up to the EO) For instance, the definition of "critical infrastructure" (within each of the sectors) will be defined by isolating critical business functions and value chains, looking at how cyber systems support them, and then looking for potential catastrophic impact. While this is a difficult cultural shift to make - esp in an org the size of the fed gov - and may not go far enough, it is still a shift that's begun.
Hi Jack,
Thanks for the comment. I've read the context information that's been provided by various agencies and agents, and I'm not persuaded (in the least) by your argument. The risk management references you mention do not, to me, reflect a DevOps style, but rather largely echo the same tune we've been hearing for years now on a standard risk management style. Mind you, this is probably "new school" (vs "old school") risk management, but it's still far short of DevOps, which isn't just about better risk management.
That said, I again stick with the original assertion, which is that we do not need a framework (from the Government, especially) to articulate any of this. It serves no purpose, and it doesn't change the incentives at all. More importantly, though, is that we (and, by "we," I really mean the feds and politicians) really need to get away from this false belief that the government can or should be leading the way on any of this. They are *not* the best qualified, and in many cases they aren't even minimally qualified. Case-in-point, you say they're pursuing a DevOps-styled approach... if that were true, wouldn't the first call be to Gene Kim, whom you would then trot right out in front of a press conference and say "Here's a highly successful entrepreneur and innovator, and he is leading our initiative!"? I've not seen that happen, and I will be sure to ask him about it when I see him, but I sadly find your assertion lacking merit as such.
The politicians driving this policy might have the best of intentions, but they are perennially behind the curve, and simply are not the right people to be leading any of these efforts. Government should legislate by objectives, modifying the incentive schemes as necessary and appropriate. They should *not* be trying to tell businesses /how/ to operate. Period. End of story.
cheers,
-ben