It's the Perimeter, Stupid

Some years ago I allowed myself to be lulled into a false sense of security by people I worked with.  When I would raise a security point, they would counter it with the perimeter argument:  sure we're putting sensitive data on the wire unencrypted, but it's our private wire, inside the perimeter. 

I bought it.  After all, if the network folks have sufficiently secured the corporate network, then we don't have to worry very much about packet sniffing.  They hold the perimeter, so as long as our traffic stays inside the firewall, there's no need to add additional protection.  This mentality is very pervasive among corporate developers.  Why?  Well I think partly because we want to believe it.  It makes our lives easier. 

But if we're honest (and not totally ignorant), we're forced to acknowledge that even if there were no such thing as the inside threat, this argument is embarrassingly, obviously, wildly wrong.

Last post I mentioned that someone once asked me, with respect to the horrendous security situation we're in, "how did it get this way?"

This is exactly how.  Naive, pollyannaish assumptions about the environment our applications are running in and the kind of people who will be abusing them.  These assumptions are at the heart of nearly every grave security problem, from the wide-open network protocols of the internet, to unencrypted account data, to the XSS vulns in our apps, to insecure default OS configurations.

I'm at least as guilty as anyone else, having bought into the perimeter fallacy some time ago.But I've seen the light again in recent years.  We can't keep this up or we're in serious trouble.


The other day, I was working on an application that needed to make use of a service over HTTP.  The payload would contain sensitive data, even social security numbers at times.  When working in the development environment, the developer of the service forwarded me a URL with the http schema. 

I pointed this out another developer, who rightly interrupted me to emphatically insist that use HTTPS. Right on.  But even this developer was not all that worried about it, citing the perimeter fallacy.


Now don't get me wrong, I perfectly understand the dilemma.  Developers don't want to think about security.  It's generally interesting only to developers who happen to be interested in security anyway.  Developers are far more interested in spending their brain power creating useful new things, solving problems at hand.

This is why I think that we need to start taking security out of the hands of developers, so that developers won't have to care about security in order to create relatively secure applications.  How to do that?  That's for another time.  I've already gone on too long.

In the meantime, we must start insisting on more secure development practices in our organizations.  We're negligent if we don't.