Cisco Identity Services Engine ISE Profiling: Profiler Explained

ISE ProfilingI’ve received a handful of support cases from engineers and customers around Cisco Identity Services Engine ISE Profiling. Questions range from “why are my devices showing up as UNKNOWN” to “How does ISE Profiling work?” Here is a breakdown of how ISE Profiling works for version 1.0.

NOTE: There are some VERY cool things coming from Cisco in the near future on this topic so stay tuned.

Cisco ISE Profiling is an advance subscription license feature used to identify what endpoints are based on network data obtained from a number of enabled probes. Use cases range from managing access rights for devices that don’t authenticate (IE Printers, Card Readers, etc.) to developing policies around device types (IE handling iPads differently from Laptops). Accuracy about device types increases as more probes are enabled. Cisco ISE probe options are NetFlow, DHCP, DHCP SPAN, HTTP, Radius, DNS and a few SNMP TRAP/Query options. Probes view network traffic seen by designated sensors (IE a ISE enabled switch). If you quickly plug and unplug a laptop into a switch, most likely ISE Profiling will only see the SNMP link up trap and know very little about the device. If the device is plugged in and attempts to access the Web, ISE Profiling will see more data and be able to make a more accurate determination of the device’s identity.

Cisco ISE profiling has categories for devices obtained from the cloud or through customization. Each category has specific “weights” assigned that are measured against the device data. As Cisco ISE profiling captures data, different specifications trigger categories as assign weight values are met. For example, a iPad will move from UNKNOWN to APPLE DEVICE based on MAC, network card manufacture type and other info. As more data is collected about the iPad, Cisco ISE profiling will use other attributes to match it from APPLE DEVICE to iPad. Custom categories can be created from UNKNOWN or existing profiles however the majority of device profiles are obtained through the cloud.  Profiling is continuous meaning if a device is spoofed, its behavior will give away it’s true identity to provide continuous monitoring of device types on your network.

NOTE: If certain probes or data is not available, you may need to tune a category’s weight. I had a customer who did not use DHCP on their network, which is weighted very high for the AVAYA PHONE category. I had to adjust DHCP to a lower weight in the default AVAYA category before all phones were profiled properly.

Some common issues I have seen in the field are:

1)   Profiling is not working:

  1. Check to see ISE Profiling Services is enabled under General Settings
  2. Verify which probes are enabled under the Probe Config Tab
  3. Verify the switch you are testing is supporting the probe. For example, if you use SNMP RO, you need to have the switch use the SNMP-SERVER commands to send data to Cisco ISE Profiling. The switch also needs to be managed by ISE via network devices tab.
  4. You may need an ip helper address of the ISE device when using the DHCP probe so ISE sees the data.

2)   Devices remain as UNKNOWN

  1. Verify which catalog/profile you are attempting to hit. Click the UNKNOWN device and review the characteristics. Make sure the probes that are enabled are used by the category you are looking to achieve. See AVAYA PHONE example above. You may need to adjust category weights if specific data is not used or not seen by ISE.
  2. Click the UNKNOWN device and verify which probes are actually working. ISE Profiling will show what it knows. Go to the monitoring section and click the device details. ISE shows the communication in detail.
  3. Make sure you have updated your ISE system. If you haven’t updated ISE, it won’t have any categories. There are Air-gap steps for customers who don’t want ISE to touch the internet.

3)   Devices remain in a generic category.

  1. This problem is similar to remaining UNKNOWN. Verify the desired category weight attributes and match it to what ISE is seeing for the device under monitoring. You may either have to tune weights or not have enough data due to lack of probe information. Options are enable more probes or use MAC address based (MAB) authentication to recognize devices.

Hope this helps with your Cisco ISE Profiling adventures.

VN:F [1.9.22_1171]
Rating: 3.5/5 (13 votes cast)
Cisco Identity Services Engine ISE Profiling: Profiler Explained, 3.5 out of 5 based on 13 ratings

