CCNP Security SISAS 300-208 Official Cert Guide (2015)

---

VMware Configurations to Allow Promiscuous Mode

As shown in Figure 15-18, VMware vSwitches will reject promiscuous mode by default. To use SPAN-type probes with ISE, you must configure the vSwitch to allow promiscuous connections.

Figure 15-18 Default vSwitch configuration.

To modify the configuration and enable promiscuous traffic, do the following:

Step 1. Highlight the vSwitch and click Edit.

Step 2. Click on the Security tab.

Step 3. Change the Promiscuous Mode drop-down to Accept, as shown in Figure 15-19.

Figure 15-19 Promiscuous vSwitch setting.

Profiling Policies

Collecting the data for profiling is only part of the solution. The other aspects are to have endpoint signatures and a policy engine to compare the collected attributes to those signatures; this will lead to the assignment of the endpoint profile.

The profiling engine works a lot like an Intrusion Detection System (IDS), where traffic is compared to a set of signatures to identify suspicious activity. The profiling engine has hundreds of built-in signatures, called profiles, which are designed to match when certain attributes exist. Additionally, much like an IDS system, an update service enables the engine to download new signatures.

Profiler Feed Service

Although ISE comes with a large and comprehensive list of signatures to classify endpoints (profiles), many devices are produced almost daily (think of the next smart phone or version of the phone’s OS). In addition, a constant stream of new profiles is created by Cisco that should be shared to the ISE deployments of the world.

That’s why Cisco created a profiler feed service. New devices are released to market, and Cisco creates profiles for them. New profiles are created by Cisco partners (manufacturers). Cisco also has a team that focuses on profile creation. The ISE profiler feed service is used to distribute these new profiles after the Quality Assurance team has approved them.

Configuring the Profiler Feed Service

Configuring the feed service is straightforward. Once enabled, it will reach out to cisco.com at the set time interval and download any published profiles. It has an option to send an email alert to the administrator when an update occurs, an undo button for reversing the latest update, a link to view a report on the latest updates, and lastly a section to send your information to Cisco to help with understanding how many customers are using the feed service.

Figure 15-20 shows an enabled and configured Profiler Feed Service screen, which is located under Administration > Feed Service > Profiler.

Figure 15-20 Configured profiling feed service.

When you don’t want to wait for a configured interval for the feed service to run, you can click an Update Now button. Be cautious with manually updating the profiles during a production workday. When the profiles are updated, it will cause all the endpoints in the endpoint database to be compared against the new list of profiles. In other words, a complete re-profiling of endpoints will occur, which can be very processor intensive.

Verifying the Profiler Feed Service

The easiest way to verify whether the feed service is operational is to click the Go to Update Report Page link on the configuration screen, located at Administration > Feed Service > Profiler, as shown in Figure 15-21.

Figure 15-21 Go to update report page link.

Clicking that link opens another window with the Change Configuration Audit report prefiltered for the feed service related entries, as shown in Figure 15-22.

Figure 15-22 Change configuration audit for feed service.

Because ISE must be able to reach cisco.com for the profiling feed service to function, you might need to configure ISE to use a proxy server to reach the Internet. This optional configuration is located at Administration > System > Settings > Proxy, as shown in Figure 15-23.

Figure 15-23 Proxy setting.

Endpoint Profile Policies

The profiling service probes collect attributes of endpoints, while the profile policies are similar to signatures, which define the endpoint profiles themselves. For example, to match an Apple-Device profile, the endpoint must have a MAC address beginning with Apple’s OUI.

Each endpoint profile policy defines a set of attributes that must be matched for a device to be classified as that endpoint type. ISE has a large number of predefined profile policies, and you have just read about the feed service that’s used to update those policies and provide new ones.

The endpoint profile policies can be viewed by navigating to Policy > Profiling, as shown in Figure 15-24.

Figure 15-24 Policy > Profiling.

Each profile is listed as Cisco provided or Administrator Modified. This classification ensures that the feed service will not override one that has been changed by the administrator.

Profiles are hierarchical and inclusive in nature, and you can pick any level to use within your authorization policies, enabling you to be very specific or broad in your rules. Examining Figure 15-25, you see the existence of a parent policy named Cisco-Device with a child policy named Cisco-IP-Phone, and that has another child policy named Cisco-IP-Phone-7940 (Cisco-Device > Cisco-IP-Phone > Cisco-IP-Phone-7940).

Figure 15-25 Cisco-Device parent profile.

When building an authorization policy, you can choose to use the profile at any point in that chain. If you were to select Cisco-Device, it would apply to all devices classified as Cisco-Device as well as anything classified as a child profile of Cisco-Device.

