Bring Your Own Device Security - NAC - MDM

Bring your own device is gaining traction in the enterprise for all the wrong reasons. It is my experience that devices unknown should not be part of your network. BYOD is touted as somehow empowering or the next step in the enterprise.

From a security perspective, you can barely trust the devices you are providing your employees, let alone the ones they might bring in from home. How many viruses, tool bars, ad-ware, and trojan's do you clean on a weekly basis off your own equipment? How hard are you trying to keep that stuff off of your own equipment? Most of us are trying pretty hard, so imagine letting in devices that are never maintained, never checked by a professional such as ourselves. How could that ever be a good idea? What would you have to tell yourself to allow that to happen? I can tell you, it's called NAC.

Network Access Control

NAC promises you that you will know what's on your network, it will inspect them, and it will take care of the unknowns for you. Refuse to be checked and be denied access to the network, simple. Fail some security check, like have no AV installed, or missing patches since 2003, no access to the network. NAC has a few levels or tiers that it can be applied at. NAC products have a robust feature set, and on paper look like they'd give you just the insight you'd need to allow "devices unknown" access to your network.

NAC can work for you, it does for quite a few organizations. NAC is an awesome compliment to network monitoring and could actually take over as your inventory system for some. They can inspect (with proper rights) the system, looking at installed programs, running services, patch levels, if anti-virus is present/updated/running and more! But there are always caveats. You often have to "whitelist" devices that can't "deal" with NAC's questions, or inspections. The network printer or copier/fax machines aren't "smart" enough or often capable of running a script of client to inspect them.
NAC should be paired with network switches capable of using 802.1x authentication. This way NAC can tell the switch to put the device on this network or on that network, perhaps just disable the port until a compliant host comes along.
802.1x is not easy to run, and again you will have ports that need to be whitelisted from using 802.1x, your switches may even be smart enough to use a static MAC address for allowances. Allow the copier, no matter where someone plugs it in, to work based on it's MAC address.

NAC can operate semi-seamlessly, and like a Captive Portal for a wifi, we've all used a Captive Portal before; it's when you're at a hotel, airport, Starbucks, restaurant, hospital etc... and no matter what site you go to you're redirected to a page where you may put in your name or agree to some terms or conditions before being allowed to the site you wanted to go to. That's a Captive Portal. NAC will essentially do the same to a computer that plugs in your network. The computer may run it's own NAC client, like Microsoft's NAP built-in client. Or like the Wifi captive portal, you'll open a browser and be presented with a choice to run a client or accept some terms and conditions. The clients are often Java or Active-X applications or more permanent binaries or executables. The Java and Active-X "agents" are supposed to be "dissolvable" so the user only has to run them once and they will self-delete.
These clients, scripts and binaries are going to try to tell the NAC about the device, and depending on the results, the NAC will allow or deny, in rare cases NAC will try to fix or remediate issues found.
Let that soak in a second. Would you allow another network administrator to change the settings, patch levels or services of your users equipment? Even with the best of intentions, they could break or inconvenience your users. If your internal application can only work with Java 1.7.X-niner-fiver, and your user, through NAC from another network gets a newer Java version, or some other patch perhaps; the user comes back in on Monday and your internal application doesn't work for the user anymore. You have to uninstall the more recent java version, and pull you hair out trying to figure out how it got there. The user just wanted on that other network, and it said click yes to "fix" the issue, and so they did.
I'll dedicate a longer article to NAC, it's a whole can of worms really, but in the end I feel there are more questions when using it than it's actually solving. Seems like a lot work that could and should be concentrated elsewhere. The data on your network is what matters, and NAC is not protecting that data, it's a "cover your a**" technology. To some it seems somehow better to say "the machine was fully patched, and running AV" when explaining how some incident occurred, versus the alternative. To some, not to me that is. A machine caused an incident on your network, and your defense is "well he was wearing a suit and tie" so he "looked ok to me".

Mobile Device Management

MDM is another NAC like technology, promising you insight and control of the mobile devices connecting to your network. MDM I think can be more effective than NAC when it comes to Mobile devices, there are better clients, a simpler device in some ways and very few caveats to using them. Where things begin to fall apart when putting MDM into use and how restrictive you try to be. You've never fought a battle until you've tried to keep Angry Birds or Instagram off of a user's company issued phone after they've had it on there before.

I've read quite a few articles and op-ed's from folks promoting BYOD's acceptance, even my own "Security Hero" has caved... I can't even tell you how confusing it was to hear him start off stating everything that is bad about BYOD, and then say:

In this case, the right decision is to sacrifice security for convenience and flexibility.

Equally sickening was agreeing with Marcus Ranum's counterpoint :)
Jokes aside, both make good cases, especially Bruce before "caving" to pressure.

One article in particular, while trying to advocate BYOD's use, in fact makes a better point against its use:  

Employees can use any device to access corporate data or systems as long as the device is compliant with the security policy.

Sounds good on paper, fails in practice. Let’s say we do magically allow only authorized, encrypted, patched and anti-virus compliant devices to access the network. Cool, so no thief can see the data on the device should be it stolen, no one infects the device should the user launch a virus program, nice… What about if that user uses iCloud, and backs up company data to Apple, and Apple get’s compromised, or an attacker does get past iCloud security: http://blog.crackpassword.com/2013/05/apple-two-factor-authentication-and-the-icloud/
MDM can prevent the users phone from backing up to iCloud and others, there are lots of settings to mess with depending on your selected MDM vendor. Don't cave in, if you are securing the phones that are your company's phone, the users lose any "rights" to dictate how they operate. Cases can be made, exceptions can be made, but if you want security you want to keep it simple. NAC and MDM are anything but simple.

Simple is as simple does:

Simple should be, but often isn't, company equipment is OK, everything else is not. Company equipment should have known phone numbers and mac-addresses. Company equipment should be white-listed for the most part, but to me a mobile device should be relegated to a network that only has Internet access. Doesn't matter if it's my company device or not, I don't see any productivity increase that can be managed when you shrink a computer and it's input methods like those of mobile devices.

The mobile devices are good at checking email, reading text/documents, but not necessarily good at composing them. If you have an OWA or online email portal your users phone can check for email, and read attachments, then good. Why does the phone or tablet need an internal network connection for that? If there is a place the mobile device is better than a PC, Server or Laptop, then let the device into that place only.
MDM is another CYA technology for a network administrator. If someone wants to get past the MDM software on the phone, you better believe it can be done, and by more people than you think capable of doing it. It's like saying: "We lost the briefcase with a copy of last years financials, but it was locked."

Final notes:

I'm not saying that you can't do BYOD, but look at it practically. Where is a mobile device better at the job than the computer the user is using. If it's just reading and replying to email, then all it needs is internet access for most organizations. The data you hold dear should not be mobile, it should be in "one place", at least in one network. Should your data be in everyone's pocket or purse? Encryption of mobile devices fails to hold up against attack or simple forensics tools. Those tools can be purchased or obtained by anyone. Where does the users device exceed, or supersede the devices you're already providing?
-rich