How to Protect a Vanishing Perimeter?

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:

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.