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

---

1. The Posture Service is comprised of which of the following functional components? (Select three.)

a. Profiling

b. Client provisioning

c. Authorization policy

d. Mobile device managers

e. Access lists

f. Guest Services

g. Posture Policy

2. What are the three possible posture outcomes following the initial connection to the network?

a. Location, Location, and Location

b. Routes, Translations, and Permissions

c. Authentication, Authorization, and Accounting

d. Compliant, Noncompliant, and Unknown

3. Which is a benefit of a NAC web agent versus a persistent agent?

a. The web agent provides enhanced remediation techniques.

b. The web agent does not require Administrator privileges to install.

c. The web agent provides additional firewall functionality for the endpoint.

d. The web agent can provide a greater number of Posture conditions.

4. True or False? The Process Check posture condition is supported on all NAC agent types.

a. True

b. False

5. The File condition for Posture does which of the following?

a. Checks the existence of a file

b. Checks the date of a file

c. Checks the version of a file on the client

d. All of the above

6. True or False? Cisco offers periodic Posture Elements updates.

a. True

b. False

7. The CoA process is used for which of the following?

a. To force an endpoint to reauthorize following a change in status

b. Following a change of posture compliancy from the NAC agent

c. Only after a NAD has terminated an endpoint’s connection

d. a and b

e. b and c

f. a, b, and c

8. When configuring the Client Provisioning Policy, you can elect each of the following except which?

a. NAC Agent Configuration

b. Network Supplicant Provisioning

c. Access list

d. Profile

9. Remediation is a process by which of the following occurs?

a. An endpoint that is not compliant with security policy can become compliant.

b. ISE communicates to the ASA firewall to block known attackers.

c. ISE confirms the identity of the end user based on the associated endpoint.

10. Which remediation type is available on a Macintosh OS X endpoint?

a. Automatic Launch Program Remediation

b. Manual Antispyware remediation

c. File Remediation

d. Manual Antivirus Remediation

Foundation Topics

Posture Service Overview

ISE only has the ability to “see” the limited amount of network traffic that the endpoint sends onto the network and is actively forwarded to ISE, usually with the assistance of other network devices (specifically, network access devices and device sensors). Using the information it receives, ISE can make an educated guess as to the type of the device (via profiling) and adjust the level of access given to the endpoint accordingly. However, the information sent to ISE will likely not include the latent virus or piece of malware running on the endpoint that is waiting to wreak havoc on the network at the right moment. ISE will likely not know about this attack on the network until it is too late.

ISE’s posture service enables ISE to have a window into the software that is running on the device. Using a number of condition and policy constructs on ISE, a network administrator can define the requisite security policy for her corporation. As the endpoint attempts to join the network, ISE can confirm whether the endpoint is in compliance with the configured security policy. If the endpoint is compliant, the endpoint will be allowed the commensurate level of network access. However, if the endpoint is not compliant, ISE can immediately react and provide a limited amount of network access to allow the endpoint to remediate its noncompliance.

What approach does ISE use to determine whether an endpoint is compliant? To get the required insight as to what is running on the endpoint, ISE leverages a network admission control (NAC) agent that is installed on the endpoint. The NAC agent performs the necessary reconnaissance of the endpoint and does ISE’s bidding to check the endpoint’s compliance to the security policy. If the endpoint is not compliant, it is the job of the NAC agent to inform ISE of the issue. Without the NAC agent, ISE would be unable to do a proper posture assessment of the endpoint.

The posture service has three major functional components:

Client Provisioning—The Client Provisioning portion of the posture service installs the NAC agent onto the endpoint.

Posture Policy—The Posture Policy defines what is compliant and what is noncompliant about the endpoint. This compliance could be based on the version of antispyware or antimalware software present on the endpoint and whether the anti-X definitions are up-to-date.

Authorization Policy—Once we know whether the endpoint is compliant, we can determine the level of access that should be granted to the endpoint. Typically, a compliant endpoint is given an increased level of access while a noncompliant endpoint is cordoned off on the network until it can remediate its noncompliant stance.

