Cisco AI Endpoint Analytics solution to MAC/Attribute Spoofing

[kthiruve]

• Endpoint Profiling overview:
• Profiling functionality and efficacy:
• System rule, custom rule, and AI rule
• Probes, labels and confidence level
• MAC Spoofing and Attribute Spoofing detection:
• AI Spoofing detection:
• Detection of suspicious behaviour due to MAC spoofing/Attribute spoofing using ML models
• Concurrent MAC detection and MAC Spoofing
• Changed profile labels
• Conclusion:

Endpoint Profiling overview:

Endpoint Visibility is the first step towards securing and protecting an endpoint. IT Administrators has challenges keeping up with managed and unmanaged endpoints and IOT devices in the network. In fact, around 30% or more of these unmanaged endpoints are unknown to IT administrators.

Cisco AI Endpoint Analytics provides capabilities that detects and profiles especially unmanaged endpoints/IOT devices and assigns different labels such as (endpoint type, hardware model, manufacturer, OS type). Multi-label classification brings in an added advantage by providing ability to categorize an endpoint in multiple ways using different profile labels that can be used as context in enforcing access policies with policy enforcement points such as Cisco ISE.

Here is a diagram showing multiple profile labels assigned to the same endpoint

Cisco AI Endpoint Analytics application is part Cisco DNA Center and included in DNA-C Advantage Licensing.  It gathers telemetry from the network and other sources to profile the endpoint. Endpoint Analytics uses key sources for gathering endpoint telemetry.

1. Metadata collected using Deep Packet Inspection (DPI) on wired/wireless using Cisco Catalyst 9k access switches and Catalyst 9800 wireless controllers. For third party or legacy support for DPI is with Cisco Traffic Telemetry appliance
2. ISE discovery mechanism and probe data including information about mobile devices from MDM vendors
3. Asset attributes Service NOW (Configuration Management Database)

Profiling starts to happen when endpoints start communicating to the network, the network devices gather endpoint telemetry, makes quick determination where possible and forwards the asset information to Endpoint Analytics application in DNAC. Endpoint Analytics uses profiling rules that are updated frequently to find the best match and assigns profile labels to IT and IOT devices.

Endpoint Analytics sends these labels and other context over to ISE for assigning access policies. From ISE 3.1 and DNAC 2.2.3.x these labels are exposed in ISE Authorization policies in authorization conditions. These authorization policies make the policy decisions to enforce right level of network access based on the endpoint context in an enterprise.

Note: ISE admins using (pre-ISE 3.1) need to create a custom profile to utilize these attributes.

Profiling functionality and efficacy:

AI Endpoint Analytics uses system, custom and AI generated profiling rules to assign endpoints profile labels.

System rule, custom rule, and AI rule

Endpoint Analytics comes with a large set of default system rules after DNAC installation. These system rules get updated from NBAR cloud on a continuous basis and can be scheduled to do so from Endpoint Analytics configuration. This helps Endpoint Analytics to cater to newer protocols as well as download new sets of rules for variety of IOT devices. It also helps to improve the efficacy of the profiling.

Beyond system rules, admins can create custom rules to fine tune/change the profile labels. An example is with CMDB attributes, if an admin knows specific information about endpoint and needs to categorize the endpoint based on that information from CMDB, they can create a custom rule.

Admins can also create AI rules from AI proposals that shows AI/ML endpoint grouping to identify unique endpoints that were previously unknown. AI rules helps customers find groups of endpoints that have common attributes, automate the rule creation and provides suggestions to admins to help them choose the correct labels for different endpoints. Suggestions are automatically shown using labels gathered from similar group of endpoints from different customers.

to match the profiling rules

1. Custom rules
2. System rules
3. AI rules

If you have few specific endpoint information such as (MAC Address, Endpoint labels), you can register the endpoints using the registration form or using a CSV file from the application.

Probes, labels and confidence level

Profile labels are assigned based on best match, the confidence level of each label is tracked internally to trigger alert when a profile label changes due to spoofing or due to other factors (for e.g: If an VM endpoint is behind the NAT’ed device).

When Endpoint Analytics receives information from the first that matches one or more profile rules, the result will be an assignment of profile labels. When it receives information from additional probes, the confidence level increases. (to a scale of 100).  Probes that helps identify multiple labels can increase the overall confidence level of the profiling label assigned.

Confidence level is based on how deterministic the protocol/attribute is. This uses few criteria such as consistency in value of attributes, ease of tampering, the attribute/value alignment with other protocols. There are weights associated with each probe and attribute that are used to calculate confidence level.

For e.g.: DHCPClassIdentifier is a stronger probe since the values are consistent and not jittery, cannot be tampered with easily by average user. User agent is a weaker attribute since a user can modify it easily. LDAP or NetBIOS can be a strong probe to recognize operating system.

