Rethinking network security: all your on-premises WiFi users are actually "remote" users - Brian Madden - BrianMadden.com
Brian Madden Logo
Your independent source for desktop virtualization, consumerization, and enterprise mobility management.
Brian Madden's Blog

Past Articles

Rethinking network security: all your on-premises WiFi users are actually "remote" users

Thanks for sharing your feedback! If your feedback doesn't appear right away, please be patient as it may take a few minutes to publish - or longer if the blogger is moderating comments.
Written on Apr 15 2013 7,821 views, 6 comments


by Brian Madden

Last week I spoke at TechTarget's Modern Infrastructure Decisions conference in New York City. My topic was about the Consumerization of IT, specifically ten things you can do to start to address consumerization in your organization. One of my ten things was "rethink network security," a topic that's important but that I've never written about before. (Until now!)

My basic idea is this. The "old" (or current?) approach to network security is based on "work" being a building. We trust devices that are inside the building, and we don't trust devices that are outside the building. So, roughly speaking, the building is the boundary of trust, like this:

The old network security

But in today's world, this approach to network security is bad for two reasons:

First, we can't trust a device just because it's inside the building. Devices are small and portable and easy to bring in, and there are too many "FUIT" ways to get around protections meant to prevent untrusted devices from getting the network. (MAC address spoofing to fool NAP/NAC, setting up rouge access points, jailbroken devices that lie to security scanners, etc.) So just because a device is inside the boundaries of the building doesn't mean we can trust it.

In today's world the opposite is true too. We have lots of trusted devices being used outside of the building. The traditional approach to dealing with these involves a VPN and maybe some client-side scans, but we often make the users jump through a lot of hoops to "prove" that they're who they say they are and connecting from a trusted device. The problem with that approach in today's world is that if we make the barrier to connection too high, user's will just say, "Eh, screw it!" and not connect to the VPN because it's such a pain. So our supposed "high security" VPN just means that we have users using Gmail instead of the corporate mail, or Dropbox instead of the corporate file sharing system. (So ironically our high security standards have the practical effect of actually lowering security overall.)

A better approach to network security for today's world

Instead, I propose that we move the trust boundary from the building perimeter to the actual resource you want to protect. e.g. You put the VPN around your server, rather than around your building, like this:

A better way for network security

The way I see this is that you basically open up your corporate user-land network to any device. Just make it wide open. (Or use basic WEP that prevents randoms from poaching your WiFi from the parking lot.) So you're essentially provide generic internet access, just like a user would have at home, the airport, on their 4G card, or at Starbucks.

Doing this provides several advantages:

  • You don't have to worry about or police every single device that walks through your door.
  • Users have the same experience everywhere. No "do it this way from the office" and "do it this other way from home."
  • You don't have to worry about rouge 3G connections or wrap your building in copper mesh.
  • You can wrap similar security around your resources regardless of where they are—in your datacenter, at a remote site, cloud-hosted services, etc. Your users connect the same way to all.

Of course there are a few disadvantages of this too:

  • You might have to buy more VPN licenses since essentially everyone will use the VPN all the time
  • You might have to update your WiFi gear to support all those new connections. (Ruckus Wireless anyone?)
  • You might have to update your networking gear to provide QoS, traffic shaping, and/or VLANs-per-user

Common objections, and why they're not valid

Whenever I talk about this, there are a few common objections that most people have, but from what I can tell none of them are that real. Here they are, along with my thoughts on them:

"But then one rouge user could take down the whole network!"

Oh please... If Starbucks or the local football stadium can figure out how to provide WiFi for the general public (hackers included), then so can you. Sure, if you have 1997-era Aironet access points then yeah, there's no QoS and one bad (or hacked) user could do some damage. But if you put each user on a VLAN, get some modern wireless gear that with enough capacity to support several devices per employee, and you do some QoS and traffic shaping, then you're fine. Again, if a hotel can figure it out, so can you.

"But how will I support all these devices?"

Well, you're supporting users connecting from home with non-company devices today, right? So how is this any different?

"I can never allow non-trusted devices on the corporate network"