Posture Flow

Much like the Profiler and Guest Services function of ISE, posturing is another optional component a network administrator can choose to deploy in a Cisco ISE network. If implemented correctly, the Posture service of ISE can greatly increase the security of a corporate network.

One of the key components of ISE that makes posturing possible is the change of authorization (CoA) function, which has been discussed numerous times in this book. To review, a CoA is the capability of ISE to instruct the network access device (NAD) to reauthorize the endpoint. This CoA normally takes place after a condition that may have changed the endpoint’s network-worthiness or level of access. For instance, if an endpoint is determined to be a mobile device via a Profiling process, a more restrictive level of network access can be given to the endpoint.

How does posturing leverage the CoA function? As an endpoint first connects to the network, an initial network authentication and authorization begin. This provides at least a minimal amount of network access to the endpoint. This initial level of network access will be sufficient for the NAC agent that resides on the endpoint to download the security policy from ISE.

After downloading the security policy, the NAC agent can then proceed to run a posture assessment of the endpoint, reporting the result to ISE. This initial connection will return with one of three results:

Compliant—After downloading the security policy from ISE, the NAC agent on the endpoint determined that the software assessment on the endpoint adheres to the security policy, reporting this information to ISE.

Noncompliant—After downloading the security policy from ISE, the NAC agent determined that there is something on the endpoint that is in violation of the defined security policy, reporting this information to ISE.

Unknown—The endpoint failed to report a posture assessment to ISE.

Whatever the outcome from the posture assessment—Compliant, Noncompliant, or Unknown—ISE can now make a determination as to the new authorization that should be granted to the endpoint. To effect this new level of access, ISE will send a CoA to the NAD on behalf of the endpoint. The NAD will then reauthorize the endpoint, implementing the updated security policy. Figure 19-1 shows a complete overview of the ISE authentication and authorization flow.

Figure 19-1 ISE authentication and authorization flow.

Typically, if an endpoint is found to be in compliance with the security policy, it will be able to access a larger amount of network resources. For instance, if the endpoint is compliant, it might be able to access all network resources, including file shares, web servers, email, and so on. If an endpoint is given a posture assessment of Noncompliant, the endpoint might be granted a minimal level of network access to remediate its noncompliance. This can allow the endpoint to access a webpage to download the latest antivirus and antimalware software and definitions or to download the appropriate corporate software packages. If an endpoint is found to be Unknown from a posture standpoint, this implies that a NAC agent is likely not installed or was unable to communicate a posture assessment back to ISE, with the former being the more likely scenario. In this case, ISE would likely force the endpoint to a web portal that would assist the user in installing the required NAC agent.

Agent Types

The NAC agent plays a critical role in the posture service on ISE. Without this agent and the assessments it provides, posturing would not be possible. However, not all NAC agents are created equal. There are two key types of NAC agents.

The first NAC agent type is the persistent agent, which is available for Mac and Windows computers. This agent type is typically used on managed endpoints—those endpoints that are maintained by a centralized IT department. This agent is typically installed from the web browser or via an MSI package and provides the greatest level of functionality of the NAC agents. However, to achieve this increased level of functionality, Administrator rights are required to install and update the agent software.

With a persistent agent, the user is guided through the posture service. The persistent agent also supports posture remediation and will inform the PSN about an IP address change that occurs while a session is active. The Cisco Identity Services Engine supports automatic NAC agent updates.

The second NAC agent type is the web agent. As the name implies, this agent is installed via a webpage, leveraging ActiveX or Java. As long as the endpoint has one or both of these software packages installed, the web agent should be able to function. Because this agent is temporary, it is well suited for unmanaged PCs and guests and does not require administrator access. However, without the increased level of operating system (OS) access provided with Administrator privileges, it offers fewer remediation options than the persistent agent. The web agent is also capable of refreshing any changes in Dynamic Host Configuration Protocol (DHCP) addresses, often seen where authorization policy enforces a change in a virtual local area network (VLAN).