27 thoughts on “Cisco Identity Services Engine ISE Profiling: Profiler Explained”

  1. Thanks for the update. Would you be kind to explain the span probes? And how to enable this in a VM environment?

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
  2. You can do a SPAN port on the ISE appliance and VM version. On the appliance it is an unused interface. On the VM is is not really used, but you could create an extra vNIC and essentially SPAN your vSwitch. If you are using a 1000v you can also do a RSPAN. The use is pretty limited but the option is there. Most people do want that kind of traffic being copied over the network, especially to a ESXi server so its not really used.

    VN:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
  3. I have a client that wants to deploy NAC afresh. Instead of buying all the NAC appliances and then using ISE as profiler, can’t i just deploy the cisco ISE as the solution. He has less than a thousand devices to profile. So a 3315 ISE would suffice instead of using the 3315 as a profiler for a legacy NAC deployment.

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    1. Correct you can consolidate NAC appliance features and Profiler however understand there are a few cases where NAC appliance can provide features that are not available in ISE today. The main one is NAC appliance can be a true “bump in the wire” meaning you can point a untrusted interface at it and it will provide automated access control as a gateway. This works for situations where your customer doesn’t have control of their access layer switches and just want to redirect traffic through NAC via untrusted to trusted side. ISE doesn’t provide NAC through switches via SNMP today. It uses 802.1x like ACS 5.X mixed with profiling and posture.

      See my notes from the other comment you made regarding sizing.

      Hope this helps

      VN:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
  4. We are implementing the ISE solution for BYOD and your have been very useful. I have a doubt: how does the ISE identifies scan DHCP options, since DHCP traffic is not passing through ISE?

    VA:F [1.9.22_1171]
    Rating: 4.0/5 (1 vote cast)
  5. ISE has DHCP and DHCP span probes available as options for profiling. These are used as well as other metrics to figure out what devices are. For example, Ive had customers shut off DHCP and found some devices such as IP phones not profile correctly with default profiling categories. I had to tune the categories to not leverage DHCP aka change the weight of the DCHP probe section of a category for things to work correctly.

    Think of ISE as the Access Control management system while the switching environment is the “collectors” of probe date. Its pulling that information from the switches … not having data traffic hitting it directly. Do keep in mind that prior to 1.1, if the switches collecting the probe information are on another network, ISE will not be able to see all the traffic properly. This was fixed with the recent release (see my last post about ISE 1.1).

    I once experienced the lack of DHCP probe info when we had ISE in a lab network and used OEAP 600 access points for home network users. Those access points would issue DHCP locally over a VPN tunnel, which ISE couldn’t see that traffic via probes. The work around was shutting off DHCP on those access points and issuing IP after the users connected through the VPN via the switch (which ISE has access to).

    Hope this helps.

    VN:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
  6. Hi. Thanks a million for keeping up this blog. It’s a great help!

    I’m new to Cisco ISE and I’m deploying for a client. Your post on profiling was really helpful. However, I still don’t understand what DHCP SPAN is and what it does. I’ve searched the Internet for resources, but I’ve not seen any helpful documents. Please help out.

    Thanks.

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    1. This comes straight from the ISE 1.1 configuration guide – “DHCP Switched Port Analyzer (SPAN) probe, when initialized on a Cisco ISE node, listens to network traffic, which are coming from network access devices on a specific interface. You need to configure network access devices to forward DHCP SPAN packets to the Cisco ISE profiler from the DHCP servers. The profiler receives these DHCP SPAN packets and parses them to capture the attributes of an endpoint, which can be used for profiling endpoints.

      You can create a profiler condition of DHCP type, where you can use the dhcp-requested-address attribute for profiling an endpoint. For a FQDN lookup, the Domain Service Name (DNS) probe extracts the source IP address from the dhcp-requested-address attribute, which is collected by the DHCP SPAN probe.”

      Let me know if you need any further clarification. Make sure to verify how your desired devices are being profiled and what criteria is used to make a positive identification. You may find DHCP SPAN is or is not needed depending on device types. Regardless, it doesn’t hurt to enable as many probes as possible. Hopefully this helps!

      VN:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
  7. Do the DHCPSPAN and HTTP probes require configuration on a network switch? The documentation doesn’t mention it but i suspect it does.

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    1. Hi Grant. Yes you need to configure a SPAN port for DHCPSPAN. From the guide “DHCP Switched Port Analyzer (SPAN) probe, when initialized on a Cisco ISE node, listens to network traffic, which are coming from network access devices on a specific interface. You need to configure network access devices to forward DHCP SPAN packets to the Cisco ISE profiler from the DHCP servers.”

      HTTP is traffic seen by the end device meaning if you just plug in the device, HTTP traffic will not be seen (just things like Linkup-traps). The user must generate this traffic before ISE will see it. From the guide “The Cisco ISE server listens to communication from the web browsers on both port 80, as well as port 8080.”.

      This brings up a good point about VMware. From the guide “If you deploy Cisco ISE on an ESX server (VMware), the Cisco ISE profiler collects the DHCP traffic but does not collect the HTTP traffic due to configuration issues on the vSphere client. In order to collect HTTP traffic on a VMware setup, you have to configure the security settings by changing the Promiscuous Mode to Accept from Reject (by default) of the virtual switch that you create for the Cisco ISE profiler. When the SPAN probe for DHCP and HTTP are enabled, Cisco ISE profiler collects both the DHCP and HTTP traffic.”

      We had to add a IP-Helper to get our DHCP traffic to be seen by ISE since our end users were coming over a VPN, which DHCP was being issued locally rather than from the internal network. We forgot to change the promiscuous mode settings as well so our profiling wasn’t working that well due to lack of DHCP and HTTP. Once we made these adjustments, everything worked smoothly.

      VN:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
  8. ok, thanks. I saw the UG’s refer to SPAN but they don’t admit that you need to get the switch to SPAN everything from the client VLAN or uplink to ISE. This is potentially a lot of data, but with SPAN you cannot specify just DHCP or HTTP, it’s everything.
    It seems to me that for effective profiling you’d need:
    DHCP – preferably by “ip helper”, else by SPAN.
    DNS – for reverse lookups.
    RADIUS – gets this from NAD anyway.
    HTTP – must be by SPAN, unless it can get it from the guest portal login (not sure about this).
    Would you agree?

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    1. It depends on what you are profiling. You don’t necessarily need everything you listed to properly profile. It depends on the weights assigned per check for a device profile. For example, if you don’t want to use DHCP, you can reduce or remove the weight values from device profiles. This may lower the accuracy (IE an Apple Ipad and Iphone may look similar however you will know they are both IOS apple devices). The more info you provide, the more accurate you will profile. All checks can be adjusted if limited sources are available. For example, I added a DHCP check for “Cisco Cius” to distinguish a standard android from a CIUS.

      Hope this helps. BTW the new 1.1 code offers a NMAP feature to run scans. Its pretty cool for device assessments.

      VN:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
  9. Hi,
    I have a problem with devices hitting ISE for the first time ( I have deny authorization by the end if none of the rules match)
    They get denied and they stay denied until I manually reconnect and once they are profiled everything is ok for the rest of their lifes 😛

    here is a screenshot

    https://dl.dropbox.com/u/75261564/Selection_019.png

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    1. Hi Ed,

      There are a few things you can do to resolve this. Basically the goal is to do something with UNKNOWN systems and/or provide a way to give profiler enough info or time to figure out what the device is. This also depends on how you build the policy checks meaning you could do a combination of USER in AD with Device Time = certain access. You could also just look at people and hidden certificates on devices to verify the device is a company owned assest used by a trusted user. You could go under MAB auth policy, click action and change change REJECT to continue then have a webauth policy for anything that isn’t meeting your 802.1x and MAB policies. You could build a policy for UNKNOWN devices and give them very limited access that can give profiler additional time to profile it. Make sure to have the COA set so the device can be moved once its profiled (my guess is you have this set to deny rather than re-auth). Other suggestions would be to focus on your profiling settings. Its possible you could use other means to speed up the profile depending on how you are identifying the systems. For example, you may be seeing the layer 2 information however waiting for DHCP before having enough weight to change from the UNKNOWN state. You could adjust the weights of other values that you capture quicker to help move devices from UNKOWN to WORKSTATION. You could use checks higher in the stack such as DHCP for moving WORKSTATIONS to WINDOWS7 devices.

      Hope this helps.

      VN:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
  10. Hi!
    Sorry for my Bad english, but i am from Germany and was looking for ISE Infos…
    The Question in use with ISE for me is how the Profiling ist working?
    Take a Look:
    With the Profiling a Brother MFC Device was indentfied correctly in the Network.
    The Unified Indentfier is the MAC as i know from the CISCO Referenz.
    Ok what we got is a Endpoint that Authenticatet per MAC and Profile values.
    At this Time we are Not use dvlan or dacl.
    Ok now Take a pc and Fake the Mac of the Brother device and we will geht Access…
    I think beacause the Endpoint with the Mac is Not profield again with all values!
    I Hope you know what i want to say…
    We tried it with Open and without Open Mode!
    Daniel

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    1. Hi Daniel,

      Let me see if I understand. You have a device that works. A similar device is not. You are using Profiling and MAB (MAC Address) rather than 802.1x and profiling. You do not have any authorization policies setup to enforce Dynamic ACLs or VLANs. You are cloning a MAC address of a working device and it gets you access. So what is your goal? To test profiling so if a MAC address is cloned, the device will be profiled different and denied?

      There are a few things to understand. ISE works based on a few steps. The first is authentication meaning how are people connecting. Are they using 80.2x, MAB or Guest access? Are they using wireless, LAN and VPN? The next step is authorization meaning what do you do once they connect. Do you put them in a VLAN? Do you apply an ACL? Profiling works during these steps by monitoring the behavior of the device. You can create authorization policies based on a combination of a profiled category and how somebody authenticated (IE using AD, MAB, etc).

      So let me know what you are trying to accomplish. If you are looking to test profiling to distinguish one device from another similar device, thats not its purpose. Profiling will tell you both devices are the same type however the authentication means will determine how they should be treated (example is two employees one similar laptops may get different access because one is a ADMIN and other is a general user). Usually profiler is key when somebody spoofs a MAC of a authorized device such as a printer and tries to get full access hiding as a printer. Profiler will see the printer acting like a user and flag it as a user even though the MAC looks like a printer.

      Hope this helps

      Joey

      VN:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
  11. I think about what i wrote yesterday and i think i wrote it Not very well…
    My Company want to go away from Port-Security on cisco switches (2960-s) and we buy ISE 1.1.1 with Advanced licence.
    We only use wired endpoints at this Time.
    The endpoints that Support dot1x are ok and no Problem.
    The endpoints that Support only MAB are the Thing that i want to Secure. That are only endpoints Where no webauth are some other logins are possible.
    Most of them are old Printers and industry equipment and a lot of old Cisco phones without dot1x option. 7960 without G
    No the problem of profiling and authorization of these endpoints.
    Till now I think and tested that when a endpoint is profiled for the first time with some data collected , this data stay in the endpointlist.
    Sample Cisco ip phone is profiled as Cisco ip phone 7960 and authorized as the same with voice option. CDP value and others are collected correct.
    No take a pc and the MAC address of the ip phone and we become access like this phone.
    And I think this is because not all values we use are updated every time a endpoint is connected.most of the values that are profiled stay in the endpoint profiling.
    In the documentation I read that the MAC address is the identifier!
    And the other problem is that my English is very bad… 🙂

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    1. Hi Daniel,

      No problem I’m following you and trust me, your english is much better than my german. So devices supporting 802.1x are fine however “headless devices” / devices without users that can’t authenticate such as printers are your target for support. Those devices are LAN only and you are using a combination of MAC and profiling. You are testing using a PC and spoofing a IP phone. You would like to see the PC computer be recognized as a PC based on behavior even though it has the iphone’s MAC right? This is a common use case.

      To make this work, you need to first have a authentication policy for 802.1x devices and MAB devices. My assumption is you already have this. This determines if its a authenticated or MAC address based device. So your PC will authenticate 802.1x while a phone could go 802.1x if supported or default to MAB if not. Lets assume your phone goes MAB. When you spoof the MAC of the phone with the PC and don’t authenticate, your PC would also fall in the MAB category for authentication just like a phone.

      The important thing is your authorization policy (second tab under Policy). This is where you determine what happens if a device is a user, phone, etc. So what you can do is build a few conditions. One can be all users in active directory that are windows devices end up in permissions EMPLOYEE. All phones end up in permissions PHONES. You can create others for iphones, androids, MAC laptops, printers, etc. The permissions are built under policy elements and this is where you choose what network or security is applied (IE put them in a VLAN, add ACLs, etc). If you build this correctly and enable profiling, your PC with the MAC of the phone will first end up in the phone permissions based on meeting the condition for phone (via its MAC address) however it should change to user or probably get denied since ISE will recognize its behavior as a PC yet not see it in active directory (IE its not a employee) causing it to fall into the default deny all policy. You could great a generic PC policy that doesn’t check for authentication so devices that are not authenticated by employees could fall into if you think it would help with testing however best practice is to let it fall in the deny all.

      Hope this helps

      Joey

      VN:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
  12. Hi Joey.

    I read your respons to Daniel.
    You said that devices not authenticated as employees should go to deny all. But what should I do if I have a wired guest network, like in a conference room?

    ( I do prefer to have guests connect wireless with a guest login, but some companies have wired guest vlan that goes strait to the internet)

    Regards,
    Philip

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    1. Hi Phillip,

      Actually you are right regarding guest users. The typical policy is having all failed devices end up in a guest redirection page or having that as the last policy before deny. So for the previous example, the PC that is spoofing the MAC of a phone would first get phone access however its behavior would change its status to a PC that has not authenticated as a employee. That would land the device in the guest redirection policy (if a guest policy is included) since its a PC that has a guest user. Thanks for pointing that out

      Joey

      VN:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
  13. Hello Joey,
    Sorry for the late reply…
    First of all I thank you for the Help at this good Blog!
    At this time we are testing many things with ISE and hope that at the end all thinks works as design…
    But I had now 3 questions:
    1. In a other blog you describe the Cisco LMS, is this a think that could help to improve your network for dot1x? (more Easy)
    At this time we manage all with the command line.
    Do you now the Cisco Prime Infrastructure?
    2. Is this correct? Without local ACL and dACL the ISE will not work as design to secure a network? (Or VLANs)
    3. Have you a good address for example dACL for Printers or Cisco IP-Phones?
    Thanks
    Daniel

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    1. Hi Daniel,

      Yes LMS features are migrating to Prime. The key things you should consider are

      1) LMS / Prime offer the ability to perform a network assessment for 802.1x capability. The 802.1x report will check both hardware and software. If the software is not correct, you can enter you cisco CCO and download the correct version on the spot.
      2) LMS / Prime offer templates to push out the 802.1x AAA commands required to enable ISE. There are templates for monitor only, low impact mode, etc.
      3) Its best practice to use templates when enabling switches to avoid mistakes while enabling your environment for ISE.

      Regarding your second question, its not completely true. Many people start off using ISE in open / monitor mode as a first phase. The idea is to gain visibility of what is on the network and eventually develop a network security policy. Once you want to enforce policy, the options are vlans, ACLs (both dynamic and regular) and STGs (for only devices supporting TrustSec). Cisco’s NAC appliance technology offers layer 3 in-band only and layer 2 using SNMP. Some of these features may bleed into ISE in the future but not available today. Most people start off by dumping all trusted devices into a vlan and either put other devices in another vlan, add a ACL or just deny them.

      What type of example are you looking for? Here is a video on configuring dACLs http://www.youtube.com/watch?v=gEvXcplOZAs. The only thing to know is you can’t apply dynamic ACLs for wireless. You have to call ACLs from ISE that already exist in your wireless controller. Its not a big deal however it does mean you must make sure the ACL you call matches how its named in WLC (very common mistake).

      Hope this helps

      Joey

      VN:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
  14. Thanks for the post. I have an ISE configured for my environment. I have the following issues
    1) Devices that do not match authourization gets the default denyaccess policy but these devices still have full access to the network. I checked if any DACL was downloaded but could not find all. I later found out that the default denyaccess authorization policy does not use dacl as it uses reject access.
    Could it be some config on my switch that allowing this access? isnt ISE suppose to overide the switch config since its integrated?
    2) How does ISE profile a phone. It recognizes a Dlink Phone as just D’link device, so it does not match the NON-Cisco phone authorization profile.

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    1. Hi Elemzy. When things don’t work, its always best to call in TAC support.

      Some suggestions you can look at are going under your identified devices and look to see how they are profiled (found under identity management). A lot of times people think ISE is seeing all network attributes however they find devices are being profiled with just radius information. For example, we had a customer that used wireless for DHCP locally at a remote site. So DHCP data wasn’t being seen by ISE located at another office hence endpoints were not being fully profiled. Sometimes a IP helper can give ISE visibility while other fixes could be moving DHCP to a internal resource. Keep in mind Profiling uses many different attributes so the more info it has, the better read it can make on a device time. For example, if I plug in a laptop and quickly unplug it, ISE only sees the NIC card manufacture (maybe) and the link uptrap. This at most can give you a basic idea of what the system is but more data would be needed to determine a “apple device” verse “MAC book”.

      Regarding a IP phone, its as explained above. The thing is profiling is based on attribute weights. So for example, if you are not using DHCP and that has a high attribute weight to change a device from “ip phone” to “cisco phone”, then you may not trigger enough attribute weight to profile your phones. So what you need to do is click one of your Dlink devices under identity management and see what attributes are used to profile the device. You may need to adjust the Dlink device or Dlink Phone attribute weights such as ARP, DHCP, etc to make it work. In this very old blog post I explain how one customer didn’t use DHCP so Avaya phones were not being profiled. We had to adjust the Avaya attributes via lower the value for DHCP to make it work. TAC could help with this if you have questions on that process.

      VN:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
  15. I have just walked into an ISE deployment with profiling enabled , ideally the client will like profiling not to apply to Cisco phones ( they want to use an imported Mac- address list from CUCM) . They will like profiling for wireless in the future but the profiling is consuming advanced licensing as it is probing phones . How do I get the ISE to turn of profiling for Cisco phones so as the save on the advanced licences and just use the basic licences with mab authentication.

    VA:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    1. There’s no way to be selective of what type of devices get profiled but as Craig (and many others) have stated several times on the mailer, a device will only consume an Advanced license if there is an AuthZ rule that uses Profiling or SGT Assignment. If you do not have an AuthZ rule based upon the phone profiling, you should not be consuming an Advanced license.

      VN:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
      1. Thanks guys ,
        I am not on this mailer , I just signed up to the blog recently . Thanks for the help . There is a catch all auth rule that allows all access ( fail open ) . This explains why the advanced licenses are being consumed .

        VA:F [1.9.22_1171]
        Rating: 0.0/5 (0 votes cast)

Leave a Reply

Your email address will not be published.

Time limit is exhausted. Please reload CAPTCHA.