Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
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:
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…;
people started trying to create security perimeters to protect our
delicate ‘internal’ computing systems. And thus, the network firewall was
born;
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;
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
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;
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;
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.