Note: Endpoint Analytics does not expose the confidence level in the UI. This is internal to Endpoint Analytics as of now.

Profiling is based on best effort/best match and is vulnerable to spoofing attempts especially in wired environment. In Endpoint Analytics we have tools that detect these spoofing attempts.

 MAC Spoofing and Attribute Spoofing detection:

In MAC Spoofing a bad actor tries to spoof the MAC address of a legitimate endpoint in the network. Attribute spoofing is when someone tries to use an attribute to spoof a legitimate attribute for e.g.: DHCP Class ID thereby posing as a legitimate endpoint. In both the cases the goal is to gain the same level of access by fooling the network and by posing as a legitimate endpoint. Cisco AI Endpoint Analytics has 3 capabilities to prevent this.

AI Spoofing detection: 

Overview:

AI spoofing detection assists in identifying unauthorized endpoints impersonating legitimate endpoints in the network using MAC and probe spoofing techniques.  This is done using cloud-generated behaviour models for different types of endpoints. These models are trained using crowdsourced netFlow data for a known endpoint type that is functioning under normal operating conditions. When an unauthorized endpoint generates traffic that deviates from the machine learning model, an anomaly is triggered with a low, medium, or high probability of detecting suspicious behaviour.  The presence of an anomaly and probability of detection is represented as one of the inputs to the overall Trust Score of the endpoint.  

 

Detection of suspicious behaviour due to MAC spoofing/Attribute spoofing using ML models

To recap, ML models are built based on behaviour of a certain class of endpoint or device. This will include the overall characteristics of a class of device and is not a sampling of just one make or model. For e.g.: IP Phone is known to generate SSL traffic and traffic sent and received using SNMP is considered normal. However, if IP Phone is speaking to a destination that is external using SSL, that traffic pattern is considered abnormal.

received from the network with the generated ML models. NetFlow records is typically aggregated in Cisco DNAC in short intervals (5 mins).  To reduce false positives ML needs 10 flows that deviates from the existing model to trigger an alert that may take a few more minutes.

It is also imperative that any behavior based model in a passive monitoring tool will need traffic from the endpoints to understand the behavior of the endpoint. A change in the behavior which is atypical of an endpoint type or class is used to identify anomalies. If an endpoint is silent and does not send any traffic or only sends DHCP traffic and is quiet afterwards, behavior based models will wait for more traffic to be generated to identify anomalies.

Please see the configuration steps to enable this functionality by following this community article.

In cases, where you see some traffic from endpoints (such as DHCP or SNMP) it is possible to detect spoofing attempt using additional features such as “Concurrent MAC detection”

Concurrent MAC detection and MAC Spoofing

Overview

This feature is meant to discover and alert on situations where same MAC address is seen simultaneously on the network in more than one location. This functionality is supported for wired endpoints with Cat9k access switches and it supports wired/wireless use case.

This can detect MAC addresses appearing concurrently across different switchports or across different switches. You need to enable ‘NBAR’ on the switches from Cisco DNAC for this. You don’t need any additional configuration for this. This functionality will work for all types of traffic (TCP/UDP) seen by the switch port.

Please see the Cisco AI Endpoint Analytics deployment guide for additional details to enable “Network Based Application Recognition (NBAR)” which is the sensor component in the switches/wireless controllers.

 This functionality looks at two aspects.

1. Collisions: How many times MAC addresses appear exactly at the same time (sampled every minute) on different ports or different switches over a 15 mins period.
2. Transitions: How many times MAC address keeps appearing, not at the same minute but keeps flipping back and forth, across different switchports or different switches over a 15-minute period.

MAC spoofing anomaly detection using the functionality:

MAC spoofing using concurrent MAC detection feature has two use cases if spoofing happens within the same network device.

1. Number of collisions are tracked to trigger an alert. Collisions have to be greater than 1 in a 10mins period for this to happen. This is based on the traffic generated by endpoint.
2. Alert is also triggered If Endpoint Analytics sees 4 or more transitions (This is when MAC address appears in more than one switchport for at least 5 times at different instance of time based on the traffic from the endpoint) within a 15-minute period from endpoints connected to the same switch.

Example: MAC address A is seen in switchport 1 and 2 on the same switch where anomaly is triggered.

Timeline in minutes

Endpoint	1 min	2 min	3 min	4 min	5 min	6 min	7 min	8 min	9 min
Legitimate	Active		Active		Active
Risky	Active			Active

You can see that there is a collision in the first minute. There are only 2 transitions, one between the 3^rd and 4th and second between 4th and 5th minutes. This will not be considered as an anomaly since there is only one collision.  This information is sent to DNAC every 15 minutes.

