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

---

1. A RADIUS change of authorization enables an authentication server to do which of the following?

a. Escalate an administrative user’s access level within the server’s administration portal

b. Grant context appropriate network access after initial access has previously been granted

c. Gain root-level access of all network devices

d. Take over the world

2. Three possible options for change of authorization actions are which of the following?

a. IKEv1, IKEv2, SSL

b. HTTP, FTP, Telnet

c. No COA, Port Bounce, Reauth

d. User mode, privileged mode, configuration mode

3. MAC Authentication Bypass is a process by which a device does which of the following?

a. Bypasses all authentication and authorization processes by using a supplicant

b. Authenticates with an X.509 certificate to establish a secure tunnel with the network

c. Authenticates without a 802.1X supplicant on the endpoint by using its MAC address as the RADIUS identity

d. Hides its MAC address from being discovered on the network

4. A MAC address is six octets in length, of which the first three octets are which of the following?

a. A duplicate of the IP address subnet in hexadecimal format

b. Always the same across all network devices

c. Assigned dynamically upon connection to the network

d. An organizationally unique identifier (OUI) that indicates the device’s vendor

e. All F’s—that is, FF:FF:FF

5. Which devices often lack an 802.1X supplicant?

a. Printers

b. Laptops

c. Cell phones

d. All of the above

6. Prior to MAB, a switchport with a non-802.1x client would be configured without 802.1x. This presented issues because of which of the following?

a. A broadcast storm would be created as the endpoint device was plugged into the interface.

b. A non-802.1x client would still not be able to gain network access.

c. A rogue user could unplug the non-802.1x endpoint and gain unauthorized access to the network.

d. Rebooting the device would cause the switchport to go into error disable.

7. Posture assessment can check for which of the following?

a. File conditions including existence, date, and/or version

b. Registry condition, whether a registry entry is or is not present, on Windows-based endpoints

c. Service condition, whether a service is or is not running, on Windows-based endpoints

d. A and B

e. B and C

f. A, B, and C

8. When configuring authorization policy based on posture assessment outcome, which of the following values are available for the PostureStatus attribute?

a. Permit, Deny, Drop

b. Compliant, NonCompliant, Unchecked

c. Internet Only, Partial Access, Full Access

d. Compliant, NonCompliant, Unknown

e. AntiVirusNotPresent, AntiVirusNeedsUpdate, AntiVirusCurrent

9. To remediate noncompliant endpoints, a redirect ACL must be defined _____ and the web redirection must be destined to ______ portal on the authentication server.

a. as a dACL, remediation

b. on the switch, remediation

c. as a dACL, profiling mitigation

d. on the switch, profiling mitigation

e. as a dACL, authentication DMZ

f. on the switch, authentication DMZ

10. A mobile device manager is which of the following?

a. A network administrator responsible for onboarding all mobile devices into the authentication server

b. An application that runs on a mobile device, allowing the user or endpoint to manage the authentication server and other network devices

c. A wireless access point that detects rogue mobile endpoints

d. A software system or service that provides advanced posture assessment for mobile endpoints

Foundation Topics

Change of Authorization

To have a secure network, it is paramount that no individual or endpoint is allowed access to the network or to network resources until they have been sufficiently authenticated. As we discussed in Chapters 2–5, you can use a variety of identity stores and authentication methods to authenticate a user or device. This authentication establishes who the user and/or endpoint is. For instance, via authentication, you can determine whether the user is part of the network administrators group of users or whether the user is simply a basic user.

Following—and often related to or based on—the authentication, the user or endpoint will be authorized to access the network at some level. Again, as mentioned in earlier chapters, authorization is the process by which you determine to which resources an authenticated user can have access. This level of authorization could allow the user unfettered access to all network resources, access to none of the network resources, or a sliding scale of access between these two extremes. Being able to provide a differentiated level of access to a network administrator versus a basic user, whereby the network administrator is given the greatest level of access and the basic user is given elementary level of access, is critical for network security. It gives users the least level of access that they require to accomplish their duties.

However, it’s not always that clear cut. Sometimes a user, an endpoint, or the network can change after the initial authentication/authorization process. For example, an endpoint could be stolen, become infected, or otherwise fall out of the good graces of the network administrators. The network must be able to react to these changes and provide an updated level of access, or authorization, to this endpoint.

As highlighted in Chapter 2, “Fundamentals of AAA,” this server-initiated authorization update process happens via a change of authorization (CoA). As an endpoint’s level of authorization changes, the authentication server can elect to do nothing (that is, do not issue a CoA), perform a port bounce (such as shut/no-shut the port), or instruct the network access device to reauthenticate the user.

By using this CoA process, we, as network administrators, have an opportunity via the authentication server to rethink or reexecute the authorization of an endpoint as the network or device changes, enabling us to implement the advanced concepts that are the key topics of this chapter.

