Sunday, October 17, 2021

How to Protect a Vanishing Perimeter?

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.

  • Similar articles

    Latest Articles