The list of supported remediation approaches is found in Table 19-2.

Table 19-2 NAC Agent-Supported Remediation Types

Posture Conditions

The purpose of posturing is to determine which software or software configurations reside on an endpoint that might soon be given access to your network. As we just discussed, this posture assessment is the job of the NAC agent, but as a network administrator, you have to define the security policy the NAC agent will adhere to as it does the assessment. The manner by which a network administrator defines this policy is by using posture conditions.

Posture conditions are used to check specific attributes on the client system. Because Cisco has partnered with many vendors over the years in developing its NAC agents, they have developed a large array of automated rule sets for more than 350 partner applications, including Windows updates (auto updates, hotfixes, and service packs), antispyware, antivirus, Windows Registry, file, and service data. This helps to simplify the configuration of these conditions within ISE.

There are several categories for assessment options. These conditions can be used alone or in combination with other conditions:

File—A condition that checks the existence of a file, the date of a file, and the versions of a file on the client.

Registry—A condition that checks for the existence of a Registry key or the value of the Registry key on the client.

Application—A condition that checks whether or not an application (process) is running on the client.

Service—A condition that checks whether a service is running on the client.

Dictionary—A condition that checks a dictionary attribute with a value.

See Table 19-3 for the assessment options that are supported for each NAC agent.

Table 19-3 Posture Assessment Options

There are several ways that you can leverage the previously mentioned supported posture assessment options to keep your network secure. Several common approaches include

Windows update verification—Microsoft frequently releases updates to its OS and Productivity Suites to patch any known vulnerabilities that were found by its millions of users. This posture condition can help ensure that the endpoint has the appropriate service packs installed and the appropriate patch level.

Antivirus application verification—Maintaining the correct antivirus software can really help lower the risk profile of an endpoint. Many corporations spend millions of dollars a year to have the best antivirus solution on their endpoints. The cost of the software is miniscule compared to the public relations impact, manpower cost of a possible compromise, loss of data, and loss of time that can result if a virus were to take down even a small portion of their endpoints and network. Depending on the size of the company and the types of endpoints that might exist, looking for a single vendor’s antivirus on the endpoint may not be practical. This posture condition can also look for any antivirus software, allowing a level of flexibility for the end user.

Virus definition verification—Much like the Windows update verification, it is equally, if not more so, important to keep virus definitions up-to-date. With the quick exchange of information that occurs via social media and the proliferation of cyber-warfare and cyber-espionage, it can be a matter of seconds that a newly found vulnerability can reach the far edges of the Internet. If a new virus definition is available, it is very important to incorporate the updated file into your endpoint security profile as quickly as reasonably possible.

Windows screensaver password verification—It is important to lock down access to your endpoints with a password. In absence of a password on your endpoint, a passerby, or possibly even a remote user, can access your computer and place any number of rogue software packages on your computer, including viruses, malware, key-loggers, and so on. With a password, this can completely prevent a user from gaining access to your computer or, at a minimum, act as a deterrent whereby the attacker will move on to an easier target.

Registry entry verification—On Windows devices, the Registry can be like the Crown Jewels of the OS. It is important to protect the integrity and content of this file. If the content, integrity, or availability of this file are compromised in any way, the entire OS can be rendered inoperable, causing large amounts of downtime, lost productivity, and possible loss of intellectual property—not to mention any public relations impact that might result. Also, by verifying the content of certain Registry keys, you can confirm whether installed software is present and whether it is configured adequately to meet the requirements of the corporate security policy.

ISE supports periodic updates to its posture elements. The posture updates can be initiated manually or scheduled to run automatically on a periodic basis. To trigger an update or to configure the updates to run on a schedule, go to Administration > System > Settings > Posture > Updates (see Figure 19-2). These updates include predefined checks, rules, and support charts for antivirus and antispyware for both Windows and Macintosh operating systems and operating system information supported by Cisco.

Figure 19-2 Posture updates.

CoA with Posture