Automating MAC Authentication Bypass

The first advanced concept we will cover is the automation of MAC Authentication Bypass (MAB). As discussed in Chapter 5, “Non-802.1X Authentications,” MAB is the process by which an endpoint bypasses authentication by using its MAC address alone. To accomplish this, the authenticator network device crafts a RADIUS Access-Request message on behalf of the endpoint. This Access-Request uses the endpoint’s MAC address as both the identity and password fields with a RADIUS Service-Type of Call-Check. This is an indication to the RADIUS server that the endpoint does not have or is currently not using an 802.1X supplicant. These devices are sometimes referred to as dumb devices.

Often, the authentication server is configured to trigger this RADIUS Service-Type of Call-Check, authenticating the device based on its MAC address. If the device’s MAC address is present in the authorized dumb devices database on the authentication server, the device is authenticated and subsequently authorized according to the configured authorization policy. If desired, devices can be subdivided into different endpoint identity groups—for example, Printers, IP Phones, and so on—and provided different levels of network access upon a successful authorization, depending on the chosen authentication server.

As discussed at length in Chapter 5, MAB is not a secure technology and it is best to leverage MAB as a secondary “authentication” method instead of as the primary method for allowing network access. Please keep this in mind as you implement MAB on your network.

Managing MAB devices can quickly become a network administrator’s worst nightmare. The dumb devices that require MAB include IP phones, IP cameras, and printers, to name just a few. Managing these IP phones, IP cameras, and printers manually within an organization can quickly get out of hand even for a small- to medium-sized business. Any time a new dumb device is placed on the network, its MAC address must be added to an internal endpoints database on the authentication server, sometimes via “MAB Devices” list(s). If a user gets a new IP phone because he spilled coffee on his last one or the printer management company replaces a printer, a network administrator must manually update the MAB database with the new device.

Some authentication servers can help to automate this process for you via device profiling. Profiling is the process by which the authentication server can make educated observations as to what the device is based on its network activity and the contents of these network exchanges. We’ll discuss some of the profiling process now and leave a more in-depth discussion of profiling in Chapter 15, “Profiling.”

As a device connects to the network, the network access device (NAD) is configured for 802.1X, often with MAB as a backup authentication method—rarely with just MAB (remember: MAB is not secure!). In either case, the NAD begins the RADIUS exchange with the authentication server, forwarding this server critical information about the authentication session including the MAC address of the endpoint, which is associated with the authentication Session ID. The Calling-Station-ID field within the RADIUS packets provides the MAC address of the endpoint requesting access to the network, while the Session ID is a unique identifier associated with that RADIUS session (and, therefore, uniquely associated to that MAC address).

As the device continues its network onboarding, it goes through its normal network processes, requesting/receiving an IP address, discovering/advertising its neighbors, and so on. At each step along the way, these various network exchanges can be sent to the authentication server and associated with the MAC address of the device.

To be most effective at profiling the endpoint, a number of profiling options must be enabled on the authentication server to facilitate and gather the information that is being provided by this endpoint. The two key profiling options that will prove most useful as we automate the MAB enlistment process are RADIUS and DHCP.

With RADIUS profiling, the authentication server can gather, record, and correlate the information contained within a RADIUS packet into an endpoint database, making intelligent observations about the device along the way. From the very first RADIUS packet received on the RADIUS server for the endpoint, observations are being made and recorded. With each RADIUS exchange, the RADIUS Calling-Station-ID and/or Session ID is provided, making it easy for the RADIUS server to know which endpoint the newly found information is about.

This MAC address, alone, can reveal quite a bit of information about an endpoint. First of all, a MAC address is divided into two main portions; the first three octets (00:1D:71:9B:06:40 as shown in Figure 6-1) are the organizationally unique identifier (OUI), and the last three octets (00:1D:71:9B:06:40) is the network interface controller (NIC) specific portion. Where a governing body such as IEEE issues the OUI, the NIC specific portion is unique per device and acts as a serial number that is assigned by the device manufacturer. With the OUI portion of the MAC address, some observations can be made immediately. Certain manufacturers are associated with producing a certain type of network device such as a network printer or IP phone. Therefore, whenever that particular OUI is seen on the network, it is a safe assumption that the owner of that MAC address is a network printer. Otherwise, the authentication server maintains a database of the OUIs associated with certain device vendors as well as the specific device types associated with these vendors, enabling the RADIUS server to dynamically associate that device with a particular network function or device group.

Figure 6-1 MAC address.

