×
We have made updates to our Privacy Policy to reflect the implementation of the General Data Protection Regulation.

How to Protect a Vanishing Perimeter?

Download our in-depth report: The Ultimate Guide to IT Security Vendors

Batten down the hatches! Raise the drawbridge!

Kind of sounds funny in today's Information Technology context, doesn'tit? However, it should at least sound familiar to many of us in the ITsecurity realm. We've been following these practices for years, afterall.

The problem is that it's too late. We have no perimeter to secure, nomatter how hard we try to convince ourselves that we do.

Perhaps you're not convinced. Perhaps you think I'm just spewing fear,uncertainty, and doubt (aka FUD) like so many do these days. Well, let metry to convince you:

  • During the 1980's, as TCP/IP was spreading its way throughoutacademia, research, government, etc., there wasn't really any securityperimeter to speak of. It was largely a Utopian sort of interconnectivitywhere everyone trusted everyone else. Well, that was true until the 1988Internet worm, that is...;
  • Not long after Robert Morris's worm spread across the Internet,people started trying to create security perimeters to protect ourdelicate 'internal' computing systems. And thus, the network firewall wasborn;
  • That illusion of a perimeter wouldn't last very long, though.Pretty soon, everyone wanted to attach their applications to the firewallso they could connect with the outside world. We in IT security reactedwith caution and quickly established a sandbox network where theseapplications could be set up without compromising the sanctity of ourdelicate internal computing systems. Thus, the de-militarized zone (DMZ)was born;
  • That, too, wouldn't last very long. While IT security held controlof the security perimeter, software developers slowly chiseled away atit. IT security proclaimed, ''Only essential network services will beallowed through the firewall -- TCP/25 (SMTP for email), TCP/80 (HTTP forWeb), and TCP/443 (HTTPS for SSL-encrypted web).'' In response, thesoftware developers came up with a protocol that would enable them toconnect their applications in a way that kept IT security happy -- WebServices riding over Service Oriented Architecture Protocol (SOAP). SOAPhappily rides over HTTP and HTTPS, which made IT security happy, right?All was well, or so we thought
  • Simultaneously (more or less), other forces were acting to furthererode the notion of a perimeter. When the firewall turned out to be toorestrictive for our remote users, we invented the Virtual Private Network(VPN) so they could connect to our delicate internal computingenvironment without compromising the perimeter;
  • Then, as dial-in connections became thought of as increasinglyprimitive, broadband and wireless connectivity was popping up everywhere.How much do you know about the computers and networks at the other end ofyour VPN connections? How much do you know about the WiFi hotspots yourpeople are using? No problem, we'll just ensure that all remote systemshave up-to-date patches, firewall software, and anti-virus softwareinstalled, right? Still promulgating the notion of a definable securityperimeter, but we're pushing it further and further away from ourdelicate internal computing environment. Something has got to give;
  • Still unconvinced? That's healthy. Don't believe everything youread. Besides, I've saved the best for last.

    Just as software developers came up with SOAP to get around ourfirewalls, they've come up with a whole class of software that opens andretains network connections to external systems. These include desktopinstant messenger applications, many Voice over IP applications, etc.Notice how popular IM has become in the past few years? Notice howpopular Skype and all the others are becoming?

    Take a closer look at how Skype works behind a firewall sometime. On atypical home network router that prevents all unsolicited incomingnetwork connections, Skype runs just fine, even allowing unsolicitedincoming phone calls while the user remains connected to Skype.

    The software has circumvented the firewall, folks. It opens and retainsan active network connection out to the Skype infrastructure, whichhappens to be peer-to-peer (P2P). How much do you know about the IM/VoIPsoftware running on all of your desktops? How much do you know about theexternal servers and P2P networks that are required to make theseapplications function?

    Blocking those ports at the firewall, you say? Well, your users arepretty smart people. In all likelihood, they disable the VPN clientsoftware and run their own software on their laptops or desktops, andgleefully connect to these services.

    I hope you're convinced by now that the perimeter, at the very least, isnot as clear a line as you may have thought it was.

    I say there is no perimeter per se; there is just a multitude ofdefensive products and features spread haphazardly throughout ournetworks. That's probably too far to the other extreme, but I think theconcept is not all that far fetched.

    I also want to emphatically note that I'm not saying AIM, Skype, and thelike shouldn't be used. Quite the contrary. I love them both, and I'm anavid user of both. The benefits justify their use, to me. Wellconfigured, they can be powerful business and personal tools.

    My main point is that our notion of a security perimeter is at bestantiquated. At worst, it's a dangerous way of thinking.

    Until and unless we concentrate our security efforts on the software, allof the security perimeters we devise will be swept aside. We cannotafford to presume that our security perimeter products will protect usagainst bad software -- no matter how much we've paid for them.

    The status quo today is that a security vulnerability in some basicapplications can punch right through our 'perimeter' and send us ITsecurity folks scrambling to put out yet another fire.

    That doesn't instill me with much confidence, and I hope it doesn't foryou either.

    Kenneth van Wyk, a 19-year veteran of IT security, is the prinicpal consultant for KRvW Associates, LLC. The co-author of two security-related books, he has worked at CERT, as well as at the U.S. Department of Defense.

  • Submit a Comment

    Loading Comments...