As mentioned previously in this chapter and as shown in Figure 19-1, ISE uses the CoA feature heavily to facilitate the posture service. When a client first attempts to join the network, it might not have a NAC agent available to perform a posture assessment. Without a NAC agent, ISE will have no mechanism to determine what software is running on the endpoint. Accordingly, the endpoint will not know how to communicate its posture assessment to ISE. For this reason, an endpoint without a posture agent will be assigned an Unknown posture status.

ISE will be configured to appropriately handle the Unknown status by adding a rule to the authorization policy. Within the authorization policy of ISE, we’ll configure a rule that has a condition that matches a posture status of Unknown. The authorization profile that is attached to that rule will leverage the common task of redirection to send the endpoint to the Client Provisioning Portal (CPP). As the endpoint attempts to browse to a website, the redirect will trigger, sending the endpoint to the CPP where it can install an appropriate NAC agent.

Now that the previously Unknown endpoint has a NAC agent, a proper posture assessment can be completed. The NAC downloads the requisite posture security policy from ISE and completes the assessment, sending the assessment result to ISE. Whether the endpoint is compliant or noncompliant, ISE sends the CoA to the NAD to signal the endpoint that a new authorization profile will be applied. If the endpoint is compliant, this CoA will likely provide an increased level of access for the endpoint. If the endpoint is noncompliant, additional remediation steps can be required to access the network.

We’ll discuss the actual configuration that must occur here shortly.

Configuring Posture

Prior to beginning the implementation of posturing on your network, it is paramount that you do a review of your network security policy. With this review, it is best to highlight all the required checks that must be done to determine whether an endpoint is compliant as well as the types of endpoints you will be assessing. Pay specific attention to the OS running on the endpoints and cross-reference these OSes with the compliancy policy.

As we alluded to previously, a number of conditions might not yet be supported with the current versions of the NAC agent on a particular OS in question (for instance, Linux operating systems do not currently have an agent installation policy within ISE). If a “required” condition is not supported, it might be prudent to come up with an acceptable approach to deal with the deviation. It is best to make sure that all required conditions are supported or understand what approach is going to be taken for unsupported conditions prior to beginning the configuration process. Brainstorm all possible scenarios so as to minimize any unintended outages during the implementation.

When you are comfortable that you have all the required information to configure a complete security policy on ISE, you can begin the configuration process. The first step of this configuration is to review the Posture general settings (see Figure 19-3) at Administration > System > Settings > Posture > General Settings. With these settings, you can configure such items as the default posture status as well as remediation timers, reassessments, and posture acceptable use policy (AUP). The configuration of the reassessments and Posture AUP is beyond the scope of the SISAS test and, therefore, is not included in this book.

Figure 19-3 Posture general settings.

The general settings also provide, as we mentioned previously, the ability to update the Posture elements from www.cisco.com.

Downloading CPP Resources

Before we start configuring the policy, it is important that we download all the required CPP resources. These CPP resources include any agents or compliance modules that might be required on the endpoints. For posturing, our focus is going to be mostly on the NACAgent or WebAgent types. These resources can be downloaded (see Figure 19-4) by going to Policy > Policy Elements > Results, Client Provisioning > Resources. Click the Add button and select the required resource, such as Agent Resources from Cisco site. This is also the same location whereby you can download the Supplicant Provisioning Wizards that are required for BYOD, as discussed in Chapter 17, “Bring Your Own Device.”

Figure 19-4 Download client provisioning resources.

Now that we have established our posture security policy, updated the Posture Elements, reviewed the Posture general settings, and updated our CPP resources, we are ready to begin our Posture service configuration. In this configuration, much like we did with our authentication, authorization, and Guest Services policies, we will lay some basic groundwork—building blocks if you will—before we start configuring the actual conditions and policies.

Client Provisioning Policy

