Introducing Cisco Identity Services Engine (ISE) Profiling

22 December 2011 by 7 Comments

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 1.0.4.573 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.

The first rule checks that the browser’s user agent contains “Android” somewhere in it.

This second rule checks that the host name contains “android” in it.

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

Filed Under: Blogs, Security Tagged With: , , , ,
About m00nie

Is a network Engineer in "sunny" Scotland who lives by Greg's motto of "too much networking would never be enough". Currently working for a service provider having previously worked at a large enterprise and a Telco. Likes searching for those mythical unicorn tears.

He posts on www.m00nie.com and packetpushers.net

  • Forkwieldingmonkey

    In the short demo I saw, the defaults were “usually” able to destinguish between an IPad1 and IPad2 correctly

    • http://www.m00nie.com/ Gavin McBain

      We had to make our own iPad2 profile policy to get them picked up at all. Its more the simple (easily spoofed) nature of the checks that worries me a bit. Hopefully in time the policies can be made alot more reliable. 

  • Anonymous

    Why does my spidey sense warn me that a plethora of security issues are about to be unleashed upon the world?

  • Marvin Rhoads

    Gavin,

    You can use named ACLs on WLCs with the current versions of ISE (1.0.4) and WLC (7.0.220). A named ACL can effectively do what a dACL does, just requiring a bit more work to pre-position it on the WLC(s).

    I haven’t seen the detailed roadmap per se but know that more integration with WLCs is coming soon with ISE 1.1 and WLC 7.2

  • Guest

    I have been wondering if once a device is profiled and stuck in an endpoint identity group, if they continue to have the profile check each time they get on a network.  Any ideas?  I guess that I am much more apt to implement MAB if this profile check happens every time. 
    Say a phone is profiled as a phone using CDP, and they are in an IG that is allowed full network access using MAB.  So a savvy user changes their mac to match the phone, unplugs the phone, and plugs in his/her pc.  I wonder if ISE is smart enough to say, ok I see your mac, and that your a profiled phone, but I am not seeing the cdp string I expect…access rejected.

  • allen00874

    Hey Gavin,

    Could you please explain the following:

    Say you create a Profiler Policy called -PCBrandX and you set the Minimum Certainty Factor to 20 and you create a condition to profile based on a check for condition based on host-name in DHCP and you assign the condition a Certainty Factor Increases of 10 etc. (Assuming that I define an Exception Action and a Network Scan (NMAP) Action) in the policy.
     
    Here are the two questions:

    If you create another condition that initiates a scan Network Scan (NMAP) Action to scan say for OS – how does the scan influence the Certainty Factor?

    Also if you create a condition that initiates Exception Action – how does that influence the Certainty Factor?

    Thanks in advance,
    Allen

  • Russell Brenner

    Has anyone actually used ISE in a education or similarly large environment before? I’m looking at a solution by Bradford Networks, looks a fair bit better. The ISE profiling looks extremely cumbersome.