Free Newsletters :
Datamation.com
Security
Read More in Security »

How to Protect a Vanishing Perimeter?

Columnist Ken van Wyk says the idea of a perimeter is quickly fading away. And considering it a solid border is a dangerous way of thinking. Now, it's time, he says, to focus on the software.
April 4, 2005
By

Kenneth van Wyk



Kenneth van Wyk



Batten down the hatches! Raise the drawbridge!

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

The problem is that it's too late. We have no perimeter to secure, no matter 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 me try to convince you:

  • During the 1980's, as TCP/IP was spreading its way throughout academia, research, government, etc., there wasn't really any security perimeter to speak of. It was largely a Utopian sort of interconnectivity where everyone trusted everyone else. Well, that was true until the 1988 Internet worm, that is...;
  • Not long after Robert Morris's worm spread across the Internet, people started trying to create security perimeters to protect our delicate 'internal' computing systems. And thus, the network firewall was born;
  • That illusion of a perimeter wouldn't last very long, though. Pretty soon, everyone wanted to attach their applications to the firewall so they could connect with the outside world. We in IT security reacted with caution and quickly established a sandbox network where these applications could be set up without compromising the sanctity of our delicate internal computing systems. Thus, the de-militarized zone (DMZ) was born;
  • That, too, wouldn't last very long. While IT security held control of the security perimeter, software developers slowly chiseled away at it. IT security proclaimed, ''Only essential network services will be allowed through the firewall -- TCP/25 (SMTP for email), TCP/80 (HTTP for Web), and TCP/443 (HTTPS for SSL-encrypted web).'' In response, the software developers came up with a protocol that would enable them to connect their applications in a way that kept IT security happy -- Web Services riding over Service Oriented Architecture Protocol (SOAP). SOAP happily 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 further erode the notion of a perimeter. When the firewall turned out to be too restrictive for our remote users, we invented the Virtual Private Network (VPN) so they could connect to our delicate internal computing environment without compromising the perimeter;
  • Then, as dial-in connections became thought of as increasingly primitive, broadband and wireless connectivity was popping up everywhere. How much do you know about the computers and networks at the other end of your VPN connections? How much do you know about the WiFi hotspots your people are using? No problem, we'll just ensure that all remote systems have up-to-date patches, firewall software, and anti-virus software installed, right? Still promulgating the notion of a definable security perimeter, but we're pushing it further and further away from our delicate internal computing environment. Something has got to give;
  • Still unconvinced? That's healthy. Don't believe everything you read. Besides, I've saved the best for last.

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

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

    The software has circumvented the firewall, folks. It opens and retains an active network connection out to the Skype infrastructure, which happens to be peer-to-peer (P2P). How much do you know about the IM/VoIP software running on all of your desktops? How much do you know about the external servers and P2P networks that are required to make these applications function?

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

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

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

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

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

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

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

    That doesn't instill me with much confidence, and I hope it doesn't for you 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.



    • 0 Comments (click to add your comment)
    Comment and Contribute

     


    (Maximum characters: 1200). You have characters left.

     

     

    IT Offers