With the appropriate resources downloaded to ISE, we have to define how these resources will be deployed to the endpoints. For instance, as the network administrators, we need to decide which NAC agent we intend to use with each endpoint type and under what conditions. This task of deploying the appropriate NAC agent to the endpoint under the right conditions is defined using the Client Provisioning Policy. As we mentioned near the beginning of this chapter, we might not want to require posturing for guest users—or, if we do, we might choose a nonintrusive, web-based agent.

The Client Provisioning Policy is what we used in Chapter 17 to deploy the Supplicant Provisioning Wizards. This time, we’ll define similar policies, or modify existing policies, to deploy the NAC agent to the endpoints. Even if you did not review the BYOD chapter, you will still likely be familiar with the intuitive constructs that were also used in the authentication and authorization policies—the IF-THEN programmatic approach. Each client provisioning rule will have a name, a set of conditions (including identity group, OS, and/or other conditions), and then the resulting NAC agent to deploy.

For the Operating Systems option, select from the predefined OSes, which include Android, Apple iOS, Mac OS X, and Microsoft Windows. Posturing of mobile endpoints are not currently supported using a NAC agent. If posturing of mobile endpoints is required, you might consider leveraging one of the Cisco’s Mobile Device Manager (MDM) partners, as we briefly discussed in Chapter 6, “Introduction to Advanced Concepts.”

If you want to cover all Windows varieties with one rule, you can select Windows All. If you require more specificity for Windows, you can also drill down into the folder and select a specific version of Windows: Windows 7, Windows 8, Windows 8.1, Windows Vista, or Windows XP.

For the Other Conditions column, you can leave this blank (triggering strictly off of the OS) or be as specific as you would like. For instance, you could trigger based on the authentication method (such as 802.1X, MAB, and so on), AD group membership, or the WLAN/SSID that is being used for access. These are just a few possible scenarios you might consider as you deploy NAC agents to your endpoints.

As you elect the NAC agent that is to be deployed to the endpoint, choosing the appropriate NAC agent type and release version, you can specify whether upgrading to the latest version is mandatory. The NAC agents available to choose from during this selection process are those that were downloaded from Cisco in the “Downloading CPP Resources” section, filtering the options based on the selected OS condition (see Figure 19-5). If you chose to not use the default posture timers under the Posture General Settings, you can choose the specific profile you configured to define various timers. You can also specify the compliance module and customization package. The finished policy is shown in Figure 19-6.

Figure 19-5 Selecting the NAC agent and policy.

Figure 19-6 Client provisioning policy.

Posture Policy Building Blocks

Everything we have configured thus far with regards to posture has been to get a NAC agent onto the endpoint. We’ve not yet started the configuration of the actual posture policy—that is which software is or isn’t running on the endpoint. These posture policies, similar to other ISE policies, have a name, conditions, and finally a result. The conditions can be a simple or compound condition, leveraging the file, Registry, service, application, or dictionary posture conditions we discussed earlier in this chapter. If these conditions match, we can then move onto the result; in this case, we refer to the result as a requirement. This requirement is somewhat different from other ISE policies because the requirement, too, is written as an expression.

This requirement expression can be read as “Requirement for ‘OS’ met IF ‘posture condition’ ELSE ‘remediation.’” The remediation in this expression defines the action that must be performed. Earlier in this chapter, we discussed the capabilities of each NAC agent when it comes to remediation opportunities (refer to Table 19-2). Be sure that whichever remediation you select can actually be accomplished in the selected OS.

Let’s now try our hand at defining a few posture policies.

Condition

The first policy building block we’ll define is the Posture conditions. These conditions will be the test for compliance performed on the endpoint. This is why the NAC agent is required: to perform this reconnaissance on the endpoint and determine which one of these defined conditions holds true on the endpoint. This condition can be to see if particular software is or is not present, such as any antivirus or antispyware software, or a specific version of antivirus or antispyware. To configure Posture conditions, browse to Policy > Policy Elements > Conditions> Posture. Once here, you can elect a specific type of condition you want to define. Let’s take a look at the AV Compound Condition option.

