Cisco Identity Services Engine (ISE) is relatively new to the market, and I think it attempts to cater to Bring Your Own Device (BYOD) scenarios where IT doesn’t “own” or manage some devices. People like their iPads. I’ve been quite interested in how the magical ISE profiling works and its implications towards security. Apart from the profiling, ISE basically works as a Radius server, checking authentication and passing back attributes to switches or wireless LAN controllers. As a note, the profiling service requires an advanced license package on top of the base license. The following is from version 220.127.116.113 of ISE.
ISE profiling will check conditions in a profile policy. Each time a device matches a condition, the “Certainty” of its being that type of device is increased. ISE gathers its information from various sources; these can be DHCP, MAC, SNMP, IP, Radius or Netflow. From each of these sources, it can check various attributes – for example, the OUI assigned to a MAC.
So let’s look at a sample pre-configured profile policy to see how ISE determines the device type. The screenshot below is the default Android profile policy. Obviously, you can define your own policies, but this post is just to demonstrate the basic functionality of ISE out of the box.
We can see there are two if conditions that are checked, and each is weighted with a score of 30. The minimum certainty factor is 30, so only one of these conditions need to be met to classify the device as “Android”. Let’s have a look at what these rules check.
So basically, if either the host name or the user agent contains “android” then ISE is certain it’s an Android device. Here are a few other examples.
- Macbook – if MAC prefix is assigned to Apple and the useragent contains Macintosh and MAC OS.
- VMWare device – if MAC prefix is assigned to VMWare.
- Playstation3 – if MAC prefix is assigned to Sony.
- Blackberry – if two of the following match: MAC prefix assigned to RIM, dhcp-class-identifier is blackberry or hostname contains blackberry.
Hopefully in the future, we’ll see better policies and condtions to check device types. DACL support on the WLCs would be great to see, too.
If anyone wants to share custom rules they have found to be a little more robust than the defaults, please share them in the comments.
“Security is an architecture, not an appliance.” – Art Wittmann