For those vendors that produce a large number of device types under a single OUI, such as Cisco (who makes routers, switches, IP phones, IP cameras, and so on), whereby differentiating the device type is not practical, additional information from the RADIUS exchange is often leveraged. Other devices, such as switches and Wireless LAN Controllers (WLCs), within the network can sometimes assist the authentication server in its profiling process. These devices are called device sensors. With these device sensors, the authentication server can gather additional information from the device that is not natively available to the server. “Neighbor” protocols, such as Cisco Discovery Protocol (CDP) and Link Layer Discovery Protocol (LLDP), provide some useful information to the authentication server. These protocols are often confined to the Layer-2 domain; if the authentication server is not on the same Layer-2 domain, another device (such as the device sensors) must tunnel, port mirror, or otherwise relay this information to the authentication server. Within these two protocols, the device capabilities, a description of the device, the hostname, the platform type, and other useful fields can be learned. All this information can then be encapsulated into a RADIUS accounting packet or similar mechanism and sent to the authentication server. The authentication server can then parse these packets and marry the additional information that was learned with the original MAC address and/or RADIUS Session ID, further evolving the dossier for the device.

Any other additional field, or combination of fields, contained within the RADIUS authentication/authorization or accounting exchange can also be leveraged to make decisions about the devices’ final profiling. From the totality of information gathered from the RADIUS processes for the endpoint, many MAB devices can be automatically added to the appropriate “MAB Devices” list(s) and assigned the appropriate level of authorization.

DHCP profiling can also be a useful mechanism to develop an endpoints dossier. As most devices join a network, they will request an IP address using DHCP. This DHCP process can easily be replicated to the authentication server by simply adding an additional “IP helper” address to the interface on the switch, pointing to the profiling server. As the authentication server receives the DHCP packets from the endpoint, the server will leverage fields from the DHCP packets (which also, subsequently, contains the MAC address of the endpoint) to determine which type of device the endpoint could be. Some of the fields within DHCP that the authentication server can leverage include device dhcp-client-identifier (or MAC address, which contains the device OUI), the dhcp-requested-address (allowing the authentication server to further correlate MAC-to-IP mapping), and dhcp-parameter-request-list (which can also act as a device-type fingerprint).

By analyzing the complete DHCP process and exchange, the endpoint identity can be further established with a reasonable level of certainty in the authentication server’s database.

As a device moves through this RADIUS and DHCP profiling process, the level of access to the network will likely need to change. By leveraging RADIUS and DHCP profiling, a network administrator can quickly and automatically identify many dumb network devices as a printer, an IP phone, an IP camera, and so on and permanently associate that device with a particular “MAB Devices” list(s). This process can equally be used to profile “smart” devices as well. This would then enable the network administrator to make authorization decisions specific for a particular device type, such as a printer that is allowed access to the network only on certain ports or an IP phone that is allowed access to a certain Cisco Unified Call Manager. For those devices that are not easily identified with certainty, these could even be assigned to an “Unknown” device list, given a basic level of network access, and further triaged manually as needed.

To trigger this new level of authorization, we will leverage the CoA. The device was given basic access to the network for the authentication server to gather the required RADIUS and DHCP fields from the device. Now that the authentication server has a more updated view of the device, the authentication server can now, via the NAD, provide a more open or a stricter level of access to the endpoint as necessary. To invoke this reauthorization process, it sends a CoA to the NAD with the relevant Session ID for the endpoint. The NAD then forces the device to reauthenticate, and subsequently reauthorize, its level of access to the network.

Posture Assessments

Authentication is often focused on the user of an endpoint. As the user brings her device onto the network, we, as network administrators, often look at who is using device and do not put any focus on what device is being used. Historically, the endpoint devices on a network were heavily managed by IT and the operating system was sufficiently locked down so that the end user could effectively change nothing.

This change control—allowing only IT to modify settings and applications on the PC—slowly started to dwindle as end devices became more mobile. Now, an end user often requires some level of flexibility to modify her laptop without IT intervention. This is important for allowing the user to add home Wi-Fi parameters, installing productivity applications, as well as installing device drivers when the end user is working remotely from a home office or from a hotspot.

How do network administrators ensure that the changes to the laptop made by the end user in the sanctity of her home are not going to compromise the security of the corporate network? How can we ensure that the device continues to comply with the company security policy? How do we react to a device that is out of compliance? This is where device posture assessments come in.

A posture assessment, or simply posturing, is a process by which an operating system—or, as in this case—an application (for example, a Cisco NAC Agent) running on an endpoint provides critical information about the software that is actively running on the device. Several conditions can be checked as part of a posture assessment. The availability of these conditions or their exact functions may vary depending on the authentication or posturing server that is being used:

File Condition—Checks the existence, date, or version of a file on the endpoint.

Registry Condition—Checks the existence or value of a registry key on the endpoint.

Application Condition—Checks whether an application is running on the endpoint.

Service Condition—Checks whether a service is running on the endpoint.