If you click AV Compound Condition (shown in Figure 19-7), you will see four predefined AV-related compound conditions. Two are for Windows and two are for Mac OS X. For each OS, a condition for the installation of an AV exists, as well as the definition file of the AV.

Figure 19-7 AV compound conditions.

If you click ANY_av_mac_def, you’ll see that this rule has a requirement of Mac OSX as the OS where the Vendor option can be ANY with a Check Type of Definition (see Figure 19-8). This rule simply ensures that the Mac OS X endpoint has any antivirus running, but it must have a virus definition that is, at most, five days old.

Figure 19-8 ANY_av_mac_def posture condition.

Now that we’ve looked at a simple condition, let’s take a quick look at one that is a little more complex. Clicking Registry Condition in the left pane displays a long list of conditions that are predefined. Many of these conditions are looking for OS updates for known vulnerabilities or to determine which version of OS is running.

Let’s define a Registry Condition of our own. Click the Add button. You are prompted to provide a name and description for your Registry condition. You can also select the RegistryType. This RegistryType allows for three options: the presence of the Registry key, a specific value being in the Registry key, or the default value being in the Registry key. You must then provide the “path” of the Registry key, selecting the Registry Root Key first and then providing the remainder of the path. Because you might want to confirm that a Registry key is NOT present, does NOT have a specific value, or is NOT the default value, you can change the Value Operator from Exists to DoesNotExist. Finally, you can select the relevant OS.

