Unrealistic Security Expectations - part 1
A frequent issue I have with some blog posts, articles and tweets from my security colleagues is how frequently they rely on unrealistic expectations. From the down-to-earth guy to the curmudgeon, it seems that all our field suffers from a collective illusion that executives will be reasonable when deciding about risk postures, people will willingly comply to security policies or architecture end states will one day be achieved. If we want to really improve security and produce sensible results, it’s time for us to wake up to reality and deal with security without unrealistic expectations.
I won’t write about the human component of these expectations, about risk related decisions and users behavior. At least on this subject I believe we’ve been seeing some ideas and people realizing we cannot expect behaviors to change and people to be conscious about security. For those who still don’t believe that go google “candy bar password”, just to mention one of the many studies that show how poor are our decisions regarding security. My main concern is about the technology landscape within the organizations and assumptions related to it made by security professionals. I just can’t help being surprised on how naïve my peers can be about how their networks will look like in the future.
It’s easier to explain what I’m talking about with an example; Back in distant 2004 I was discussing with the Wintel support team of the company I used to work for what should be done regarding Windows NT 4 servers, since the security patches wouldn’t be available anymore after the end of that year. At one point in the discussion there was a general perception that the risk from having those servers in our network wouldn’t be that high, as the plan was to eventually have everything migrated to Windows 2000. When I left that company, a few years later, those servers were still around. Since then I’ve seen the same thing going on over and over again, in organizations of different sizes, countries and businesses.
IT changes are almost never implemented as “Big Bang” projects. There is always a phased approach. Paretto is always being applied, 80% of the bad stuff being removed fairly soon and the remaining stays around for a long time. An isolated situation like that wouldn’t be an issue, but in medium and large organizations we can see dozens of cases of older, unsupported, often unsecure technology, configurations, processes, just refusing to go away. That’s the nature of things and I can’t see that changing soon. The problem is how to build security in that reality. It’s just too common to see great security ideas failing to provide results because they depend on clean, stable environments. That was always the case for the Identity Management projects (“oh, those identity repositories will be retired soon, don’t worry about those”), Log Management (“the new version that we’ll implement soon supports syslog-ng”), DLP and others. The security architects are developing solutions that depend on perfect scenarios, scenarios that will never become reality. That’s how most of the security technology deployments fail.
Here’s what we need to do to change: design your security solutions to work with REAL environments. Assume that things will fail, will not be as expected. Security solutions should be resilient to those environments, simply because that’s how our networks look like. I don’t like it, I would really love to have those perfect CMDBs available, all servers available to aggressive patching, all networks supporting 100% traffic capture for monitoring purposes. But that’s just not truth.
It’s not just “design for failure”. It’s design around failure. Your network is a mess and it will always be like that, deal with it.
In the next part I’ll expand on the unrealistic expectations for policies and standards. Meanwhile, let me know what are the unrealistic expectations you see in security and how you think we should deal with them!