As we discussed in the first post of this series, consumerization and mobility will remain macro drivers of security for the foreseeable future, and force us to stare down network anarchy. We can certainly go back into the security playbook and deal with an onslaught of unwieldy devices by implementing some kind of agentry on the devices to provide a measure of control. But results of this device-centric approach have been mixed. And that’s being kind.

On the other hand from a network security standpoint a device is a device is a device. Whether it’s a desktop sitting in a call center, a laptop in an airline club, or a smartphone traipsing around town, the goal of a network security professional is the same. Our network security charter is always to make sure those devices access the right stuff at the right time, and don’t have access to anything else. So we enforce segmented networks to restrict devices to certain trusted network zones. Remember: segmentation is your friend – and that model holds, up to a point. But here’s the rub in dealing with those pesky smartphones: the folks using these devices actually want to do stuff. You know, productive stuff – which requires access to data. The nerve of those folks. So just parking these devices in a proverbial Siberia on your network falls apart. Instead we have to figure out how to recognize these devices, make sure each device is properly configured, and then restrict it to only what the user legitimately needs to access.

But controlling the devices is only the first layer of the onion, and as you peel back layers your eyes start to tear. Are you crying? We won’t tell. The next layer is the user. Who has this device? Do they needs access to sensitive stuff? Is it a guest who wants Internet access? Is it a contractor whose access should expire after a certain number of days? Is it a finance team member who needs to use a tablet app on a warehouse floor? Is it the CEO, who basically does whatever he or she wants? Depending on the answer you would enforce a very different network security policy.

For lack of a better term, let’s call this context, and be clear that the idea of a generic network security policy no longer provides adequate granularity of protection as we move to this concept of any computing. It’s not enough to know which device the user uses – it gets down to who the user is and what they are entitled to access. Unfortunately that’s not something you can enforce exclusively on the device because it doesn’t: 1) know about the access policies within your enterprise, 2) have visibility into the network to figure out what the device is accessing, or 3) have the ability to interoperate with network security devices to enforce policies. The good news is that we have seen this before, and as good security historians we can draw parallels with how we initially embraced VPNs.

But there is a big difference from the past, when we could just install a VPN agent that downloaded a VPN access policy which worked with the perimeter VPN device. With smartphones we get extremely limited access to the mobile operating systems. These new operating systems were built with security much more strongly in mind – including from us – so mobile security agents don’t have nearly as deep access into what other apps are doing – that’s largely blocked by the sandbox model embraced by mobile operating systems. Simply put, the device doesn’t see enough to be able to enforce access policies without some deep, non-public access to the operating systems. But even that is generally not the stickiest issue with supporting these devices.

You cannot count on being able to install mobile security agents on mobile devices, particularly because many organizations support a BYOD (bring your own device) policy, and users may not accept security agents on their devices. Of course, you can declare they can’t access the network, which quickly becomes a Mexican stand-off. Isn’t there another way, which doesn’t require agents to implement at least basic control over which mobile devices gain access and what they can reach?

In fact there is. You should be looking for a network security device that can:

  1. Identify a mobile device and enforce device configuration policies.
  2. Have some idea of the user, and be able to understand the access rights of the user + device combination. For example, the CFO may be able to get to everything from their protected laptop, but be restricted if they use an app on their smartphone.
  3. Support the segmentation approach of the enterprise network – identifying users and devices is neat but academic until it enables you to restrict them to specific network segments.

And we cannot forget: we must be able to most of this without an agent on the smartphone. To bridge this mobile security gap, those are the criteria we need to satisfy. In the next post we will wrap up this series by dealing with some of the additional risk and operational issues of having multiple enforcement points to provide this kind of access control.