Figure 19-9 shows one example of a Registry condition that checks for the patch of the W32.Blaster.Worm (https://technet.microsoft.com/library/security/ms03-026) on Windows XP.

Figure 19-9 W32.Blaster.Worm Registry condition.

Remediation

With these conditions, we defined what we are checking for on the endpoint. This is the posture assessment. Next, we must define what we are going to do if the condition we found is or is not what we want it to be. If the result of the condition goes against our security policy, we’ll need the user to remediate the discrepancy before gaining access to the network. To configure the remediation for posturing, go to Policy > Policy Elements > Results > Posture > Remediation Actions.

With our previous examples, if the Mac OS X computer had a virus definition that was older than five days, we can require the user to install the latest antivirus definition before moving forward with his network access. For the W32.Blaster.Worm patch on Windows XP, we can force the user to install a Windows update. Again, some remediation types might not be available on all operating systems.

For this example, let’s revisit the Mac OS X endpoint that is missing the latest antivirus definition. This is a huge risk to our network and our well-being as a company. For this reason, we’ll require this endpoint to install the latest AV definition before it will be granted access to the network. To begin the configuration of the remediation, click AV Remediation.

Clicking AV Remediation shows that there are two predefined remediations: AnyAVDefRemediationWin and AnyAVDefRemediationMac. The latter remediation will be the relevant one for the Mac OS X endpoint that is lacking the latest definition. Opening this remediation policy, you will see a name, a description, that it is a manual remediation (meaning, you’ll need to click a link), that the remediation is for a Mac OS X computer, and that it is for any AV vendor name.

Figure 19-10 AV remediation for Mac OS X.

Requirement

The next step in our posturing process is to define what we plan to do about our noncompliance to the security policy. With the conditions, we defined what we want to check for on the endpoint. We also defined what we intend to do if the condition is not met by using the remediation construct. However, outside of our own insight, we have nothing else that links the condition to the remediation. The requirement function brings the two together.

To get to the requirement function, browse to Policy > Policy Elements > Results > Posture > Requirements (see Figure 19-11). Several requirements already are written to cover many of the antivirus and antispyware posture assessments on Windows and Mac OS X endpoints alike. Looking down the list, you can see that the relevant rule for our Mac OS X endpoint that doesn’t have the latest antivirus definition is Any_AV_Definition_Mac.

Figure 19-11 Posture requirements.

Looking at that Any_AV_Definition_Mac closely, you’ll see it pertains to Mac OSX and is met if ANY_av_mac_def; if you recall, that condition states that my AV definition file must be less than five days old. If this condition is NOT met—that is, else—ISE will take the steps defined in the column Remediation Actions. In this case, the Remediation is AnyAVDefRemediationMac.

In this case, the conditions that were predefined were pretty simple—for a relatively simple test. However, if you wanted to have a few more conditions defined before you worried about upgrading the virus definition, you can define multiple conditions under the Conditions column (see Figure 19-12). As you combine more than one condition, you can define a few options on how those conditions are met. The three options that are available when you are combining multiple conditions are All Selected Conditions Succeed, Any Selected Condition Succeeds, and No Selected Condition Succeeds.

Figure 19-12 Multiple condition combining options.

Even yet, we still haven’t defined the totality of conditions that each endpoint must meet. For instance, do all Mac OS X computer have to have the latest AV definitions or only those laptops that are taken off campus? What about the people in IT who refuse to install AV programs because it slows down their computers during intensive lunchtime gaming? With the posture policy, we will now lay out all the rules and define who has to meet which requirements. To get to the posture policy, go to Policy > Posture.

The Posture Policy screen displays a familiar IF-THEN construct. In this case, we will be defining which endpoints (based on identity groups, operating systems, and other conditions) must meet which requirements (see Figure 19-13). For our Mac OS X endpoint that is missing the latest antivirus definition, we’ll give the posture policy the name MacOSX_OldAVDef. For the OS, we know that we only care about the Mac OS X virus definitions. For the other conditions, we could select a group that excludes the IT team, so the IT team would be allowed to play their lunchtime games without any issues. However, for the sake of simplicity, we’ll enforce the rule for everyone who has a Mac OS X endpoint. Finally, on the last column, we have to select the requirements to which this user group must adhere to—that is, Any_AV_Definition_Mac. In summary, this posture policy rule states that any user with a Mac OS X endpoint must have an antivirus definition that is less than five days old.

Figure 19-13 Posture policy rule.

Modifying the Authorization Policy for CPP

As the Mac OS X endpoint—the one without the latest antivirus definition—attempts to connect to the network, it will still be required to go through the normal authentication and authorization process. Our configuration of “all things posture” hasn’t changed that requirement. Actually, now that we have posturing in place, we can make the authorization process that much stricter. Let’s take a look at what is required to accomplish that.

Up to this point, the authorization policy was based on username, AD user group, certificates, and possibly profiling. Nothing, yet, has looked at the OS or other software running on the endpoint. With the posturing configuration complete, we can now start taking a look at the software on the endpoint (specifically, the Mac OS X endpoint) and start making authorization and access decisions based on that outcome.

The first step in this journey is to make sure each endpoint has a NAC agent installed. How do we tell whether the endpoint lacks a NAC agent? The easiest way to tell whether the endpoint lacks a NAC agent is if the posture status is unknown. If the posture status is compliant or noncompliant, this implies that the NAC agent was present on the endpoint, made a posture assessment, and reported to ISE (either for the good or the bad). Without a NAC agent present, the endpoint will not be able to tell ISE anything about its compliance. Let’s add an authorization policy that will leverage this unknown posture status and send the user off to the Client Provisioning Portal (CPP) to download the NAC agent (see Figure 19-14). The AV pair that stores the posture status is Session:PostureStatus EQUALS Unknown.

Figure 19-14 CPP downloadable ACL.

To send the client to the CPP, we have to first configure an authorization profile that will trigger a redirect to the CPP. For this, we need to leverage two key common tasks:

DACL name—In this case, we want to create a downloadable ACL that will allow the unknown user very limited access to the network.

Web redirection—To send the endpoint to the correct web portal for CPP, we have to configure the web redirection and the associated redirect ACL to point to the CPP (see Figure 19-15). This redirect ACL is a named ACL, so we’ll also need to define it on the NAD.

Figure 19-15 CPP authorization profile.

The redirect ACL we’ll configure on the NAD will be CPP-REDIRECT-ACL and will match the ACL shown in Example 19-1.

Example 19-1 CPP-REDIRECT-ACL Contents