Security requires a prison not a fortress

Rob Labbe, Senior Security Program Manager at Microsoft challenges us to think about security in a new way: does it matter if someone gets in to your system if you stop them from taking anything out? 

One of the best parts of doing webcasts is people often ask you questions you hadn’t quite thought about, or make you think about issues in different ways. I just finished recording a security webcast on .NET Rocks with Carl Franklin and Richard Campbell and it got me thinking. Shame they never warned me I’d have to think.

The information security “industry” has turned out thousands of security products, tools, methodologies, processes, you name it… some of it is even pretty good. Given all that innovation, why is it, at a macro level it appears we’re not getting any better as an IT industry or as developers in security our systems and preventing large scale compromise?

It can’t be a lack of tools, platforms and processes can it? Given the huge advances in all those areas, I think it is pretty safe to say we have the tools in our toolbox to be more secure. So, if it isn’t the tools, could it be us? Could it be that as developers and IT pros we’re simply looking at security the wrong way?

Since the beginning of time, when we have something of value we try to protect it by ensuring the bad guys can’t get to it. We build castles, moats, and walls… Banks build vaults, we bury important military installations in the middle of mountains or solid chunks of granite. All that thinking carried over to our IT systems.  We focus on firewalls to keep the bad guys out, intrusion detection to let us know if they find a way in, and all manner of systems and technologies to do it. We’re building a big, digital vault to keep our company crown jewels locked up. In theory it’s a great plan. If we keep all the bad guys out, then there is no way they can steal our stuff.

Before we have a chance to finish our perfect, high security vault, we get a wrinkle, one I like to call “The Business”. They have requirements, they want to let people into our vault. All sorts of people. Good people, bad people, people we don’t even know about. By the time we’re finished poking holes in our vault for all the services and users want, a complex system can have thousands upon thousands of endpoints, holes and possible entry points.

I think we need a new analogy. Rather than building a vault or fortress, perhaps we need to design our networks as prisons. Classify our applications and data according to their sensitivity (minimum security right through super max) and flip a lot of our security and detective controls inward. Lets focus on controlling the known, our data, and relatively few users and systems that are within our span of control. Time has proven that we can’t prevent the determined human adversary from finding some foothold in, however we can make great strides in limiting that impact. Does it matter who gets in, if the important data doesn’t get out?

For IT Pros, most of this comes down to doing a really good job with hygiene tasks: Keeping machines patched, doing a good job with identity management (particularly privileged Identity) and you’re 90% of the way there. For developers, again it is partly hygiene, but we need to remember that our applications need to be installed on systems, so we need to work with the IT pros to ensure least privilege, and intelligent encryption and data protection for data based on the risk and data classification.

For Developers, to enable good application security hygiene we need a good Security Development Lifecycle. A good SDL will help you build that prison for your key data, help you identify the key assets, identify risks and design security controls to protect those key assets. Regardless of what is going on “out there” the SDL will help you manage and identify those places you need to work with IT to come up with one big plan.

Over the next several guest blog posts, I’m going to walk through the SDL from a developer’s perspective, using the prison as the analogy, we’ll look at how following good SDL practices will help us not only build a more secure application, but also do it in a way that has minimal impact on the project budget and schedule. It should be a fun ride, stay tuned!