Example 2: MAC address A is seen in switchport 1 and 2 on the same switch where anomaly is triggered.

Timeline in minutes

Endpoint	1 min	2 min	3 min	4 min	5 min	6 min	7 min	8 min	9 min
Legitimate	Active	Active	Active		Active		Active
Risky	Active	Active		Active		Active

You can see that there is a collision in the first and second minutes. Additionally, there are 4 transitions as you can see between 3rd to 4th, 4th to 5th, 5th to 6th and 6th to 7th minutes. This will be considered as an anomaly based on collisions alone. However, if there were another transition, for example in the 8th minute, when a suspicious(risky) endpoint appears an alert would be triggered. This information is sent to DNAC every 15 minutes.

Endpoint Analytics tracks the switch ID, switchport and VLAN and presents that in the Endpoint Analytics UI for admins to take action based on this alert. This anomaly/threat triggers a low to medium Trust Score based on the nature of traffic, number of hits etc.

If MAC spoofing using concurrent MAC detection happens across the network device it will take around 15min to 30 min to trigger an alert.  

Note: For MAC spoofing across network devices alert is triggered if number of collisions/transitions is greater than 2 (3 or more) AND average time between those collisions/transitions is not greater than 10 min (at least 3 per 30 min in average). No alert is triggered if it is more than 10 minutes. This is to reduce false positives and allow users to move from one location to another location without causing alerts

 

Changed profile labels

Overview

Profile label changes may indicate and underlying condition where there is a possibility of a MAC spoofing, attribute spoofing or the endpoint is running a NAT’ed device behind etc. Endpoints need to send traffic to the network devices for the functionality to trigger an alert on changes in profile labels.

Significant change in any one of the four-profile label assigned will be considered as anomaly for triggering an alert. For e.g.: Windows OS to Linux or to IOS.

You need to enable sensor component ‘NBAR’ on the switches and wireless for this. You don’t any additional configuration for this.

Please see the Cisco AI Endpoint Analytics deployment guide for additional details to enable “Controller Based Application Recognition (CBAR)” from DNAC UI. This enables the sensor component in the switches/wireless controllers.

How is anomaly detected?

Protocols and attributes are assigned weights to track the confidence level as described above. Confidence level of an endpoint is tracked through the life of an endpoint.

Now, if an unauthorized/illegitimate endpoint connects using the same MAC address, endpoint information is gathered from attributes sent via the protocol. The confidence level of profile label assigned is recalculated based on the new set of protocol/attributes that could be either strong or weak. If the spoofing endpoint sends a stronger attribute with a set of endpoint information different from the one Endpoint Analytics learnt earlier and if this results in a significant change (e.g.: Windows OS to Linux), then this is considered as anomaly and an alert is generated.

Example:

Say, endpoint A is categorized as Medical Device with an endpoint type of CT Scanner that is derived out of probes such as DICOM with few attributes that provides high confidence level.

If endpoint B, which is an Apple IOS device, spoofs the MAC address to gain access, it starts sending DHCP (including DHCP Class ID attribute) and HTTP traffic (User agent attribute). At this point, this will change the ‘Endpoint type’ profile label and trigger an alert.  This is because the previous confidence level in label assignment using DICOM, was changed by a strong attribute such as DHCP Class ID along with the weaker User agent attribute that increased the confidence level beyond what was identified with DICOM.

However, if the Apple iOS device does not send DHCP attributes, and the user triggers http traffic only, if the device type information is arrived from http user-agent (considered as a weak probe attribute), this may not trigger a change in profile label at all. In this case Endpoint Analytics does not trigger an alert for this type of anomalies. This behaviour is built-in to avoid false positives, endpoint misconfigurations etc. In this case more protocol/attribute information from the Apple iOS device will be collected till the system surpasses the previous confidence level and alert will be generated only after that.

Conclusion:

Spoofing attempts can be detected using AI Spoofing Detection, Concurrent MAC detection and Changed profile labels. The first two will address majority of MAC spoofing use cases within and across wired/wireless infrastructure where endpoint generates traffic. Attribute spoofing can be detected with AI Spoofing detection and Changed profile labels. Overall, these three functionalities can be important security tools that can be used against MAC spoofing/Attribute spoofing.

This is currently supported in wired environment with Cat9k access switches and between wired and wireless with Cat9800 wireless controllers.

Profiling using deep packet inspection using NBAR in Wireless Flexconnect mode is added in IOSXE 17.6.x. Support for SDA network with Fabric in wireless is supported in IOSXE 17.7 with Cat9800 Wireless controller and supported AP’s in both local and Flexconnect with DNAC 2.2.3.