Yesterday, I threw down my soap box into another discussion of ways to rearchitect the internet – specifically the pieces supporting critical infrastructure. It was, as usual, about technical solutions to large scale, enterprise security problems. It was a bit of a stretch for me to bring this up in that particular thread, but I think it’s important to beat the drums on this subject wherever possible:
The “security” problems we’re having nationally and globally aren’t technical. They’re not even security problems, really; they’re failures of management. In fact, they’re very similar failures to those leading up to and causing the current economic mess. Any technical discussion is really putting the cart before the horse.
For example, I was recently on a con-call recently where a bunch of people at a large enterprise were trying to track down (to keep it generic) “Secure Devices” they’d purchased. Absolutely no one knew where they all were, who owned them, how many there were, whether they worked or not, how they were configured, etc. Some groups knew theirs, others didn’t. In some cases, there was duplication of effort. In others, worse still, there was conflict of effort. How can this environment possibly result in “security”?
This kind of management mess is the primary contributor to the failure of cyber security – CIKR or otherwise, not technical problems.
Why do I believe this? I started out doing network security analysis. I was really good at it, but couldn’t do it nearly well enough because the tools seemed to suck. So, I started designing better tools to do things in ways that had never been done before. But then I found that even with better tools, I still couldn’t provide a good basis for analysis because I didn’t know anything about the organization I was “securing”. Once I figured that out I went to try and get the business leaders to provide that information to their security team and I found that the information had never been collected and no one seemed to see the value in doing so. That’s how I ended up (in short) with the perspective I have today. It’s based in a sequence of layered steps that I know are solid – I only wish I could do a better job of communicating the dependencies here.
The conceptual failure seems to be the belief that technical risk remediation is a sane strategic end-goal. It’s not. There will always be technical vulnerabilities and failures of design – that’s a given. You can fix these individually, but that’s a tactic not a strategy. There is no end game or any way to get ahead of the curve.
Instead, we lack and should pursue national business, social, and government consensus on solid plans to:
- Assess current environments and keep those assessments up to date,
- Do interdependency analysis,
- Plot those against business risk (individual organizations, nationally, etc.)
- Measure performance and success in terms of business needs supported
Not to mention consensus on “communication” (which is probably even more important) like: who should be at the table for these things, how communication happens and with who, etc. You get the idea.
These are all deficits that are completely independent of the technical architecture of our infrastructure. Filling them would get us a long way down the road to solving our security problems in our current environments
We have a habit, in the cyber world, of consistently making changes without sober scientific evaluations of cause+effect and it bites back every time. And, until we start getting better at the above named activities, we can’t do that evaluation in any way that will guarantee successful solutions. (I recognize that there are many, many good initiatives going on in these areas…but so far, they still seem disjointed and lacking enough universal consensus to solve the problem.)
Maybe some of these technical suggestions for rearchitecting the internet will work. Who knows? We don’t even have consensus on where, why, or how our current technology fails or where it succeeds. How can we claim to know what will fix it? Technical solutions to security problems without business context will only ever, at best, be hail mary’s and misguided hope.
Now to get a little more ranty (smile):
I really fear what is happening…which is calls for large scale, quick change without even the most fundamental management practices in place. (eg, business architecture).
What is going to happen is we’re going to invest a lot of time, money, and effort in investing in technical re-engineering and we’re STILL going to get trampled on by malicious actors…except we’ll be billions of dollars more in the hole. I think that merits being called out as often as possible. What do you think?
The government and large enterprises get compromised constantly and -at will-. The whole mess from top to bottom, public and private, is absolutely fubar’d. This is public knowledge – it ends up in CNN regularly. Yet, our management processes are SO bad, that even ending up on mainstream news does not force real change. Failing FISMA does not force real change. There is NO visibility from cyber technology to management to business leaders to business risk. There are exceptions, but this is the rule. So you dont have the visibility to make the needed changes. Not only that, but without the data gathered by these management processes, security controls cannot ever be effectively placed, configured, or run. We will lose, no matter what technology we put in place without these management practices. There is no question.
Technical solutions may work, but that’s like putting a finger in the dam. Unless there is a framework to consistently identify and correlate environment, requirements, risk, technology, operational processes, controls will eventually fail because the enterprise (national, private, whatever) cannot respond to evolving threats. Spend the money up front to put in strong security practices, though, and the rest will follow.
Even then, we can’t possibly identify all the inter-dependencies and requirements needed to make large changes move without going through exactly the kind of process and management methodology I’m referring to anyway. Just to put the cart before the horse requires the horse be in the front. (Does that even make sense? heh.)