The Problem

Bring your own device (BYOD) means something different to everyone you talk to. Is it company issued mobile devices, is it the employee’s mobile devices, or is it employees bringing their personal laptops to work?

No matter how you define it, I would argue BYOD devices do not need the same access to your data as your workstations. A mobile tablet probably does not need access to your customer database. An employee bringing their laptop to play World of Warcraft on their lunch break also should not have access to your file share, so how do you begin to restrict these devices without overly complicating your network?

The Solution

With Cisco’s Identity Services Engine, ISE for short, you can set up policies that will allow you to use your existing workforce service set identifier or SSID to provide the differentiated access you need to start securing your network.

In this article, I’ll lay out a wireless access policy and show you how your devices will conform to this policy using a single SSID. Then in my next article, I will walk through the configuration that was used to make it happen.

Policy

The first step to any successful security strategy is defining the policy. In our wireless access policy we will allow domain computers to have full access to the network, utilizing their device certificate for authentication. The company issued mobile devices will have a user certificate for authentication and they will also be checked with our mobile device management (MDM) platform. If they are compliant, we will allow them access to our inside network, but restrict them with an access-list (ACL). Lastly any device that connects with user credentials will be moved to our off network guest VLAN.

Wireless Access Policy

Device Type

Authentication

Posture

SSID

VLAN

Access-list

Company Computer

EAP-TLS

N/A

GET IT

Inside 582

Company Mobile

EAP-TLS

Compliant

GET IT

Inside 582

INET_Exchange

Employee Device

PEAP

N/A

GET IT

Guest 583

Company Computer

The company computer we’ll be using is a Windows 7 desktop joined to an Active Directory domain. It has a wireless profile and computer certificate pushed down to it through Group Policy. When it joins the wireless network we get the following permission.

Network1

 

You can see from the wireless LAN controller (WLC) screenshot that our device named “CSATENG-WIN7-01.csateng.lab” is connected to our WLAN profile named “blog.cdw.com”. The permission applied put it on the inside VLAN 582 with no ACL applied.

Company Mobile Device

The company mobile device is an iPad that has been issued a user certificate through the MDM solution. When it joins the wireless network it is given the following permission.

Network2

 

You can see we are still connected to the same WLAN profile, but our permission is a little different. Again Extensible Authentication Protocol Transport Layer Security (EAP-TLS) was used for authentication, but this time it had our username as the identity. With that information, ISE knew to still put us on VLAN 582, but this time it applied an ACL named INET_Exchange to limit our access to the network.

Employee Devices

The employee device can be anything, a laptop, iPod, tablet, or coffee maker. Okay, the coffee maker is probably a stretch. But who knows? The point is we can accommodate them, but we are not going to put our data at risk. Let’s see what happens when our iPad connects and uses the “User1” Active Directory username and password.

Network3

 

Again we still connected to the same WLAN profile, but this time our permission is completely different. Protected Extensible Authentication Protocol or PEAP was used for authentication and with that information ISE put the device on VLAN 583, which gave us guest equivalent access. The experience is different than our guests will be, but the permission is the same.

Conclusion

You can see by the examples there is a lot we can do to help mitigate risk while simplifying the design. With ISE, we are able to accommodate many different scenarios with a single SSID while still maintaining our security policy. In the next article, we will walk through how the devices were configured to make this work.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>