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.