When it comes to profiling endpoints, I’ve noticed that even some of the more ISE-focused engineers even see it as something that’s magical and vague that happens behind the scenes. This is not specific to ISE either. I don’t think I’ve ever seen a network access control product that has 100% profiling fidelity or as granular as a customer might expect it to be. I would say that the built-in profiles for ISE probably identifies 90% of endpoints from at least a high level. The purpose of this blog post is to help remove some of that “behind-the-scenes” magic for you so you can making profiling work for you.
The first thing I would do is to make sure probes are turned on correctly in ISE and the the network devices. Assuming that they are, the next thing I want to do is to take a look at all the endpoints and their attributes that ISE is receiving. You can click on the devices one-by-one in the ISE GUI but that would be pretty tedious and it’s hard to compare similar endpoints if you’re looking at them individually. Here’s the trick I like to use: Pull an endpoint dump from ISE. I made the following video before Cisco Live in 2019 and it demonstrates how to pull all the endpoints that ISE is seeing along with all the profile attributes that have been received for those endpoints:
In the downloaded CSV file, you’ll notice that you get a TON of different columns of information. It’s easy to be overwhelmed. You have to get rid of some of that noise. I usually delete all the columns except for the following:
host-name - Learned from DHCP. Sometimes default hostnames will tell you what type of device it is or if there is a naming convention you use for certain devices in your environment, you can use that as an attribute in a profile.
MatchedPolicy - I usually keep this in there so I can see if the endpoint is being correctly profiled or even if it has a profile built into ISE already.
OUI - Helps me to identify the manufacturer of the device
dhcp-class-identifier - Some vendors will actually state the device, model number or other information in the class identifier which can be used as part of a profile. An example of a class identifer would be “DolbyAudioHub” - this would tell me what type of endpoint it is.
dhcp-parameter-request-list - Useful in helping to determine what kind of operating system is on the device. Windows, Mac OSX, Android and iOS have certain DHCP parameter lists that are used which can help you to determine what OS that endpoint is running.
User-Agent - This is collected from the web traffic and can help us in determining not only the operating system but the model number of the device. Many Android and iOS devices will state the model number in the browser user-agent. An example of this might be “Android /…/ Nexus 5 Build” - This example would tell me that it’s a Nexus 5 phone running Android OS.
MDMManufacturer - If you’re using an MDM in your environment, this data can give you manufacturer information such as whether the endpoint is an Android or Apple device. This information is more informative than anything else since you can’t use it in a profiling policy.
MDMModel - If you’re using an MDM in your environment, this data can give you model information such as whether it’s an iPhone, iPad, etc. This information is more informative than anything else since you can’t use it in a profiling policy.
MDMOSVersion - If you’re using an MDM in your environment, this data can give you mobile OS version such as iOS and Android OS version. This information is more informative than anything else since you can’t use it in a profiling policy.
cdpCachePlatform - If the device uses CDP, you can usually determine what model or type of device this endpoint is from here. While CDP is a Cisco proprietary protocol, many non-Cisco devices use it - VMWare would be a good example of a non-Cisco platform that uses CDP. An example of this would be “cisco AIR-AP3802I-B-K9” - From this example, I can see that it’s a Cisco 3802 access point.
cdpCacheVersion - If the device uses CDP, this can tell you the OS version it’s running and possibly more information on the model of the endpoint. An example might be “Cisco AP Software, C3700” - this example tells me it’s a Cisco 3700 series access point.
cdpCacheDeviceId - If the device uses CDP, this can tell you the hostname of the device. Sometimes the device type is in that hostname - for example, “rtr-4451” might end up being a ISR4451.
lldpSystemDescription - If the endpoint uses LLDP, you can glean the model number, operating system version, and other information from the LLDP system description. An example might be “Cisco AP Software, C3700” - this example tells me it’s a Cisco 3700 series access point.
lldpSystemName - If the device uses LLDP, this can tell you the hostname of the device. Sometimes the device type is in that hostname - for example, “rtr-4451” might end up being a ISR4451.
hrDeviceDescr - If SNMP is enabled on the endpoint and ISE does an SNMP NMAP scan, information such as the model number and manufacturer may be gleaned from the device description. An example might be “Canon iPF780” - This example (and Google!) tells me that it’s a Canon large printer and the model number is iPF780
sysDescr - If SNMP is enabled on the endpoint and ISE does an SNMP NMAP scan, we can get a great description of what type of endpoint this is such as “APC Management Center” or a similar description.
AD-Host-Exists - This will be markeed TRUE if it’s joined to the domain. I sometimes create sub-profiles if I want to specify the difference between something like
AD-Operating-System - If the endpoint is joined to the Active Directory domain and the AD probe is turned on, this probe will tell you what operating system is on the endpoint. An example might be “Mac OS X” or “Windows 10”
device-platform - If the endpoint is connecting on VPN with AnyConnect, ISE can gather additional device-platform information. The device platform might give you information on whether the endpoint is a Mac device (mac-intel) or Windows device (win)
device-type - If the endpoint is connecting on VPN with AnyConnect, ISE can gather even more information on the device type such as whether it’s a “MacbookPro” or “iMac” which can further be used for profiling.
Before we go jumping into our endpoint dump CSV, let’s take a step back and look at profiling logic. Profiles don’t have to be flat. You can nest your profiles to get more specific with models or endpoint types. I created the following crude graphic to illustrate:
Using the above logic, an endpoint can be profiled as a Cisco 7942 IP phone using nested profiles:
The endpoint first matches the root (Cisco-Device) profile by matching one of the listed rules in that profile.
If the endpoint meets the requirements for Cisco-Device, it can be further profiled as an IP phone if it meets one of the additional attributes listed under the Cisco-IP-Phone profile. This profile can only be matched against if the endpoint has already matched the parent profile (Cisco-Device). Otherwise, the endpoint won’t be evaluated against Cisco-IP-Phone.
After matching the Cisco-IP-Phone profile, the endpoint can further be evaluated and matched to the Cisco-IP-Phone-7942 profile based on having attributes that meet that Cisco-IP-Phone-7942 nested profile.
Of course not all attributes may be weighted the same. Every time a profiling rule is matched, it increases the certainty factor of whether this device type is the profile in question. You get to decide what that minimum certainty factor should be for the profiles you create. When creating a custom profile, you can manually set the minimum certainty factor for this profile and the certainty factor for each rule you create. You can state how much the certainty factor will increase based on the matched rule or attribute. If a endpoint matches two different profiles, it’ll match to the one that it has the highest certainty factor with. In order to make sure your custom profiles are weighted heavier than the built-in Cisco profiles, it’s recommended to heavier certainty factors - 1000 or more would be great.
Once again, let’s illustrate how certainty factors work with my crude design skills:
In the above diagram, this is how an iPad is matched to the iPad profile:
An endpoint connects to the network and first matches the Apple-Device with a certainty factor of 80. Since the minimum certainty factor for this profile was 40, this endpoint fell under the Apple-Device profile. ISE detecting the following attributes:
User-Agent contains “Mac” (+40 to the certainty factor)
The DHCP requested parameters matched the fingerprint of an iOS device (+40 to the certainty factor)
This endpoint then matched the Apple-iOS-Device profile that was nested under the Apple-Device profile with a certainty factor of 100. This was due to the ISE detecting the following attributes:
User-Agent also contained “iPad” (+50 to certainty factor)
DHCP requested parameters matched the fingerprint of an iOS device (+50 to the certainty factor)
Finally, the endpoint matched the iPad profile meeting just the certainty factor of 100 for that nested profile. It did so evaluating the following attributes:
User-Agent contained “iPad” (+50 to certainty factor)
host-name contained “iPad) (+50 to certainty factor)
Hopefully that wasn’t too confusing. The key takeaways from the above that I want to ingraine in anyone reading this are:
You can use nested profiles to get more specific with your endpoint types
In order to match to a nested profile, the endpoint needs to match the parent profiles first.
Since all attributes are not created equal, you can weigh those attributes in the profile to have greater value placed on certain attributes over others.
When creating custom profiles, make sure the certain factor and the weight of the attributes are higher (100 or greater) so your custom profile is preferred over any built-in Cisco profile.
Going back to our endpoint dump, if you removed all the columns except the ones mentioned above, it probably still looks like a mess:
The next thing I like to do is clean up the view of this monster spreadsheet. I would recommend highlight the top title row on the Excel spreadsheet. Then on the top of Excel, navigate to View.
Then click on Freeze Panes and choose Freeze Top Row from the drop-down. This will keep the top row in view no matter how far you scroll down the spreadsheet.
The next thing I like to do is highlight everything by clicking on the triangle on the top lefthand area.
Under Home on the top bar, click on Wrap Text to ensure that the text is wrapped in the cells. You might need to re-size the columns to make it a little more readable.
Now the cells should be a little more human readable but the spreadsheet still isn’t very organized as you can see from below:
What I recommend doing is selecting any column on the page:
Then navigate to Data on the top menu and clicking Sort.
From the sort warning pop-up, choose the option Expand the Selection. Be sure to check the box for My data has headers. I usually like to sort my data dumps as such:
OUI
dhcp-parameter-request-list
dhcp-class-identifer
User-Agent
After I’ve formatted and organized my CSV file, I can usually zoom out of my spreadsheet and identify like attributes with greater ease. Let’s use the below endpoints as an example.
All of the endpoints are showing as being identified as “Unknown” in ISE but we can notice a couple things right off the bat that are all similar among all the endpoints:
The MAC OUI appears to be AAEON technologies - a manfacturer of SCADA and PLC devices
The dhcp-class-identifier further identifies the device as a PLC device
The endpoints are all requesting the same dhcp-parameter-request-list
With this information, we can easily create a custom profile using tying those three attributes together.
Once you have the endpoints dumped and organized, it’s all about being able to identify the attributes that are common between the same type of endpoints or attributes that identify what kind of endpoint it is. Let’s take a look at another part of the endpoint dump.
From the above screenshot, you can breakdown the attributes as such:
Green - Identifies that this is an Apple device of some type
Purple - Identifies that it’s an iOS device specifically
Yellow - Identifies what type of iOS device it is: iPad
Using the different attributes, you can either create one big massive profile or you can nest your profiles to get more granular with your device types.
After you organize what attributes you will use for your custom profile, you would build the profile in ISE under Policy>Profiling. You can watch me create a custom profile on video here if you need to see a basic example.
Hopefully this blog post has broken down some of the mystery behind profiling and given you some tips on how to better organize and identify attributes so you can use them in profiling.