Figure 15-26 graphically displays the way a profile hierarchy is built within ISE.

Figure 15-26 Profiling hierarchy illustrated.

To serve as further examples, there is a predefined authorization rule named Profiled Cisco IP Phones. This rule permits full access to the network and assigns permission to join the Voice VLAN for all devices that that are profiled as a Cisco-IP-Phone parent profile and any of the child profiles. Figure 15-27 shows this rule.

Figure 15-27 Default Profiled Cisco IP Phones rule.

Continuing to examine policy hierarchy and how it works, let’s dig into a specific example. In this sample network, there is a Cisco 7970 IP Phone, and that phone has been granted access from the Profiled Cisco IP Phones default authorization rule. This permits all devices matching a Cisco-IP-Phone profile Identity Group.

Start by examining the endpoint attributes and comparing them to the profiling policies.

Step 1. Navigate to Administration > Identity Management > Identities > Endpoints. Locate the 7970 phone, as shown in Figure 15-28.

Figure 15-28 Filtered endpoint identities.

Step 2. Click that endpoint to enter into the endpoint details.

Step 3. You will immediately see that the Policy Assignment (profile of the device) is Cisco-IP-Phone-7970. However, the Identity Group Assignment is Cisco-IP-Phone. Additionally, the AuthorizationPolicyMatchedRule is Profiled Cisco IP Phones, which means the correct authorization rule is being matched, as shown in Figure 15-29.

Figure 15-29 Endpoint details.

Step 4. Scroll downward in the endpoint details and see that the EndPointSource is the RADIUS probe, as shown in Figure 15-30. That means the RADIUS probe provided us with the most information needed to classify this device (which must have arrived from the device sensor on the NAD).

Figure 15-30 Endpoint details: EndPointSource.

Step 5. Continuing down the list of attributes, notice the CDP cached data from the switch that was sent to ISE via the RADIUS probe (see Figure 15-31).

Figure 15-31 Endpoint details: CDP data.

You can see these attributes of the endpoint, but how is that used within the profiling policy? To answer that question, examine the profiling policy hierarchy for the endpoint.

Step 6. Navigate to Policy > Profiling > Cisco-Device. Cisco-Device is the top level of the profiling hierarchy for this endpoint, as shown in Figure 15-32.

Figure 15-32 Cisco-Device profiling policy.

Using Figure 15-32 as a reference point, please take note of the following details:

The minimum certainty factor of this profile is 10. Certainty factor is an aggregate value between 1 and 65535. Each of the conditions at the bottom of the policy that are matched will add up to equal the endpoints certainty value. The higher the value, the more certain ISE profiler is that an endpoint matches the specific profile.

Note that the OUI is CISCO SYSTEMS, INC., shown in Figure 15-33, and that will match the condition for Cisco-Device shown in Figure 15-34. This is one possible mapping that meets the minimum certainty value and should match the endpoint to this parent policy.

Figure 15-33 OUI of the endpoint.

Figure 15-34 OUI condition in Cisco-Device policy.

A Network Scan (NMAP) Action is set to OS-Scan. For this action to occur, there must be a condition in the profile that has a result to trigger the network scan. Figure 15-35 displays this mapping of the condition to the action. Figure 15-34 displays the contents of the condition, meaning that if the MAC OUI contains CISCO, then run the NMAP Scan type defined.

Figure 15-35 Network scan action and condition with scan result.

This profiling policy has a tremendous number of conditions. Most of them add a certainty value of 5 or 10. The Certainty Value needs to be only a minimum of 10 to match the profile, so matching any one of these conditions will most likely equal a match.

Step 7. Navigate to Policy > Profiling > Cisco-Device > Cisco-IP-Phone, as shown in Figure 15-36, to examine the conditions used for this policy.

Figure 15-36 Cisco-IP-Phone profiling policy.

Using this profile as a reference point, please take note of the following details:

To even be compared to this profiling policy, the device must have first matched its parent policy. In this case, the device had to match the Cisco-Device policy before these conditions would ever be examined.

The minimum certainty factor of this profile is 20, as shown in Figure 15-36. Certainty factor is an aggregate value between 1 and 65535. Each of the conditions at the bottom of the policy can add more certainty to this profile, if they are matched.

The CDP Cache shown in Figure 15-31 shows that the cdpCachePlatform attribute was sent as Cisco IP Phone 7970.

Figure 15-37 shows that the Cisco IP Phone profile policy uses a condition looking for the cdpCachePlatform value to contain Cisco IP Phone and increase the certainty by 20.

