ISE Profiling Query

[dngore]

Hi,

We are looking for ISE opportunity for Bank customer. They have some queries and need clarity on the following

1. ATM machines  Profiling Only
   1. These non-802.1x devices today are connected to an L3 device (IDU). They have static IP address.
   2. Is there a way to profile these devices ? Since the  ATM is connected to a non-cisco switch , can Netflow (from the central location ) be used to profile an ATM as they use specific port numbers
   3. Document states that ISE needs both IP and MAC association to end points- is this needed for profiling an ATM like device which is connected to a device from where there is no way to get the endpoint MAC
   4. The requirement here is to only profile the asset as an ATM, not really  authenticate it
2. Switch replacement
   1. If a currently 802.1x switch fails and is replaced with an RMA’ed switch / new switch  is introduced , it is possible that the new switch may not get 802.1x configs (human errors). In such a scenario is there a way to identify this ?
   2. Assuming the new switch does not get an 802.1x/ RADIUS configs, can we depend on the Netflow probe to understand that new endpoints have been introduced in the network
3. Reports
   1. If a current NAD is powered off, is there a way to figure out that the NAD is no longer available ?? Any report that will give this to us

[howon]

1. Only MAC is needed to be added to the endpoint DB. However, IP is required to connect between MAC address to any of the L4+ profile attributes. If this is Cisco switch, then ip device tracking can be enabled to send IP to ISE via RADIUS Accounting. Once  IP is available to ISE, Netwflow or NMAP may be used to further enhance profile. However, Netflow is generally not recommended due to amount of events ISE has to process.

2. There are certain mis-configurations that ISE can identify and report, but if ISE is not getting any events in the first place the answer is no.

3. Not natively. It may be possible if you have 3rd party SIEM or syslog receiver to craft event when certain switch does not send authentication request. You can couple that with periodic RADIUS keepalives or reauth to find out the ones not sending any request.

[Craig Hyps · Accepted solution]

In addition to Hosuk's response, these questions were answered in detail on an internal communication from Khizar Alimia. Please do not replicate queries across teams as it exhausts available resources to support entire community. My responses to Khizar.

1. ATM machines  Profiling Only

1. These non-802.1x devices today are connected to an L3 device (IDU)
2. Is there a way to profile these devices ? Since the  ATM is connected to a non-cisco switch , can Netflow (from the central location ) be used to profile an ATM as they have specific port numbers

  [Craig] It is not clear if the ATM is connected to L3 device which is then connected to non-Cisco switch, then to 2960?  Or if treating the L3 device as the “non-Cisco” device which is connected to 2960. 

1. ATM -> IDU -> non-Cisco switch -> 2960
2. ATM -> IDU -> 2960

If A, then it may be difficult to authenticate all devices depending on what all is attached to non-Cisco switch.

If B, then may be simpler, especially if all devices interconnected from IDU are ATMs (or only one ATM per IDU).

As there is an L3 device between ATM and switch, will the 2960 see individual MAC addresses of ATM(s), or just the L3 device (think router where switch only see L2 MAC address of the router and numerous IP addresses from things behind it.  If only one MAC and one IP visible, then ISE could profile the IDU and grant that port access needed for ATMs.

If there is a way to profile the ATMs, I am sure we can find it, but actual connection between ATM and 2960s will determine what we (or any vendor) can detect for classification. Also connection type will dictate authentication options.

3. (doc states that ISE needs both IP and MAC association to end points)- is this needed for profiling an ATM like device which is connected to a device from where there is no way to get the endpoint MAC

[Craig] ISE learns MAC addresses from RADIUS auth, DHCP, and SNMP.  IP addresses can be learned from RADIUS Accounting, DHCP, or SNMP.  IP addresses allow ISE to leverage additional probe data from DNS and NMAP.  Netflow is technically possible but typically not recommended today due to the additional requirements on 1) Netflow capable devices (which I don’t see here) and 2) Impact on profiling capacity.  Endpoints do not absolutely require IP, but it definitely helps.  In any case, the above methods should be able to acquire MAC and IP address info to leverage most/all probes.

4. The requirement here is to only profile the asset as an ATM, not really  authenticate it

  [Craig] If enable a port for RADIUS auth, then may not have a choice, but see responses to #2 above since not certain if 2960 will even “see” the actual ATMs depending on how connected behind the IDU. 

2. Switch replacement
   1. If a currently 802.1x switch fails and is replaced with an RMA’ed switch / new switch  is introduced , it is possible that the new switch may not get 802.1x configs (human errors). In such a scenario is there a way to identify this ?

  [Craig] There are ways to bootstrap a switch configuration using auto-discover or other network management tools.  This is really not an ISE issue.  ISE will not directly detect if switch is misconfigured for 802.1X.  I think this is better addressed by tools like Prime to configure switches.   

2. Assuming the new switch does not get an 802.1x/ RADIUS configs, can we depend on the Netflow probe to understand that new endpoints have been introduced in the network

[Craig] The switch must be configured for communication with ISE in some manner.  If RADIUS not configured, then at a minimum the switch must have SNMP enabled to allow ISE to query switchports and detect new things that connect to the network.  Of course, without RADIUS configured, ISE cannot enforce access control on the switch.

If switch is not properly configured after RMA, then expect more fundamental issues with network connectivity and manageability.  Even if compare approaches from some competitors, the switch would minimally have to have proper SNMP or SSH access configured, so the assumption that switch should still secure network if improperly or partially configured is not a reasonable assumption. A process need to be in place regardless of vendor implementation to ensure switch is properly configured after replacement.

3. Reports

1. If a current NAD is powered off, is there a way to figure out that the NAD is no longer available ?? Any report that will give this to us

[Craig] I would rely on standard network monitoring tools for this.  All customers should have a network management and monitoring system that flags to console and reports when any piece of infrastructure is no longer available or down.  Typical case is that net monitoring is looking for activity or response to simple ICMP pings or SNMP queries to detect as soon as network is down.  I am sure they have tools that alarm on network going down.  Connectivity status is fundamental to net ops.