Dictionary Simple Condition—Checks an attribute that is associated to a user and value.

Windows Update Verification—Confirms that the endpoint has the appropriate Windows service pack installed.

Virus Application Verification—Confirms that the endpoint has an antivirus solution installed. If specific software is required, this can also be confirmed.

Virus Definition Verification—Confirms that the endpoint has the virus definition file present and that they are newer than a particular date.

Spyware Application Verification—Confirms that the endpoint has an antispyware solution installed.

Windows screen saver password verification—Verifies that the user has a Windows screensaver password defined.

This information about the endpoint is forwarded to the authentication or posture server. The server compares this data to the security policy as configured, giving the device an assessment of Compliant, NonCompliant, or Unknown. This assessment outcome can then be used as part of the authorization for the endpoint, or what this endpoint will have access to. If the endpoint is compliant with the configured security policy, the device can be given unfettered access to the network via the selected authorization policy. If the endpoint is NonCompliant or Unknown, the resulting authorization policy could redirect the endpoint to a remediation portal by using a redirect ACL defined on the switch. If the posture status is Unknown, the posture agent will be installed on the endpoint so a proper posture assessment can be completed.

After the device has been appropriately remediated via the portal page, a CoA can be issued to the NAD to reauthenticate the user. A more in-depth review of the posturing configuration is provided in Chapter 19, “Posture Assessment.”

Mobile Device Managers

A mobile device manager (MDM) is a security software system that enables an administrator to configure and secure a mobile device, regardless of where the device is located. As an endpoint onboards with an MDM, the owner of the endpoint gives permission to the MDM software to access the device and gather any required information. This is accomplished by leveraging an MDM agent on the endpoint—either a separate application or an agent that is built into the OS—and a server. After the required permissions are issued, the MDM software performs a number of “assessments” on the device, identifying the current state of security, software, and networking, amongst other things. This information is then passed to the MDM server for processing. This MDM server can reside on premises at the corporation or in the cloud. Some additional supporting servers reside in the cloud and supplement the operation of the MDM; these include Apple’s Push Notification Servers and Google Client Messaging Servers.

A number of MDM vendors exist. Each of these vendors provides Comprehensive Device Provisioning, Detailed User and Device Context, and Increased Device and Application Security. Depending on your user base, cost, preferred deployment model (on premises or in the cloud), and security policy, you might choose one MDM vendor over the other.

Many of the features that are supported almost ubiquitously across all MDM vendors include these:

Support for most mobile and laptop platforms—This includes Android, Apple iOS, Mac OSX, and some Windows.

Application provisioning—Pushing required applications to the device.

Security posturing—Includes checking whether Pin-lock is enabled, whether encryption is enabled, whether the device is jail broken, and so on.

Modify device capabilities—Includes enabling and disabling Wi-Fi, GPS, Bluetooth, and the camera.

Remote wipe—Whenever a device is lost or stolen, the employee or administrator can perform a partial or full wipe on the endpoint.

Active Directory support—Includes the ability to authenticate MDM users based on AD credentials.

VPN provisioning—Deploying VPN configurations so the endpoint can securely connect to the corporate network.

Device backup—Ensuring the device has been backed up recently.

Many of the fields discussed are not directly available to the authentication server’s posture assessment process. Depending on the authentication server, some fields might be explicitly communicated to the authentication server. Otherwise, in absence of these explicit fields, the MDM server can provide a final, summary assessment of Compliant or NonCompliant back to the authentication server.

MDMs, either via an application on the endpoint or via software features embedded natively in the operating system, can see a greater amount of detail as described previously. MDMs also provide a greater level of security remotely, for user and administrators alike. This enables the endpoint to be locked remotely and wiped securely from a portal available within the MDM or by proxy via the authentication server.

To take advantage of the MDM features, the authentication server’s authorization policy can query the status of the endpoint as Compliant/Noncompliant as seen by the MDM as well as check the status of several other explicit endpoint statuses from the MDM (for example, Jailbroken or Pin-lock). If a device needs to be redirected to register with the MDM or for noncompliance, the authentication server’s authorization policy can perform a redirect, sending the endpoint to an MDM portal page for further mitigation and remediation information.

As corporations continue to accept mobile devices as viable and often critical business tools, the network availability from these devices, the applications available from these tools, and the devices’ security remain paramount. An MDM acts as just one more tool to manage and enforce security policy on these devices.

Exam Preparation Tasks

Review All Key Topics

Review the most important topics in the chapter, noted with the key topics icon in the outer margin of the page. Table 6-2 lists a reference of these key topics and the page numbers on which each is found.

Table 6-2 Key Topics for Chapter 6

Define Key Terms

Define the following key terms from this chapter, and check your answers in the glossary:

change of authorization (CoA)

Cisco NAC agent

mobile device manager (MDM)