You need to redefine your definition of "corporate network." Your corporate network is the tight boundary that's around your servers or whatever else you're actually trying to protect. There's no point to protecting your entire user-land network. Just make it "the internet" and move on.

Actually, that's a good bottom line to summarize this whole concept. You can't protect the user-land network, so don't even waste your money and time trying. Instead spend your money and effort where it can actually be effective, buying a decent SSL-VPN solution, good networking gear, and modern WiFi hardware. Done.

 
 




Our Books


Comments

Matt Kosht wrote re: Rethinking network security: all your on-premises WiFi users are actually "remote" users
on Mon, Apr 15 2013 9:06 AM Link To This Comment

Well said and completely agree. Been saying it for a year ;)  However the notion of making "open" or WEP wifi is a puzzling. I have WPA2/PSK on my wifi at home to keep someone from simply capturing data from the air. Judging from my neighbor's wifi I can see from my house they do the same.  I wouldn't want LESS security in the office. A simple key/WPA2 wouldn't be very onerous and would be MUCH better than WEP which is easily hacked .

I would posit that the server security boundary should NOT contain DV servers either. They are not any different than any other desktop.

Peter Fretty wrote re: Rethinking network security: all your on-premises WiFi users are actually "remote" users
on Mon, Apr 15 2013 11:20 AM Link To This Comment

Well said. Far too much attention is devoted to the various devices and no enough on the network and data. With a growing BYOD focus the most important component is always to protect data access -- after all that is one thing that is always the enterprise's responsibility. This approach also opens up IT to build on the user relationship.

Brian Madden wrote re: Rethinking network security: all your on-premises WiFi users are actually "remote" users
on Mon, Apr 15 2013 11:25 AM Link To This Comment

Yeah I agree that WPA2 would be fine too and also compatible with everything, but if your VPN boundary is done right than it shouldn't matter. After all most public networks use no encryption at all and you have to be confident with your users there too. But of course, if you're going to enable encryption, yeah, may as well be WPA2 instead of WEP.

Also I LOVE the idea of having your VDI servers outside that boundary. YES YES YES!!!

David Stafford wrote re: Rethinking network security: all your on-premises WiFi users are actually "remote" users
on Mon, Apr 15 2013 11:59 AM Link To This Comment

+1 on VDI connection/security servers outside boundaries.  The project name of my first VDI deployment was "Alternative Access".  It was exactly this premise that while we in IT feared giving just any device 'equal' access, providing everyone an 'alternative' means of access in the event they can't pass NAC policy/controls would be the next best thing.

With regards to WEP/WPA/WPA-2/etc. - Sure. Dual-SSID's would make sense, but why not deploy a 'pay-wall' style solution exactly like airports, hotels, etc to make sure zero-day devices like the Microsoft Watch could also enable employees to auth in from a wide-open SSID ?

Srini Gurrapu wrote re: Rethinking network security: all your on-premises WiFi users are actually "remote" users
on Mon, Apr 15 2013 12:27 PM Link To This Comment

This is actually going back to 2004 when NAC (Network Access Control) market became a hot topic and eventually led to UAC (Universal Access Control) markets.

At Juniper, we first solved the "untrusted locations", "untrusted devices", "external users" with an SSL VPN solution to provide end-to-end security. Then we realized that most security threats were coming from inside with mobile workers. So, we came up with "location-agnostic", "device agnostic" secure access for both inside and outside access -- using SSL VPN model. In fact, at Juniper, we used to route all access from the Wireless Access Points to an SSL VPN device so that every Wi-Fi access from any device, any user, any location is secured. However, inside the network you would have problems of the "network throughput" to secure every connection through SSL VPN, so we used IPSec with NULL encryption to minimize the overhead in the LAN-only use case.

Net-net: Every access  to a resource from any device, any location, any user, a need to provide the same level of secure access like an SSL VPN device. In fact, I saw this as running VPNs everywhere for every acces -- resulting in a notion of "Fully Private Networks" (FPNs). In the mobile world and consumerization, this is absolutely necessary.

At WheelZ, we are trying to unveil the vision of FPNs with application specific security addressing the end-to-end security, including both data-at-rest and data-in-transit.

Srini

(Note: You must be logged in to post a comment.)

If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.