There Is No Perimeter

Last week I mentioned the myth of the “network perimeter” and alluded to the futility of trying to secure it, and I wanted to expand on that theme a little more.  I frequently find myself working with IT staff that have a mentality of “us vs. them” or “inside the perimeter vs. outside the perimeter” concept of security.  I strongly believe that there needs to be a paradigm shift in thinking from the perimeter based view to one of embedding security throughout the infrastructure, top to bottom, and in every component

To understand why this is so, let’s look way back through the mists of time to a different epoch, to the early nineties when Bruce Springsteen was still making hits, Grunge was hitting its stride, and some of us dedicated ourselves to the crazy antics of those kids in Beverly Hills.  Before the early nineties, when I deployed my first corporate “Internet” connection and “firewall” (router with an ACL), few corporations had Internet connectivity.  What connectivity there was generally consisted of some point-to-point leased line connectivity; perhaps some dedicated frame relay, X.25, microwave, satellite links and often banks of modems for dialup.  The vast majority of these connections were internal to the organization, generally connecting remote facilities together, occasionally for special business partner connectivity, and for support staff and remote access by at-home workers.  Generally there was no service provided to the general public, everyone who connected to us was a known entity.  Those connections to outside entities were dedicated to special application, often simple messages, such as automated re-ordering from a MRP system between customer and suppler.  All the connected sites were considered trusted; there were no concepts like DMZ.

Then came the Internet, web sites, services aimed at the unwashed masses of Internet connected pubic.  Providing services to those entities who were completely unknown to us.  Cheswick and Bellovin’s landmark work “Firewalls and Internet Security” (Addison-Wesley , 1994) documented and cemented the concepts of the Internet perimeter, DMZ networks, and the placement of firewalls.  This work and the thinking of the time followed the paradigm of “us vs. them”.  This was probably appropriate for the time, back then many corporate network infrastructures did have something that could approximate a perimeter, a point or set of points on the network on one side of which all network connections were trusted, on the other side of which they weren’t.  That often amounted to the Internet on the outside and everything else on the inside.  But times changed, and the perimeter has slowly blurred to the point, in many organizations, where it simply doesn’t exist any longer.  How did that happen?  Let’s consider some of the services and connectivity most corporations now provide on their networks.

One of the biggest drivers for the blurring of the perimeter is the use of VPN technology.  For site-to-site VPN this essentially connects two remote networks into one.  In many cases this is easier to secure as a control can be applied to the single point of connection.  Client VPN is a different story.  Often provided for remote workers, ROHO/SOHO, remote and after hours technical support, vendor access, this provides a direct network connection between a remote workstation and one or more systems on the corporate network.  Due to the way it proliferates, it becomes much harder to control, as it has to be done on a host by host basis.  However as a corporation you generally have very little control over the machines at the other end of the connection.  For example unless you are providing workstations with locked down images you have only a modicum of control, and even then it isn’t fool proof.  How do you prevent remote workstations transmitting virus or worm code?  What about remote tunneling where the remote workstation acts as a router for other Internet traffic?  What if the remote machine is part of a Botnet or is otherwise “owned” and has remote command and control software on it?  Finally there is the issue of management of the remote users.  If this is for vendor support, does everyone at the vendor have a single username/password?  How do you get plugged into the vendor HR processes to manage account and passwords when there is turn over?

Even worse than VPN is the “Reverse VPN” type of service by vendors like GoToMyPC where individual internal users can setup their workstation on the internal network to make outbound connections which are then used to command and control the internal machine.  These services have all the same problems as with VPN, and this is even harder to control.  Even a proxy won’t work if the data stream is HTTP compliant.  Some you may be able to control with IP address filters, but not all and especially the deliberately malicious ones.  Try Googling “reverse www shell” sometime if you need something to keep you awake at night.  Various browser based, virus, and other exploits deliver remote command and control software that makes outbound connections.

Infrastructure and the deployment of applications and services can also blur the perimeter.  For example systems in a DMZ network that can make inbound connections to networks of higher trust levels can provide a route inbound for malicious traffic.  Consider how your DMZ application layer systems access back end databases.  Or how webmail machines are accessed (Outlook Web Access is a huge offender).  Another huge offender is Blackberry Enterprise Server.  This remotely accessible system, which has had numerous issues in the past, and which can provide remote access capability to mobile computers (Blackberries) is frequently on an internal trusted network.  Wireless networks can extend your internal network a mile or more depending on your equipment and the use of remote login services over the Internet potentially extends your corporate network across the globe.

There are many more examples of the blurring of the perimeter, hopefully these few have at least conveyed the message that focusing on securing the perimeter, while important, is not the complete solution.  A good exercise to determine if you might be relying on perimeter security too much is to print out your network diagrams, point at a system and say “That machine is compromised, now what?” Or ask yourself what happens when a vendor’s network is compromised and they connect to yours.   Remember (gratuitous Matrix reference) “Do not try and secure the perimeter.  That’s impossible.  Instead… only try to realize the truth….There is no perimeter”.

Speak Your Mind

Tell us what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!