Step 7 examined Cisco-IP-Phone, but what does it take to get one step further, to reach the final Cisco-IP-Phone-7970 profile?

Figure 15-37 cdpCachePlatform condition.

Step 8. Navigate to Policy > Profiling > Cisco-Device > Cisco-IP-Phone > Cisco-IP-Phone-7970, and we will examine the conditions used for this policy (see Figure 15-38).

Figure 15-38 Cisco-IP-Phone-7970 profile.

Using Figure 15-38 as a reference point, please take note of the following details:

To even be compared to this profiling policy, the device must have first matched its parent policy. In this case, the device had to match the Cisco-Device and Cisco-IP-Phone policy before these conditions would ever be looked at.

The profile itself has only one condition, and that condition is that the cdpCachePlatform attribute is Cisco IP Phone 7970. Figure 15-31 has shown that it is.

Rarely would you build an authorization policy that is specific to the point of the model number of the Cisco Phone; instead you would just use the Cisco-IP-Phone parent policy in your authorization policies.

Logical Profiles

When ISE 1.0 was first released, it was quickly requested by many customers to have a grouping of profiles that are not hierarchical. For example, many requested to create a profile group named IP-Phones that contains all the individual profiles of IP phones, Cisco and non-Cisco alike.

ISE 1.2 answered that request. With that release, Cisco introduced the new concept of logical profiles. These logical profiles are exactly what customers requested: a grouping of profiles.

To examine the only prebuilt logical profile in ISE, navigate to Policy > Profiling > Logical Profiles. Select IP-Phones, as shown in Figure 15-39.

Figure 15-39 IP-Phones logical profile.

Notice in Figure 15-39 that the logical profile contains Avaya, Cisco, Nortel, and generic IP phone profiles.

ISE Profiler and CoA

When using an endpoint profile as an attribute within your authorization policy, you will be providing differentiated results for specific profiles. However, there is often a “chicken and the egg” phenomenon happening simultaneously. You cannot provide the right access to a device without knowing what that devices is, yet you cannot find out what the device is without providing some level of access. The endpoint must be active on the network for ISE to identify the endpoint profile.

Enter the concept of change of authorization (CoA), which was introduced to you in Chapter 6. Without CoA, the only time a policy server such as ISE is permitted to send a command to the NAD is during a response to an authentication request. This created numerous issues because there would not be a way to disconnect a bad actor from the network or change the level of access an endpoint is permitted to have based on a newer data that has been learned at the policy engine. The current authorization to the network would have to sustain until the next time the endpoint has to authenticate.

Because the authorization policy can be configured to send different results for an endpoint before it is profiled and then send another level of authorization after the endpoint profile becomes nailed down further and the final result after the endpoint profile is definitely known, you cannot wait for the next authentication request each time. Instead, the profiling engine can use CoA to change the level for each state the endpoint goes through.

There are two main areas for configuring CoA with profiling. A global setting enables CoA for profiling in the ISE deployment, and a CoA can be configured on a per-profile basis.

Global CoA

To enable CoA for profiling in the ISE cube, and to configure the CoA type used by profiling globally, navigate to Administration > System > Settings > Profiler, as shown in Figure 15-40.

Figure 15-40 Profiler global settings.

As shown in Figure 15-40, the default setting is No CoA. Click the drop-down list, as shown in Figure 15-41, to see the choices: Port Bounce and Reauth.

Figure 15-41 Profiler CoA types.

The Port Bounce CoA shuts down the switch port and then performs a no shutdown to reenable it. This causes the link state to change, simulating the unplugging and plugging in of network cable. The benefit to this type of CoA is that many devices will try to renew their DHCP assigned IP addresses when the link state changes. Additionally, there is a built-in failsafe to never send a Port Bounce when more than one MAC address is seen on the switch port. That failsafe is in place to ensure there is no negative impact on IP telephony. When more than one MAC address exists on the switch port, a Reauth is sent instead.

The Reauth CoA instructs the NAD to initiate a new authentication to the endpoint, sending another EAPoL Start message to trigger the supplicant to send the credentials again. In the case of MAB, however, the NAD resends a RADIUS authentication with the endpoint MAC address as the identity credential. Either way there is a new authentication, but that authentication maintains the same authentication session ID. By maintaining the session ID, ISE is able to tie together the multiple states of the endpoint.

Regardless of the CoA type used, ISE has now forced a new authentication attempt so that a different authorization result can be sent to the NAD, providing the correct level of network access with the latest profiling information being used. However, setting a global CoA type to Port Bounce is not recommended. The safer bet is to use the Reauth option.

