Over the last few months I’ve come to the conclusion that we’re doing security wrong. Not the day to day details, though we’ve gotten a lot of that wrong as well. I mean we’ve gotten the big picture issues wrong, we’ve made a number of false assumptions about how we should be protecting our enterprises. We’re building the very concepts we rely upon to develop products, services and systems from on shaky ground. If you don’t agree, just look around at the ease which hackers are tearing through the defenses of even the largest merchants (Sony) and you have to admit that something isn’t working like it should be. You can blame businesses for not giving us the resources we need, you can blame a shortage in decent security professionals or you can do some self examination and realize that maybe security best practices and compliance efforts just aren’t working.
When I say we’re doing it wrong, I’m thinking at a more basic level than some of the common fallacies we run into every day. We all know that ‘firewalls are a security device’ is wrong; they’re just a complex traffic management device and don’t do much more than filter traffic on the grossest level in most cases. And that’s assuming they’ve been set up correctly, which too many aren’t. When was the last time you saw good egress rules? Or the fact that a number of studies have shown that antivirus commonly doesn’t catch more than 70% of all viruses and the number is falling. These are both assumptions that executives and non-security professionals make, but most of us in the community know that firewalls and AV are just things we put in because the business has come to think of them as the expected minimums.
But the flaws I’m looking for go deeper than the fallacies of firewall and antivirus effectiveness. I’m not looking for the nuts and bolts assumptions that we make to work on a day in and day out basis. I’m trying to examine the deeper assumptions, the ones that we’ve built our entire philosophy of security upon. In a different context we my call this our morality or religion, which might not be a horrible comparison. I’m looking to see what are some of the most basic truths we’ve decided for ourselves and what are the errors we’ve made because we’ve built these up from lessons taught to us by others. Were these assumptions once valid, did they once have a grain of truth or were they merely the most basic and easy rules to put in place because they hadn’t been tested before. And just as with religious or moral beliefs, to few of us ever take them out of the back of our mind to re-examine the assumptions and see if they still hold up as well to our adulthood as they did to our childhood. The security assumptions that might have served you well when you were an IDS or firewall administrator may not translate well to a later point in your career, and in fact may cause damage to your reputation.
It’s never easy to change the core of your belief system. I only know a few people who consciously make a habit of doing it on an annual basis and even fewer who live their lives in a constant state of re-examination. It’s a powerful tool to be able to look at your worldview, understand that you’ve made some mistakes and adjust to the new realities of how that affects the way you interact with the world. But it’s painful sometimes, and the change can be difficult.
So enough of the philosophical BS, what are the fundamental flaws in security reasoning that I’ve identified? I’ll be honest, there’s only one I’ve identified and mulled over to the point that I’m ready to share. We, security professionals have taken it upon ourselves to be responsible for all risk in the corporate environment. We started by placing the firewalls around the outside of the network and as more and more complexity was added into the IT infrastructure, we took on more and more of the risk into our philosophy, without really stopping to consider if we are the ones who are responsible for the vulnerabilities and misconfigurations that spawn much of the risk in our environments. We’ve only rarely been given, or fought for, the authority to make changes in the products and systems that introduce risk, we are all to often nothing more than a speed bump in the corporate culture and a scapegoat for compromises when they happen. “Why didn’t you protect us? It’s your fault this happened!” But if we had little or no ability to change the underlying systems that led to the compromise, why are we considered responsible? Responsibility without the authority to affect change is the surest route to being a scapegoat in the best of situations.
So why have we accepted this risk responsibility without having any authority? Because that’s how most of us have been taught to do security. It’s not only our duty to identify risks and explain them to the business, it’s our duty as security professionals to shoulder that risk and do what needs to be done. Despite the fact that we can’t change the underlying problems that introduce the risk. Despite the fact that all too often we don’t have the manpower to deal with the problems we already have. Despite the fact that we’re not given the budget we need to reduce the risks that existed in the enterprise before some new project introduced even more risk into our overstressed environment.
So if we’re not responsible for the risk in the enterprise, who is? In a perfect world, the people who introduce the risks should also be the ones responsible for it. Is the marketing department requiring a new feature on the company web site that also opens up the corporation to a partner? Then they should be the ones who’s finances bear the burden of paying for the additional monitoring costs. The development department is doing the programing for the corporate web site, so why is the security department being held responsible when a SQL injection attack not only takes down the site but also discloses a million customer records? If a proper SDLC had been implemented, if tools for testing the software, if internal training had taken place, the SQL injection should never have happened. Yes, we can be responsible for adding a layer of protection beyond that, but it’s the development team that should be taking the responsibility, since they’re the team that actually had the authority to make changes and prevent the risk from being placed in the environment in the first place. We need to stop being the sin eaters of the corporate world, absolving all other departments of their responsibility for the risk to the corporation they introduce on a daily basis. We need to push back and put the onus of dealing with risks and vulnerability on the shoulders of the people who are closest to the problem.
The fundamental flaw in security thinking is that we can effectively combat the risk for the entire company. We can’t. We have to advise and point out where new or existing risks are, but it’s impossible for the security team within an organization to deal with every single potential vulnerability and we shouldn’t even be trying. We need to make a change to the way we think about security and start pushing that responsibility back on the people who can actually affect change. It’s amazing how many requirements turn into ‘nice to have’ or ‘we don’t really need that’ when the department asking has to shoulder the responsibility.
There’s no quick fix, I think this is something that needs to be a ‘generational’ change in security. One of the first things that was brought up when I floated this idea amongst my peers is that we can’t just barge into the corporation and force a new way of thinking on corporations. And that’s true, we will never be able to make an overnight change to the way other business units perceive us and we can’t be militant in pushing other parts of the organization to take responsibility for their actions. It will be an unpopular path to take, since no one wants to take back responsibility once it’s been offloaded. But it’s imperative we start down this path, because this isn’t a problem that’s going to go away, and as more and more compromises happen, we’re only going to be blamed more for issues we had no authority to change. We have to change the way we approach risk in the enterprise and slowly educate our businesses about where the responsibility for risk really sits.
There are a number of people who I think are already aware of this fundamental flaw in security thinking. Andy Ellis over at Akamai, Rafal Los at HP and a number of senior security professionals understand that we can’t take the responsibility for all risk and are pushing it back to the proper departments. This isn’t to say they’re blocking progress, but that they’re telling the departments, “If this is what you need, we will show you the risks involved. But you will sign off on those risks and accept that if something goes wrong, it’s not the security department who will take the blame.” Rafal gave a great talk on this recently at BSides Detroit, and my conversations with him subsequently were a large part of the impetus for this post.
Start by changing your own way of thinking about acceptance of risk. Push back gently at first, but push back. Even if you’re unable to get a written statement saying that others take responsibility for the risk they’re creating, bring it up in meetings and stop just accepting it for them. Talk to your legal department, make sure the corporate council knows when there’s a risk you think will put the company in danger. Start cultivating relationships higher in the organization and changing the way other people think about security. Because as long as we continue to take responsibility for all risk in the corporation, we will be the scapegoats for any compromise and will be unable to be effective. Not only will we continue to suffer, but the business will continue to be compromised with frightening regularity.
This marks blog post 2000. It’s taken 7.5 years. But it’s been worth it.