After the profiler CoA is enabled globally, a CoA is automatically sent for any endpoint that transitions from unknown to any known profile.

Per-profile CoA

ISE 1.2 added a new setting to profiles that enable an administrator to control her own destiny with CoA. This came about with the need to send a Port Bounce CoA for certain devices only, while using the global Reauth CoA for the remaining endpoints.

This is known as the per-profile CoA. When a CoA type is configured for a profile, it is used when an endpoint is classified as that profile type. The setting is shown in Figure 15-42.

Figure 15-42 Per-profile CoA.

As shown in Figure 15-42, a device profiled as a Xerox-Device will now trigger a Port Bounce CoA, causing the link to go down and back up again. This in turn triggers the endpoint to request a new IP address from the DHCP server. This is useful when a device is using MAB and needs to be assigned to a different VLAN.

Global Profiler Settings

Additional settings related to profiling are set at the global (system-wide) level, not just the global CoA type. These include the SNMP community strings for NMAP SNMP walks and the enable setting for endpoint attribute filtering.

Configuring SNMP Settings for Probes

The SNMPQUERY probe uses the SNMP community strings that are defined as part of the NAD entry under Administration > Network Resources > Network Devices. Each NAD could theoretically have a different community string.

As described in the Network Scan (NMAP) section, NMAP uses SNMP to examine endpoints. For this to function, ISE profiler must know which SNMP community strings to use. The community strings to use are configured within Administration > System > Settings > Profilerand are configured by listing each community string one-by-one with a comma separating each value. After they are saved, the two text boxes are erased; you then must click the Show button to see the configured strings, as displayed in Figure 15-43.

Figure 15-43 Global SNMP settings for NMAP probe.

Endpoint Attribute Filtering

ISE Profiler can and does collect a lot of data about endpoints. It stores all that data and replicates it to the other ISE nodes in the deployment. To help keep the replication traffic down, ISE has endpoint attribute filters, which are enabled at Administration > System > Settings > Profiling, as shown in Figure 15-44.

Figure 15-44 Endpoint attribute filter.

When the filtering is enabled, profiler builds a white list of attributes that are used in the existing profiler policies. In other words, the profiler examines every policy that is enabled and creates a list of attributes that are needed for all those policies. Only those attributes will now be collected and stored in the endpoint database.

Use of the endpoint attribute filter is highly recommended but only after a deployment has been up and running properly for an extended period of time. The reason it is not recommended for use immediately with an ISE install is to enable the administrator to have all the necessary attributes to build new profiles. If the list of collected attributes is filtered down, there might not be enough data available to create the necessary profiles.

Profiles in Authorization Policies

As you saw with the profiled Cisco IP phone authorization rule earlier in this chapter, the profile can be used as a condition of an authorization policy rule in the form of an identity group. Originally, ISE required an identity group to use any of the profiling policies in the rule; however, it has evolved into the ability to use the profile directly (called the EndPointPolicy).

Endpoint Identity Groups

Local identities within the ISE database can be in the form of user identities or endpoint identities. Some identity groups can contain multiple identities, although an identity (user or endpoint) can be a member of only one identity group at a time.

To create an identity group based on the profile, you simply select the labeled Yes, Create Matching Identity Group option on the profile, as displayed in Figure 15-45.

Figure 15-45 Create matching identity group.

If that option is selected, the matching identity group will be found under Administration > Identity Management > Groups > Endpoint Identity Groups (as shown in Figure 15-45).

Figure 15-46 Endpoint identity groups.

Even though endpoint identity groups were the way to go with ISE 1.0, the use of them for profiling has been deprecated in favor of using the actual endpoint profile or logical profiles directly in the authorization policy.

Therefore, starting with ISE 1.2, endpoint identity groups are used for a different purpose. They are used for more of a MAC Address Management (MAM) model, where you can create a static list of MAC addresses to be authorized specifically. For example, you could create a list of all Apple iPads that are owned by the company so they can be differentiated from personally owned iPads.

The Blacklist identity group is a perfect example of identity group usage in this manner. If a user were to lose his personal device, he would be able to log in to the MyDevices portal and mark a device as lost, as shown in Figure 15-47. This would immediately add the endpoint to the Blacklist group, as shown in Figure 15-48. The device would then be denied network access by default, as shown in Figure 15-49.

Figure 15-47 MyDevices: Mark endpoint as lost.

Figure 15-48 Blacklisted devices.

Figure 15-49 Default blacklist authorization rule.

From the MyDevices portal, selecting Reinstate moves the device from the Blacklist group to the RegisteredDevices group. Figure 15-50 shows the MyDevices portal, and Figure 15-51 shows the RegisteredDevices group.

Figure 15-50 MyDevices: Reinstate the endpoint.

Figure 15-51 RegisteredDevices endpoint identity group.

EndPointPolicy

Beginning with ISE 1.2, identity groups are no longer the way to apply policy based on the endpoint’s profile. Policy is now built with the actual profile through the use of the Endpoints:EndPointPolicy attribute.

To see the use of the profile in a policy, you will duplicate the existing NSP authorization rule and then modify that new rule to use the Android profile, which does not have a corresponding identity group.

From the ISE GUI, do the following:

Step 1. Navigate to Policy > Authorization.

Step 2. Duplicate the NSP rule.

Step 3. Add a new condition matching Android devices to the existing MSCHAP condition of Endpoints > EndPointPolicy.

Figure 15-52 shows the resulting authorization rule.

Figure 15-52 Authorization rule using the EndPointPolicy condition.

Throughout all of this, always keep in mind the simplicity of using logical profiles to streamline your authorization policies, and limit the number of individual EndPointPolicies that you need to add to your authorization rules.

Verify Profiling

There are a few key places to verify profiling operation. Most exist within the ISE GUI, and of course you should always examine the network device itself.

The Dashboard

The dashboard is always the first screen you see when you log in to the ISE GUI, as shown in Figure 15-53. Right on the dashboard are numerous places to look to see whether profiling is working.

Figure 15-53 The Cisco ISE dashboard.

Examining Figure 15-53, four areas of the dashboard are called out:

Profiled Endpoints Counter (1)—This counter shows the number of endpoints that have been profiled in the last 24 hours.

Profiler Activity Window (2)—This shows a bit more detail than the Profiled Endpoints Counter; it shows two different counters: last 60 minutes and 24 hours. It also lists the individual profiles in a color-coded graph and can be expanded. The entire window can be expanded to see more detail.

The Total Endpoints Counter (3)—This shows the total number of endpoints that have been examined by the MnT persona within the ISE cube. What makes this particular counter so interesting is what happens after you click it. This is examined in detail in the next section, “Endpoints Drill-down.”

Global Search (4)—This search bar enables you to search based on the profile, MAC address, or even username. This tool is covered in more detail in the section “Global Search.”

Endpoints Drill-down

Often thought of as the best kept secret in ISE, the Endpoints Drill-down tool is frequently overlooked or unknown. Just like the rest of the dashboard, it is part of the MnT persona (not the PSN persona) and therefore displays a result based on the logs sent from the PSN to the MnT node and not the actual endpoint database. Although these can often contain the same data, they can sometimes not match identically, due to log purging.

Regardless of where the data is sourced from, the tool is an excellent way to look into the profiled endpoints and verify that the profiling service is working. Figure 15-54 shows the Endpoints Drill-down tool that appears when you click the total endpoints counter (#3 in Figure 15-53).

Figure 15-54 Endpoints Drill-down.

Selecting items from the left side of the tool filters the list of endpoints, and each endpoint can be drilled into further on the right side of the tool. In addition, the endpoint list can be exported with the Export button in the lower-right corner.

Global Search

The Global Search tool is available from any screen within the ISE GUI. Typing in a profile name displays results that can be drilled into further. Figure 15-55 shows the use of the Global Search tool to find profiles containing “Apple.”

Figure 15-55 Global searching for Apple.

Selecting Apple-Device from the resulting list displays a more focused list of endpoints matching that profile, as shown in Figure 15-56.

Figure 15-56 Apple-Device.

Endpoint Identities

The ultimate source of truth about endpoints is the actual endpoints database. The graphical view of that list of endpoints is located at Administration > Identity Management > Identities > Endpoints. This brings up the endpoints table, and the profile of the endpoint is visible in the first column.

Figure 15-57 Endpoints table.

Clicking any of the endpoints in the table will bring up the endpoint details. The list of details maintained for each endpoint can be quite large, especially if the Endpoint Attribute Filter is not enabled. Figure 15-58 shows the endpoint details screen for an Apple iPhone, and Figure 15-59 shows some of the details further down the list, including the HTTP probe being given credit for the final profile assignment.

Figure 15-58 Endpoints details.

Figure 15-59 Endpoint details, continued.

Device Sensor Show Commands

With Cisco switches that run device sensor, there is a show command specifically for the device sensor capability in the switch: show device sensor cache [ all | mac ]. Example 15-13 displays the output of the show command. While the values might not make a lot of sense to a human being, it does demonstrate that the device sensor is collecting and caching profiling data.

Example 15-13 show device-sensor cache all