Cisco NAC Appliance - Clean Access Manager Installation and Configuration Guide, Release 4.1(3)
Configuring Agent Requirements
Downloads: This chapterpdf (PDF - 2.19MB) The complete bookPDF (PDF - 16.18MB) | Feedback

Configuring Agent Requirements

Table Of Contents

Configuring Agent Requirements

Overview

Configuring AV/AS Definition Update Requirements

AV Rules and AS Rules

Verify AV/AS Support Info

Create an AV Rule

Create an AV Definition Update Requirement

Create an AS Rule

Create an AS Definition Update Requirement

Configuring a Windows Server Update Services Requirement

Create Windows Server Update Service Requirement

Map Windows Server Update Service Requirement to Windows Rules

Configuring a Windows Update Requirement

Create a Windows Update Requirement

Map Windows Update Requirement to Windows Rules

Configuring Custom Checks, Rules, and Requirements

Custom Requirements

Custom Rules

Cisco Pre-Configured Rules ("pr_")

Custom Checks

Cisco Pre-Configured Checks ("pc_")

Using Pre-Configured Rules to Check for CSA

Copying Checks and Rules

Configuration Summary

Create Custom Check

Registry Checks

File Checks

Service Check

Application Check

Create a Custom Rule

Validate Rules

Create a Custom Requirement

Create File Distribution/Link Distribution/Local Check Requirement

Configuring a Launch Programs Requirement

Launch Programs With Admin Privileges

Launch Programs Without Admin Privileges

How the Agent Verifies Digital Signature and Trust on an Executable Program

Create a Launch Programs Requirement

Launch Programs via Clean Access Agent Example

Map Requirements to Rules

Apply Requirements to User Roles

Validate Requirements

Configuring an Optional/Audit Requirement

Configuring Auto Remediation for Requirements

Viewing Agent Reports

Exporting Agent Reports

Limiting the Number of Reports


Configuring Agent Requirements


This chapter describes how to configure requirements on the CAM so that the Clean Access Agent and Cisco NAC Web Agent can perform vulnerability assessment and remediation on client machines.

Overview

Configuring AV/AS Definition Update Requirements

Configuring a Windows Server Update Services Requirement

Configuring a Windows Update Requirement

Configuring Custom Checks, Rules, and Requirements

Configuring a Launch Programs Requirement

Map Requirements to Rules

Apply Requirements to User Roles

Configuring Auto Remediation for Requirements

Viewing Agent Reports

Overview

Requirements

To perform vulnerability assessment for client machines running the Clean Access Agent or Cisco NAC Web Agent, you need to configure and implement requirements based on the type of client validation you want to perform for the client operating system. Requirements are used to implement business-level decisions about what users must (or must not) have running on their systems to be able to access the network. The requirement mechanism maps one or more rules that you want clients in a user role to meet to the action you want those users to take if the client fails the rules. When you create a new requirement, you choose from one of several different requirement types (e.g. AV Definition Update) to configure options, buttons, and remediation instructions the Agent dialogs present to the user when the client fails the requirement. For detailed instructions on creating the different requirement types, see:

Configuring AV/AS Definition Update Requirements

Configuring a Windows Server Update Services Requirement

Configuring a Windows Update Requirement

Configuring Custom Checks, Rules, and Requirements

Configuring a Launch Programs Requirement

Rules

In all but one case—the Windows Server Update Service (WSUS) "Severity" option requirement type—you must map rules to requirements to ensure client machines meet security standards. A rule is the unit the Agent uses to validate client machines and assess whether or not a requirement has been met. Rules can be:

Preconfigured AV/AS rules, which you associate to AV/AS requirements. These require no additional checks to validate client machines.

Preconfigured Cisco Rules ("pr_rule") that feature one or more preset checks. For example, Windows hotfix-related "pr_" rules that only address "Critical" updates. You can map pr_rules as the validation criteria for several different requirement types. Refer to Cisco Pre-Configured Rules ("pr_") for further details on Cisco Rules.

A custom rule made up of one or more preconfigured or custom checks. A custom rule is one you create yourself by configuring a rule expression based on checks.

For details on mapping requirements to rules, see Map Requirements to Rules.

Checks

Checks are the building blocks for rules, but in most cases you will not need to configure them. A check is a single registry, file, service, or application check for a selected operating system, and is used to create a custom rule. A check can be a Cisco pre-configured check (pc_ check) or a custom check you create yourself. When you map rules to requirements, make sure the appropriate checks (pc_ checks or custom checks) are in place to accurately validate client machines.


Note Preconfigured ("pr_") rules are already associated with one or more checks that validate client machine security standards. You only need to create custom rules or checks if the preconfigured rules or checks do not meet your needs. See Configuring Custom Checks, Rules, and Requirements for more information.


Role Mapping

Once you have mapped a requirement to one or more rules, the final step is to associate the requirement to a normal login user role. Users who attempt to authenticate into the normal user role are put into the Temporary role until they pass requirements associated with the normal login role:

If they successfully meet the requirements, the users are allowed on the network in the normal login role.

If they fail to meet the requirements, users stay in the Temporary role for the session timeout until they take the steps described in the Agent dialogs and successfully meet the requirements.

For details on mapping requirements to roles, see Apply Requirements to User Roles.


Note To map a requirement to a normal login user role, the role must already be created as described in Create User Roles, page 6-1.


User Login/Agent Behavior

During user login/remediation, the Agent dialogs present different buttons that users can click depending on the requirement(s) assigned to validate the client machine:

File Distribution displays a Download button on the Clean Access Agent

Link Distribution displays a Go To Link button on the Clean Access Agent/Cisco NAC Web Agent

Local Check displays a Download button (disabled) on the Clean Access Agent

AV Definition Update displays an Update button on the Clean Access Agent

AS Definition Update displays an Update button on the Clean Access Agent

Windows Update displays an Update button on the Clean Access Agent

Launch Programs displays a Launch button on the Clean Access Agent

Windows Server Update Service displays an Update button on the Clean Access Agent


Note In release 4.1(3), the Mac OS X Agent does not feature the same behavior as the Windows Clean Access Agent and Cisco NAC Web Agent. For more information on Agent dialogs and behavior, see Chapter 12, "Cisco NAC Appliance Agents."


For out-of-band users, successfully authenticating and meeting requirements allows the users to leave the in-band network (on the Auth VLAN) and access the out-of-band network on the Access VLAN.

Configuring AV/AS Definition Update Requirements

The AV Definition Update and AS Definition Update requirement type can be used to report on and update the definition files on a client for supported antivirus or antispyware products. If the client fails to meet the AV/AS requirement, the Clean Access Agent communicates directly with the installed antivirus or antispyware software on the client and automatically updates the definition files when the user clicks the Update button on the Clean Access Agent dialog.


Note The Cisco NAC Web Agent only supports Go To Link manual remediation functionality. Cisco NAC Web Agent does not support Update, Download, or Launch remediation actions, nor Auto Remediation.


AV Rules incorporate extensive logic for antivirus vendors and are associated with AV Definition Update requirements. AS Rules incorporate logic for most antispyware vendors and are associated with AS Definition Update requirements. For AV or AS Definition Update requirements, there is no need to configure checks. You associate:

AV Definition Update requirement with AV Rule(s) and user roles and operating systems

AS Definition Update requirement with AS Rule(s) and user roles and operating systems

and configure the Agent dialog instructions you want the user to see if the AV or AS requirement fails.


Note Where possible, Cisco recommends using AV Rules mapped to AV Definition Update Requirements to check antivirus software on clients. In the case of a non-supported AV product, or if an AV product/version is not available through AV Rules, administrators always have the option of using Cisco provided pc_ checks and pr_rules for the AntiVirus vendor or of creating their own custom checks, rules, and requirements through Device Management > Clean Access > Clean Access Agent (use New Check, New Rule, and New File/Link/Local Check Requirement), as described in Configuring Custom Checks, Rules, and Requirements.

Clean Access works in tandem with the installation schemes and mechanisms provided by supported Antivirus vendors. In the case of unforeseen changes to underlying mechanisms for AV products by AV vendors, the Clean Access team updates the Supported AV/AS Product List and/or Clean Access Agent/Cisco NAC Web Agent in the timeliest manner possible in order to support the new AV product changes. In the meantime, administrators can always use the "custom" rule workaround for the AV product (such as pc_checks/pr_ rules) and configure the requirement for "Any selected rule succeeds."


Figure 11-1 shows the Clean Access Agent dialog that appears when a client fails to meet an AV Definition Update requirement.

Figure 11-1 Required AV Definition Update (Clean Access Agent User Dialog)

AV Rules and AS Rules

Antivirus rules (AV Rule) and anti-spyware rules (AS Rule) are preconfigured rule types that are mapped to the matrix of vendors and products sourced in the Supported AV/AS Product List. There is no need to configure checks with this type of rule.

There are two basic types of AV Rules:

Installation AV Rules check whether the selected antivirus software is installed for the client operating systems.

Virus Definition AV Rules check whether the virus definition files are up-to-date on the client. Virus Definition AV Rules can be mapped into AV Definition Update requirements so that a user that fails the requirement can automatically execute the update by clicking the Update button in the Clean Access Agent and the system reporting function can alert Cisco NAC Web Agent users of the requirement.

There are two basic types of AS Rules:

Installation AS Rules check whether the selected anti-spyware software is installed for the client OS.

Spyware Definition AS Rules check whether the spyware definition files are up-to-date on the client. Spyware Definition AS Rules can be mapped into AS Definition Update requirements so that a user that fails the requirement can automatically execute the update by clicking the Update button in the Clean Access Agent and the system reporting function can alert Cisco NAC Web Agent users of the requirement.

AV Rules are typically associated with AV Definition Update requirements, and AS Rules are typically associated with AS Definition Update requirements.

The steps to create AV Definition Update Requirements are as follows:


Step 1 Verify AV/AS Support Info

Step 2 Create an AV Rule

Step 3 Create an AV Definition Update Requirement

Step 4 Map Requirements to Rules

Step 5 Apply Requirements to User Roles

Step 6 Validate Requirements


The steps to create AS Definition Update Requirements are as follows:


Step 1 Verify AV/AS Support Info

Step 2 Create an AS Rule

Step 3 Create an AS Definition Update Requirement

Step 4 Map Requirements to Rules

Step 5 Apply Requirements to User Roles

Step 6 Validate Requirements



Note In some cases it may be advantageous to configure AV or AS rules/requirements in different ways. For example:

Not all product versions of a particular vendor may support the Clean Access Agent launching the automatic update of the product. In this case, you can provide instructions (via the Description field of the AV or AS Definition Update requirement) to have users update their AV or AS definition files from the interface of their installed AV or AS product.

You can associate the AV or AS rules with a different requirement type, such as Link Distribution or Local Check, to change the Clean Access Agent buttons and user action required from "Update" to "Go to Link", or to disable the action button and provide instructions only. This allows you flexibility in configuring the actions you want your users to take.

You can also configure different Enforce Types. You can generate reports for clients and optionally provide users extra time to meet a requirement without blocking them from the network. See Configuring an Optional/Audit Requirement for details.


Verify AV/AS Support Info

Cisco NAC Appliance allows multiple versions of the Clean Access Agent to be used on the network. New updates to the Agent will add support for the latest antivirus or antispyware products as they are released. The system picks the best method (either Def Date or Def Version) to execute AV/AS definition checks based on the AV/AS products available and the version of the Agent. The AV/AS Support Info page provides details on Agent compatibility with the latest Supported AV/AS Product List downloaded to the CAM. This page lists the latest version and date of definition files for each AV and AS product as well the baseline version of the Agent needed for product support. You can compare the client's AV or AS information against the AV/AS Support Info page to verify if a client's definition file is the latest. If running multiple versions of the Agent on your network, this page can help troubleshoot which version must be run to support a particular product.

Use the following steps to view Agent support details.


Step 1 Go to Device Management > Clean Access > Clean Access Agent > Rules > AV/AS Support Info.

Step 2 Choose either Antivirus (Figure 11-2) or Anti-Spyware (Figure 11-3) from the Category dropdown.

Figure 11-2 AV/AS Support Info — AV Vendor Example

Figure 11-3 AV/AS Support Info — AS Vendor Example

Step 3 Choose a corresponding vendor (Antivirus Vendor or Anti-Spyware Vendor) from the dropdown menu.

Step 4 For Antispyware products, only the Windows Vista/XP/2K operating system is supported. Check the Minimum Agent Version Required to Support AS Products table for product details.


Note Regular updates for Anti-Spyware definition date/version will be made available via Cisco Updates. Until update service is available, the system enforces definition files to be x days older than the current system date for AS Spyware Definition rules (under Device Management > Clean Access > Clean Access Agent > Requirements > Requirement-Rules).


Step 5 For Antivirus products, choose Windows Vista/XP/2K or Windows 9x/ME from the Operating System dropdown menu to view the support information for those client systems. This populates the following tables:

Minimum Agent Version Required to Support AV Products: shows the minimum Agent version required to support each AV product. For example, a 4.1.3.0 Agent can log into a role that requires Aluria Security Center AntiVirus 1.x, but for any lower Agent version, this check will fail. Note that if a version of the Agent supports both Def Date and Def Version checks, the Def Version check will be used.

Latest Virus Definition Version/Date for Selected Vendor: displays the latest version and date information for the AV product. The AV software for an up-to-date client should display the same values.


Note The Agent sends its version information to the CAM, and the CAM always attempts to first use the virus definition version for AV checks. If the version is not available, the CAM uses the virus definition date instead.



Tip You can also view the latest def file version when selecting an AV vendor from the New AV Rule form.



Create an AV Rule

Use the following steps to configure an AV rule.


Step 1 Make sure you have the latest version of the Supported AV/AS Product List, as described in Retrieving Updates, page 9-12.

Step 2 Go to Device Management > Clean Access > Clean Access Agent > Rules > New AV Rule.

Figure 11-4 New AV Rule

Step 3 Type a Rule Name. You can use digits and underscores, but no spaces in the name.

Step 4 Choose a specific Antivirus Vendor, or choose ANY vendor, from the dropdown menu. Along with the Operating System chosen, this populates the Checks for Selected Operating Systems table at the bottom of the page for the ANY vendor option or with the supported products and product versions for the specified vendor.

Step 5 From the Type dropdown menu, choose either Installation or Virus Definition. This enables the checkboxes for the corresponding Installation or Virus Definition column in the table below.

Step 6 Choose an Operating System from the dropdown menu:

Windows Vista/XP/2K

Windows ME/98

This populates the product versions supported for this client OS in the table below.

Step 7 Type an optional Rule Description.

Step 8 In the Checks for Selected Operating Systems table, choose the product versions you want to check for on the client by clicking the checkbox(es) in the corresponding Installation or Virus Definition column:

ANY means you want to check for any product and any version from this AV vendor.

Installation checks whether the product is installed.

Virus Definition checks whether the virus definition files are up to date on the client for the specified product.


Note In a definition rule, the Agent first confirms whether or not the product is installed, then checks whether or not the definition file is up-to-date.


Step 9 Click Add Rule. The new AV rule will be added at the bottom of the Rule List with the name you provided.


Note When configuring AV Rules, the "ANY" Antivirus vendor option and the vendor-specific "ANY Product/ANY Version" option work differently:

For ANY vendor, the Agent needs to query the server to verify whether the installed product is from a supported vendor. Because the Agent only queries once at the beginning of each login session, the user must click Cancel or restart the Agent to repeat the login process in order to refresh the server's response.

For "ANY Product/ANY Version" for a specific vendor, the Agent only needs to match the required vendor against what is installed on the client machine. No query is needed.



Create an AV Definition Update Requirement

The following steps show how to create a new AV Definition Update requirement to check the client system for the specified AV product(s) and version(s) using an associated AV Rule. If the client's AV definition files are not up-to-date, the user can simply click the Update button on the Clean Access Agent, and the Agent causes the resident AV software launch its own update mechanism. Note that the actual mechanism differs for different AV products (e.g. live update vs.command line parameter).


Note The Cisco NAC Web Agent only supports Go To Link manual remediation functionality. Cisco NAC Web Agent does not support Update, Download, or Launch remediation actions, nor Auto Remediation.


Use the following steps to create an AV Definition Update requirement.


Step 1 In the Clean Access Agent tab, click the Requirements submenu link and then New Requirement.

Figure 11-5 New Requirement

Step 2 For Requirement Type choose AV Definition Update.

Step 3 Choose an Enforce Type from the dropdown menu:

Mandatory—Enforce requirement.The user is informed of this requirement and cannot proceed or have network access unless the client system meets it.

Optional— Do not enforce requirement. The user is informed of the requirement but can bypass it if desired (by clicking Next in the Agent dialog). The client system does not have to meet the requirement for the user to proceed or have network access.

Audit—Silently audit. The client system is checked "silently" for the requirement without notifying the user, and a report is generated. The report results (pass or fail) do not affect user network access.

Refer to Configuring an Optional/Audit Requirement for details.

Step 4 Choose the Priority of execution for this requirement on the client. A high priority (e.g. 1) means this requirement is checked on the system ahead of all other requirements (and appears in the Clean Access Agent and Cisco NAC Web Agent dialogs in that order). Note that if a Mandatory requirement fails, the Agent does not continue past that point until that requirement succeeds.

Step 5 If you want to enable and configure Auto Remediation for the Clean Access Agent:

a. Choose the Remediation Type [Manual | Automatic] from the dropdown menu. Choosing Manual preserves previous Agent behavior. The user has to click through each of the requirements using the Next button in the Clean Access Agent. Choosing Automatic sets the Agent to perform Auto Remediation, where the Agent automatically performs updates or launches required programs on the client after the user logs in.

b. If you configure the requirement to use automatic remediation, specify the Interval in seconds (the default interval is 0). Depending on the requirement type, this interval either sets the delay before the Agent re-attempts remediation or sets the total time allowed for a particular remediation process.

c. Enter the Retry Count []. Specifying a retry count sets a limit on the number of times the Agent automatically retries the requirement if it initially fails. (The default retry count setting is 0.)

For details on configuring Auto Remediation, see Configuring Auto Remediation for Requirements.


Note The Cisco NAC Web Agent does not support Auto Remediation.


Step 6 Choose an Antivirus Product Name from the dropdown menu or choose ANY. The Products table lists all the virus definition product versions supported per client OS.

Step 7 For the Requirement Name, type a unique name to identify this AV virus definition file requirement in the Agent. The name will be visible to users on the Clean Access Agent and Cisco NAC Web Agent dialogs.

Step 8 In the Description field, type a description of the requirement and instructions to guide users who fail to meet the requirement. For an AV Definition Update requirement, you should include instructions to alert Cisco NAC Web Agent users of the requirement and for Clean Access Agent users to click the Update button to update their systems.

Step 9 Click the checkbox for at least one client Operating System (at least one must be chosen).

Step 10 Click Add Requirement to add the requirement to the Requirement List.


Create an AS Rule

Use the following steps to configure an AS rule.


Step 1 Make sure you have the latest version of the Supported AV/AS Product List, as described in Retrieving Updates, page 9-12.

Step 2 Go to Device Management > Clean Access > Clean Access Agent > Rules > New AS Rule.

Figure 11-6 New AS Rule

Step 3 Type a Rule Name. You can use digits and underscores, but no spaces in the name.

Step 4 Choose an Anti Spyware Vendor from the dropdown menu, or choose ANY to select any supported AS vendor or product. This correspondingly populates the Checks for Selected Operating Systems table at the bottom of the page with the supported products and product versions from this vendor (for the Operating System chosen).

Step 5 From the Type dropdown menu, choose either Installation or Spyware Definition. This enables the checkboxes for the corresponding Installation or Spyware Definition column in the table below.

Step 6 The Operating System field displays Windows Vista/XP/2K by default.

Step 7 Type an optional Rule Description.

Step 8 In the Checks for Selected Operating Systems table, choose the product versions you want to check for on the client by clicking the checkbox(es) in the corresponding Installation or Spyware Definition column:

ANY means you want to check for any product and any version from this AS vendor.

Installation checks whether the product is installed,

Spyware Definition checks whether the spyware definition files are up to date on the client for the specified product.


Note In a definition rule, the Agent first confirms whether or not the product is installed, then checks whether or not the definition file is up-to-date.


Step 9 Click Add Rule. The new AS rule will be added at the bottom of the Rule List with the name you provided.


Create an AS Definition Update Requirement

Use the following steps to configure an AS Definition Update requirement.


Step 1 Go to Device Management > Clean Access > Clean Access Agent > Requirements > New Requirement.

Figure 11-7 New AS Definition Update Requirement

Step 2 For Requirement Type choose AS Definition Update

Step 3 Choose an Enforce Type from the dropdown menu:

Mandatory—Enforce requirement.The user is informed of this requirement and cannot proceed or have network access unless the client system meets it.

Optional— Do not enforce requirement. The user is informed of the requirement but can bypass it if desired (by clicking Next in the Agent dialog). The client system does not have to meet the requirement for the user to proceed or have network access.

Audit—Silently audit. The client system is checked "silently" for the requirement without notifying the user, and a report is generated. The report results (pass or fail) do not affect user network access.

Refer to Configuring an Optional/Audit Requirement for details.

Step 4 Choose the Priority of execution for this requirement on the client.

Step 5 If you want to enable and configure Auto Remediation for the Clean Access Agent:

a. Choose the Remediation Type [Manual | Automatic] from the dropdown menu. Choosing Manual preserves previous Agent behavior. The user has to click through each of the requirements using the Next button in the Clean Access Agent. Choosing Automatic sets the Agent to perform Auto Remediation, where the Agent automatically performs updates or launches required programs on the client after the user logs in.

b. If you configure the requirement to use automatic remediation, specify the Interval in seconds (the default interval is 0). Depending on the requirement type, this interval either sets the delay before the Agent re-attempts remediation or sets the total time allowed for a particular remediation process.

c. Enter the Retry Count []. Specifying a retry count sets a limit on the number of times the Agent automatically retries the requirement if it initially fails. (The default retry count setting is 0.)

For details on configuring Auto Remediation, see Configuring Auto Remediation for Requirements.


Note The Cisco NAC Web Agent does not support Auto Remediation.


Step 6 Choose an Anti-Spyware Vendor Name from the dropdown menu or choose ANY. The Products table lists all the spyware definition product versions currently supported per client OS.

Step 7 For the Requirement Name, type a unique name to identify this AS definition file requirement in the Agent. The name will be visible to users on the Clean Access Agent and Cisco NAC Web Agent dialogs.

Step 8 In the Description field, type a description of the requirement and instructions to guide users who fail to meet the requirement. For an AS Definition Update requirement, you should include an instruction alerting Cisco NAC Web Agent users of the requirement and for Clean Access Agent users to click the Update button to update their systems.

Step 9 Click the checkbox for at least one client Operating System (at least one must be chosen).

Step 10 Click Add Requirement to add the requirement to the Requirement List.


Configuring a Windows Server Update Services Requirement


Note For non-admin users, use of the Agent Stub is mandatory for WSUS requirements. Refer to Clean Access Agent Stub Installer, page 10-17 for details.


The Clean Access Agent "Windows Server Update Services" requirement type allows administrators to launch Windows Server Update Services (WSUS) on Agent user machines based on the following:

Cisco Rules (e.g. pr_<Windows operating system>_hotfixes) and/or administrator-configured custom rules for a specific Windows operating system

Windows Update severity checks

If you choose to validate Windows client machines using "Cisco Rules," you must also map the WSUS requirement to one or more rules in the CAM. You can choose to map the requirement to existing Cisco (pr_hotfix) rules or to custom rules you create to ensure client machines meet specific criteria before granting access to the Cisco NAC Appliance network. Because external server access is not required, using Cisco Rules can provide for quicker client validation and user login. However, client machines are only checked against "Critical" hotfixes encompassed by the Cisco Rules. For details on pr_rules, see Configuring Custom Checks, Rules, and Requirements.

If you choose to validate client machines using Windows Update "Severity" options, you do not have to configure requirement-rule mapping and you can choose the level of hotfix to check against. The "Severity" posture assessment settings require access to external WSUS update servers to both verify client machine security compliance and install Windows updates, which can take a significantly longer period of time to complete.

The "Windows Server Update Services" requirement provides an Update button on the Clean Access Agent for remediation. When the end user clicks the Update button, the Clean Access Agent launches the Automatic Updates Agent and forces it to get the update software from a Microsoft-managed or local/third-party-managed WSUS server. You can make the WSUS requirement Mandatory, however, the software download from WSUS servers can take some time (particularly if you are using "Severity" settings to validate client machines). Therefore, Cisco recommends making the WSUS requirement "Optional" so that WSUS remediation takes place as a background process on the client machine.


Note The Cisco NAC Web Agent only supports Go To Link manual remediation functionality. Cisco NAC Web Agent does not support Update, Download, or Launch remediation actions, nor Auto Remediation.


If you only need to enable or disable Windows Updates (that is, if you do not require specific updates based on the Microsoft severity level), you can configure a standard Windows Update requirement instead of a WSUS requirement. For more information, see Configuring a Windows Update Requirement.

Prerequisites

The network administrator must ensure the Automatic Updates Agent is updated to support a local WSUS server to support auto-launch capabilities. For details, refer to:

http://www.microsoft.com/windowsserversystem/updateservices/evaluation/faqs.mspx

Non-admin users must use the Agent Stub installer to execute WSUS requirements. Refer to Clean Access Agent Stub Installer, page 10-17 for additional details.

The "Windows Server Update Services" requirement type is only for Windows 2000, Windows XP, and Windows Vista.

In order to support Windows Server Update Services operations, client machines must have version 5.4.3790.1000 (or a more recent version) of the WUAUENG.dll file installed.

Some Microsoft Windows components (i.e., Internet Explorer 7) require admin privileges in order to successfully update. If the user does not have admin privileges on the client machine, the Windows update process returns a "WU_E_NO_INTERACTIVE_USER" error. Therefore, Cisco recommends making any Windows updates requiring admin privileges "Optional" to minimize update failures. For details, refer to:

http://msdn2.microsoft.com/en-us/library/aa387289.aspx

WSUS forced updates can take a while. They are launched and run in the background.

If there are update errors, refer to C:\Windows\Windows Update.log or C:\Windows\WindowsUpdate.log on the client machine.

The steps to create a Windows Server Update Service Requirements are:


Step 1 Create Windows Server Update Service Requirement

Step 2 Map Windows Server Update Service Requirement to Windows Rules

Step 3 Apply Requirements to User Roles

Step 4 Validate Requirements


Create Windows Server Update Service Requirement

Use the following steps to configure a Windows Server Update Service (WSUS) requirement.


Step 1 Go to Device Management > Clean Access > Clean Access Agent > Requirements > New Requirement.

Figure 11-8 New Windows Server Update Service Requirement

Step 2 From the Requirement Type dropdown menu, choose Windows Server Update Services.

Step 3 Choose an Enforce Type from the dropdown menu:

Mandatory—Enforce requirement.The user is informed of this requirement and cannot proceed or have network access unless the client system meets it.

Optional— Do not enforce requirement. The user is informed of the requirement but can bypass it if desired (by clicking Next in the Agent dialog). The client system does not have to meet the requirement for the user to proceed or have network access.

Audit—Silently audit. The client system is checked "silently" for the requirement without notifying the user, and a report is generated. The report results (pass or fail) do not affect user network access.

Refer to Configuring an Optional/Audit Requirement for details.

Step 4 Choose the Priority of execution for this requirement on the client. A high priority (e.g. 1) means this requirement is checked on the system ahead of all other requirements (and appears in the Agent dialogs in that order). Note that if this is a Mandatory requirement and it fails, the Agent does not continue past that point until that requirement succeeds.

Step 5 If you want to enable and configure Auto Remediation for the Clean Access Agent:

a. Choose the Remediation Type [Manual | Automatic] from the dropdown menu. Choosing Manual preserves previous Agent behavior. The user has to click through each of the requirements using the Next button in the Clean Access Agent. Choosing Automatic sets the Agent to perform Auto Remediation, where the Agent automatically performs updates or launches required programs on the client after the user logs in.

b. If you configure the requirement to use automatic remediation, specify the Interval in seconds (the default interval is 0). Depending on the requirement type, this interval either sets the delay before the Agent re-attempts remediation or sets the total time allowed for a particular remediation process.

c. Enter the Retry Count []. Specifying a retry count sets a limit on the number of times the Agent automatically retries the requirement if it initially fails. (The default retry count setting is 0.)

For details on configuring Auto Remediation, see Configuring Auto Remediation for Requirements.


Note The Cisco NAC Web Agent does not support Auto Remediation.


Step 6 Under Windows Updates Validation by, specify the validation method to use when checking the Windows operating system installed on the client machine:

Cisco Rules—Use Cisco Rules (e.g. pr_<Windows operating system>_Hotfixes) or similar administrator-configured custom rules on the CAM to verify whether the client Windows operating system meets minimum security standards. This is the faster method to assess the client machine's security posture, as it relies on criteria available in the CAM's local database. For fastest execution, Cisco recommends using Cisco Rules as the validation method with Express installation (which installs "Critical and Important" Windows updates) and Windows Servers as the installation source.


Note If you choose this option, you also need to configure requirement-rule mapping, as described in Map Windows Server Update Service Requirement to Windows Rules.

If you wish to validate against your own custom rules, Cisco recommends that you configure them similarly to an existing Cisco Rule (e.g pr_<Windows operating system>_Hotfixes). You should know the level of severity of the hotfix to check for (e.g. "Important" vs. "Low"). Refer to Copying Checks and Rules for details.


Severity—Verify whether or not the Windows operating system on the client meets minimum security standards using a Microsoft-managed or local Windows Update server. With this validation method, you do not need to map the WSUS requirement to any rules. However, the Severity setting requires the CAM to use an external WSUS server to verify updates currently installed on the client machine and then install the Windows updates necessary to meet the requirement. When you use locally-managed or hosted Windows (WSUS) servers to perform the Windows updates to satisfy a WSUS requirement, the WSUS server automatically installs all of the updates available for the specified severity level. (That is, if there are 5 "Important" updates and 3 "Critical" updates and the client machine already features some of the updates, the WSUS installer still automatically installs all of the updates specified by the requirement type.) As a result, validating client matches based on severity can take a longer period of time to assess and remediate.


Note You set the validation method to coincide with the Severity option using the Windows Updates Installation Sources setting in step 9.


Step 7 Under Windows Updates to be Installed, specify the level of updates to install. The validation method essentially checks what's missing on the machine to trigger an update. The actual update will originate from Microsoft or WSUS servers. The number of updates installed depends on the level of updates you choose here. For example, if you choose validation by Cisco Rules, which only checks for Critical hotfixes, but choose Custom Windows Updates to be Installed, with a level of Medium, all "Critical, Important, and Moderate" hotfixes will be installed on the client, but only if the client is missing Critical hotfixes to begin with.

Express—This option installs the same Windows updates as would be available from the Windows Update application "Express" option. Typically, the "Express" option includes only the "Important and Critical" Windows updates. However, if the Microsoft version of the Express update includes other installations (like a Service Pack update, for example), then all of the updates are automatically installed on the client machine.

Custom—Use this setting and the associated dropdown menu to install updates based on their severity by choosing Critical, Medium, or All from the associated dropdown menu.

Critical—Installs only "Critical" Microsoft Windows updates.

Medium—Installs all "Critical, Important, and Moderate" Windows updates.

All—Installs all "Critical, Important, Moderate, and Low" Windows updates.

In all cases, the WSUS server automatically downloads all of the updates to install on the client. Therefore, even if the client machine already features 3 of 5 updates of a given severity, the WSUS server still downloads and installs all updates.

Step 8 Click Upgrade to Latest OS Service Pack to automatically install the latest service pack available for the user's operating system.


Note This option is automatically included in the install process when you specify either Medium or All Custom updates, above, and cannot be "left out." If you specified Critical Custom updates, you can choose to enable or disable this option.

Cisco Rules validate all "Critical" Windows updates and verify whether or not minimum Windows 2000 Service Pack and Windows XP Service Pack updates are installed on the client machine. If you choose to require only "Critical" Windows Updates to be Installed, Windows 2000 Service Pack 4 and Windows XP Service Pack 2 may not be present on the client machine, hence, the client machine will not pass posture assessment via "Cisco Rules." To address this potential problem, Cisco recommends that if you choose to validate client machines using "Cisco Rules" and require only "Critical" updates, that you also require Service Pack Updates to ensure any clients validated using "Cisco Rules" pass posture assessment. (If you choose to validate client machines according to "Severity" rather than "Cisco Rules," this is not an issue.)



Note Windows Service Pack updates traditionally take a long time to download and install. Before you require users to update their Windows operating system with a full service pack installation, be sure you extend the session timeout period for Temporary Role users to accommodate the long install and update process. (See Configure Session Timeout for the Temporary Role, page 8-19.)


Step 9 For Windows Updates Installation Sources, specify the source for the Windows update(s):

Windows Servers—Updates the Windows operating system using Microsoft-managed Windows update servers.

Managed WSUS Servers—Updates the Windows operating system using resources managed by the Windows server administrator or other trusted third-party source.

Step 10 For Installation Wizard Interface Setting, specify whether or not the user sees the Installation Wizard user interface during Windows Update installation:

Show UI—The Windows Update Installation Wizard progress is visible to users during the update process so they can tell what components are being updated and when the update completes. (Users must have Administrator privileges on the client machine in order to see the Installation Wizard user interface during Windows Update.)

No UI—The Windows Update takes place in the background once the update process has begun and the user is only notified when the update is complete.

Step 11 For the Requirement Name, type a unique name to identify this requirement in the Agent. The name will be visible to users on the Clean Access Agent and Cisco NAC Web Agent dialogs.

Step 12 In the Description field, type a description of the requirement and instructions to guide users who fail to meet the requirement, including instructions for Clean Access Agent users to click the Update button to update their systems. Note that Windows Server Update Service displays the Update button on the Clean Access Agent.

Step 13 Click one or more of the following checkboxes to set the Operating System(s) for the requirement:

Windows 2000

Windows XP (All) or one or more of the specific Windows XP operating systems

Windows Vista (All) or one or more of the specific Windows Vista operating systems

Step 14 Click Add Requirement.

Step 15 If you configured the WSUS requirement for "Windows Updates Validation by Cisco Rules," continue to the next step, Map Windows Server Update Service Requirement to Windows Rules.

Otherwise, continue to the next steps to complete the configuration:

Apply Requirements to User Roles

Validate Requirements


Map Windows Server Update Service Requirement to Windows Rules

Perform the steps in this section if you configured a Windows Server Update Service requirement for Windows Updates Validation by Cisco Rules. (See Create Windows Server Update Service Requirement.)

If you specified Windows Updates Validation by Severity, you do not need to map the Windows Server Update Service to an existing Windows Rule and you can skip this section.

Use the following steps to map a Windows Server Update Service requirement to a Windows rule.


Step 1 Go to Device Management > Clean Access > Clean Access Agent > Requirements > Requirement-Rules.

Figure 11-9 Map Windows Update Requirement to Rules

Step 2 From the Requirement Name dropdown menu, choose the Windows Server Update Service (WSUS) requirement you configured.

Step 3 To configure the Windows Server Update Service requirement-rule mapping, repeat the following procedure for each operating system you want to validate for this requirement:

a. In the Operating System dropdown menu, choose one of the operating systems you configured for the requirement in step 13 of Configuring a Windows Server Update Services Requirement.

Rules are categorized in the system according to the operating system for which they are configured. The Operating System dropdown determines which Rules appear for selection in the "Rules for Selected Operating System" table at the bottom of the page. For example, if you want to map multiple hotfix rules to a requirement you configured for Windows XP (All), in the Requirement-Rule page, you must individually select each flavor of Windows XP (e.g.Windows XP Pro/Home, Windows XP Tablet PC, Windows XPMedia Center) from the Operating System dropdown to be able to view and select the pr_hotfix rules for each of those OS flavors (e.g. pr_XP_Hotfixes, pr_XP_TabletPC_Hotfixes, and pr_XP_MCE_Hotfixes, respectively) in the "Rules for Selected Operating System" list.

b. Choose one of the following options for Requirement met if:

All selected rules succeed (default)—all the rules must be satisfied for the client to be considered in compliance with the requirement.

Any selected rule succeeds—at least one selected rule must be satisfied for the client to be considered in compliance with the requirement.

No selected rule succeeds—the selected rules must all fail for the client to be considered in compliance with the requirement.

c. Ignore the AV Virus/AS Spyware Definition rule options.

d. The Rules for Selected Operating System list will display all rules that exist in the system for the chosen OS (pr_ rules or rules that you have configured). Click the checkbox for each rule you want to enable for this requirement. Rules that are typically associated to this requirement are:

pr_AutoUpdateCheck_Rule (Windows XP (All), Windows 2000)

pr_XP_Hotfixes (Windows XP Pro/Home)

pr_2K_Hotfixes (Windows 2000)

pr_Vista_<version>_Hotfixes (Windows Vista Home Basic/Premium, Business, Ultimate, Enterprise)

Note that all rules are listed under Device Management > Clean Access > Clean Access Agent > Rules > Rule List.

e. Click Update to complete the mapping.

Step 4 Continue to the next steps—Apply Requirements to User Roles and Validate Requirements—to complete the configuration.


Configuring a Windows Update Requirement

The Agent "Windows Update" Requirement type configuration page allows administrators to check and modify Windows Update settings, and launch Windows Updater on Agent user machines.

When this requirement is configured, the administrator can turn on Automatic Updates on Windows Vista, Windows 2000, or Windows XP client machines which have this option disabled on the machine.

The Windows Update requirement (set to Optional by default) provides an Update button on the (persistent) Clean Access Agent for remediation. When the end user clicks the Update button, the Clean Access Agent launches the Automatic Updates Agent and forces it to get the update software from an external WSUS server. The software download from the WSUS server may take some time. Therefore, Cisco recommends you keep the Windows Update requirement Optional so that remediation occurs in the background.


Note The Cisco NAC Web Agent only supports Go To Link manual remediation functionality. Cisco NAC Web Agent does not support Update, Download, or Launch remediation actions, nor Auto Remediation.


Windows operating systems can be customized in many ways to include hotfixes and service packs as part of the operating system installation. In some cases, the Clean Access Agent may not be able to detect hotfix key values in the registry when the hotfix is part of the operating system. In these cases, Cisco recommends using the Windows Server Update Services (WSUS) requirement, which can be configured to access external Windows Updates servers. For more information, see Configuring a Windows Server Update Services Requirement.

Prerequisites

The Windows Server Update Services requirement type applies only to Windows 2000, Windows XP, and Windows Vista client machines. It supports checking Cisco- and Windows-based client operating system verification and customized update installation options based on update severity.

The network administrator must ensure the Automatic Updates Agent is updated to support a local WSUS server to support auto-launch capabilities. For details, refer to http://www.microsoft.com/windowsserversystem/updateservices/evaluation/faqs.mspx

In order to support Windows Server Update Services operations, client machines must have version 5.4.3790.1000 (or a more recent version) of the WUAUENG.dll file installed.

For non-admin users, the Clean Access Agent Stub service must be installed and running on the client machine to execute WSUS requirements. Refer to Clean Access Agent Stub Installer, page 10-17 for additional details.

WSUS forced update may take a while. Generally, it is launched and run in the background.

Some Microsoft Windows components (such as Internet Explorer 7) require admin privileges in order to successfully update. If the user does not have admin privileges on the client machine, the Windows update process returns a "WU_E_NO_INTERACTIVE_USER" error. Therefore, Cisco recommends making any Windows updates requiring admin privileges "Optional" to minimize update failures. For details, refer to http://msdn2.microsoft.com/en-us/library/aa387289.aspx.

If there are update errors, see C:\Windows\Windows Update.log or C:\Windows\WindowsUpdate.log.

The steps to configure a Windows Update requirements are as follows:


Step 1 Create a Windows Update Requirement

Step 2 Map Windows Update Requirement to Windows Rules

Step 3 Apply Requirements to User Roles

Step 4 Validate Requirements


Create a Windows Update Requirement

Use the following steps to configure a Windows Update requirement.


Step 1 Go to Device Management > Clean Access > Clean Access Agent > Requirements > New Requirement.

Figure 11-10 New Windows Update Requirement

Step 2 From the Requirement Type dropdown menu, choose Windows Update.

Step 3 Choose an Enforce Type from the dropdown menu:

Optional (default setting)—Do not enforce requirement. The user is informed of the requirement but can bypass it if desired (by clicking Next in the Agent dialog). The client system does not have to meet the requirement for the user to proceed or have network access.


Note The Windows Update requirement type is set to Optional (or "do not enforce") by default to optimize user experience by running the update process in the background. Cisco also recommends leaving this requirement as Optional if selecting the "Automatically download and install" option.


Mandatory—Enforce requirement.The user is informed of this requirement and cannot proceed or have network access unless the client system meets it.

Audit—Silently audit. The client system is checked "silently" for the requirement without notifying the user, and a report is generated. The report results (pass or fail) do not affect user network access.

Refer to Configuring an Optional/Audit Requirement for details.

Step 4 Choose the Priority of execution for this requirement on the client. A high priority (e.g. 1) means this requirement is checked on the system ahead of all other requirements (and appears in the Agent dialogs in that order). Note that if this is a Mandatory requirement and it fails, the Agent does not continue past that point until that requirement succeeds.

Step 5 If you want to enable and configure Auto Remediation for the Clean Access Agent:

a. Choose the Remediation Type [Manual | Automatic] from the dropdown menu. Choosing Manual preserves previous Agent behavior. The user has to click through each of the requirements using the Next button in the Clean Access Agent. Choosing Automatic sets the Agent to perform Auto Remediation, where the Agent automatically performs updates or launches required programs on the client after the user logs in.

b. If you configure the requirement to use automatic remediation, specify the Interval in seconds (the default interval is 0). Depending on the requirement type, this interval either sets the delay before the Agent re-attempts remediation or sets the total time allowed for a particular remediation process.

c. Enter the Retry Count []. Specifying a retry count sets a limit on the number of times the Agent automatically retries the requirement if it initially fails. (The default retry count setting is 0.)

For details on configuring Auto Remediation, see Configuring Auto Remediation for Requirements.


Note The Cisco NAC Web Agent does not support Auto Remediation.


Step 6 From the Windows Update Setting dropdown, choose one of the following options:

Do not change setting

Notify to download and install

Automatically download and notify to install

Automatically download and install

These settings correspond to the Automatic Updates dialog settings on the Windows client (Figure 11-11)

Step 7 Click the checkbox for Permanently override user setting with administrator Windows Update Setting, if you want to enforce your administrator-specified setting for Automatic Updates on all client machines during and after Windows Update. If left unchecked, the admin setting will only apply when Automatic Updates are disabled on the client; otherwise the user setting applies when Automatic Updates are enabled.

Step 8 For the Requirement Name, type a unique name to identify this requirement in the Agent. The name will be visible to users on the Clean Access Agent and Cisco NAC Web Agent dialogs.

Step 9 In the Description field, type a description of the requirement and instructions to guide users who fail to meet the requirement, including instructions for Clean Access Agent users to click the Update button to update their systems. Note that Windows Update displays the Update button on the Clean Access Agent.

Step 10 Click one or more of the following checkboxes to set the Operating System(s) for the requirement:

Windows 2000

Windows XP (All) or one or more of the specific Windows XP operating systems

Windows Vista (All) or one or more of the specific Windows Vista operating systems


Note Make sure the operating system you choose matches the operating system you set for the rule(s) you plan to map to this Windows Update requirement in Configuring a Windows Server Update Services Requirement.


Step 11 Click Add Requirement.

Figure 11-11 Windows XP Automatic Updates


Map Windows Update Requirement to Windows Rules

Use the following steps to map a Windows Update requirement to one or more rules.


Step 1 Go to Device Management > Clean Access > Clean Access Agent > Requirements > Requirement-Rules.

Figure 11-12 Map Windows Update Requirement to Rules

Step 2 From the Requirement Name dropdown menu, choose the Windows Update requirement you configured.

Step 3 To configure the Windows Update requirement-rule mapping, repeat the following procedure for each operating system you want to support:

a. In the Operating System dropdown menu, choose one of the operating systems you configured for the requirement in step 10 of Configuring a Windows Update Requirement.

Rules are categorized in the system according to the operating system for which they are configured. The Operating System dropdown determines which Rules appear for selection in the "Rules for Selected Operating System" table at the bottom of the page. For example, if you want to map multiple hotfix rules to a requirement you configured for Windows XP (All), in the Requirement-Rule page, you must individually select each flavor of Windows XP (e.g.Windows XP Pro/Home, Windows XP Tablet PC, Windows XPMedia Center) from the Operating System dropdown to be able to view and select the pr_hotfix rules for each of those OS flavors (e.g. pr_XP_Hotfixes, pr_XP_TabletPC_Hotfixes, and pr_XP_MCE_Hotfixes, respectively) in the "Rules for Selected Operating System" list.

b. Choose one of the following options for Requirement met if:

All selected rules succeed (default)—all the rules must be satisfied for the client to be considered in compliance with the requirement.

Any selected rule succeeds—at least one selected rule must be satisfied for the client to be considered in compliance with the requirement.

No selected rule succeeds—the selected rules must all fail for the client to be considered in compliance with the requirement.

c. Ignore the AV Virus/AS Spyware Definition rule options.

d. The Rules for Selected Operating System list will display all rules that exist in the system for the chosen OS (pr_ rules or rules that you have configured). Click the checkbox for each rule you want to enable for this requirement. Typical rules that are associated to this requirement are:

pr_AutoUpdateCheck_Rule (Windows XP (All), Windows 2000)

pr_XP_Hotfixes (Windows XP Pro/Home)

pr_2K_Hotfixes (Windows 2000)

pr_Vista_<version>_Hotfixes (Windows Vista Home Basic/Premium, Business, Ultimate, Enterprise)

Note that all rules are listed under Device Management > Clean Access > Clean Access Agent > Rules > Rule List.

e. Click Update to complete the mapping.

Step 4 Continue to the next steps—Apply Requirements to User Roles and Validate Requirements—to complete the configuration.


Configuring Custom Checks, Rules, and Requirements

A check is a condition statement used to examine the client system. In the simplest case, a requirement can be created from a single rule made up of a single check. If the condition statement yields a true result, the system is considered in compliance with the Agent requirement and no remediation is necessary.

To create a check, first determine an identifying feature of the requirement. The feature (such as a registry key or process name) should indicate whether the client meets the requirement. The best way to find such an indicator is to examine a system that meets the requirement. If necessary, refer to the documentation provided with the software to determine what identifying feature to use for the Clean Access check. Once you have determined the indicator for the requirement, use the following procedure to create the check.

Custom Requirements

You can create custom requirements to map rules to the mechanism that allows users to meet the rule condition. The mechanism may be an installation file, a link to an external resource, or simply instructions. If a rule check is not satisfied (for example, required software is not found on the client system), users can be warned or required to fix their systems, depending on your configuration. As shown in Figure 11-13, a rule can combine several checks with Boolean operators, "&" (and), "|" (or), and "!" (not). A requirement can rely on more than one rule, specifying that any selected rule, all rules, or no rule must be satisfied for the client to be considered in compliance with the requirement.

Figure 11-13 Custom Checks, Rules, and Requirements

Custom Rules

A rule is a condition statement made up of one or more checks. A rule combines checks with logical operators to form a Boolean statement that can test multiple features of the client system.

Cisco Pre-Configured Rules ("pr_")

Cisco NAC Appliance provides a set of pre-configured rules and checks that are downloaded to the CAM via the Updates page on the CAM web console (under Device Management > Clean Access > Updates).

Pre-configured rules have a prefix of "pr" in their names (e.g. "pr_XP_Hotfixes"), and can be copied for use as a template, but cannot be edited or removed. You can click the Edit button for any "pr_" rule to view the rule expression that defines it. The rule expression for a pre-configured rule will be composed of pre-configured checks (e.g. "pc_Hotfix835732") and boolean operators. The rule expressions for pre-configured rules are updated via Cisco Updates. For example, when new Critical Windows OS hotfixes are released for Windows XP, the pr_XP_Hotfixes rule will be updated with the corresponding hotfix checks.

Pre-configured rules are listed under Device Management > Clean Access > Clean Access Agent > Rules > Rule List.


Note Cisco pre-configured rules are intended to provide support for Critical Windows operating system hotfixes only.


Custom Checks

A check is a condition statement that examines a feature of the client system, such as a file, registry key, service, or application. Table 11-1 lists the types of custom checks available and what they test.

Table 11-1 Checks

Check Category
Check Type

Registry check

whether or not a registry key exists

registry key value, version, or modification date

File Check

whether or not a file exists

date of modification or creation

file version

Service check

whether or not a service is running

Application check

whether or not an application is running


Cisco Pre-Configured Checks ("pc_")

Pre-configured checks have a prefix of "pc" in their names (for example, pc_Hotfix828035) and are listed under Device Management > Clean Access > Clean Access Agent > Rules > Check List.

Using Pre-Configured Rules to Check for CSA

You can use Cisco pre-configured rules to create an Agent requirement that checks if the Cisco Security Agent (CSA) is already installed and/or running on a client. To do this:

1. Create a new Link Distribution or File Distribution requirement (for Windows Vista/XP/2000).

2. Associate the requirement to one or both of the following rules (for Windows Vista/XP/2000):

pr_CSA_Agent_Version_5_0

pr_CSA_Agent_Service_Running

3. Associate the requirement to the user role(s) for which it will apply.


Note See Configuration Summary for further details on creating custom requirements (using either pre-configured or custom rules).


Copying Checks and Rules

Note that pre-configured rules and checks are not editable, but can serve as templates. To modify a non-editable check or a rule, make a copy of it first by clicking the corresponding Copy button. Copies of checks are added to the bottom of the Check List, in the form copy_of_checkname. Copies of rules are added to the bottom of the Rules List, in the form copy_of_rulename. Click the corresponding Edit button to bring up the Edit form to modify the check or rule. The edited checks and rules can then be configured and associated to requirements and roles as described in the following sections.

Configuration Summary

The steps to create custom requirements are as follows:


Step 1 Create Custom Check

Step 2 Create a Custom Rule

Step 3 Validate Rules

Step 4 Create a Custom Requirement

Step 5 Map Requirements to Rules

Step 6 Apply Requirements to User Roles

Step 7 Validate Requirements


Create Custom Check

Use the following steps to configure a custom Check.


Step 1 In the Clean Access Agent tab, click the Rules submenu and then open the New Check page.

Figure 11-14 New Check


Note For all custom checks, follow steps 2 through 7, refer to the specific configuration settings for each check type, then go to step 8.


Step 2 Select a Check Category: Registry Check, File Check, Service Check, or Application Check.

Step 3 Select a Check Type for the Category and fill in specific form fields as described in the following section. Specify the parameters, operator, and (if the check type is a value comparison) the value and data type of the statement, and click Add Check to create the evaluation statement. If the condition statement evaluates to false, the required software is considered missing.

Registry Checks

File Checks

Service Check

Application Check

Step 4 Type a descriptive Check Name. The rules created from this check will reference the check by this name, so be sure to give the check a unique, self-descriptive name. The name is case-sensitive and should be less than 255 characters and without spaces or special characters.

Step 5 Type an optional Check Description.

Step 6 Click one or more of the following checkboxes to set the Operating System(s) for the requirement:

Windows All

Windows 2000

Windows ME

Windows 98

Windows XP (All) or one or more of the specific Windows XP operating systems

Windows Vista (All) or one or more of the specific Windows Vista operating systems

Step 7 If desired, select "Automatically create rule based on this check". In this case, the rule is automatically populated with the check when added and is named "checkname-rule".

Step 8 Click Add Check when finished.

Registry Checks

Registry Key—Checks whether a specific key exists in the registry.

Registry Value (Default)—Checks whether an unnamed (default) registry key exists or has a particular value, version, or modification date.

Registry Value—Checks whether a named registry key exists or has a particular value, version, or modification date.

Figure 11-15 Registry Check Types

a. For the Registry Key field, select the area of the client registry:

HKLM - HKEY_LOCAL_MACHINE

HKCC - HKEY_CURRENT_CONFIG

HKCU - HKEY_CURRENT_USER

HKU - HKEY_USERS

HKCR - HKEY_CLASSES_ROOT

Then type the path to be checked.

For example: HKLM \SOFTWARE\Symantec\Norton AntiVirus\version

b. For a Registry Value search, enter a Value Name.

c. For Registry Value searches, enter a Value Data Type:

1. For a "Number" Value Data Type (Note: REG_DWORD is equivalent to Number), choose one of the following Operators from the dropdown: equals, greater than, less than, does not equal, greater than or equal to, less than or equal to

2. For a "String" Value Data Type choose one of the following Operators from the dropdown: equals, equals (ignore case), does not equal, starts with, does not start with, ends with, does not end with, contains, does not contain.

3. For a "Version" Value Data Type choose one of the following Operators from the dropdown: earlier than, later than, same as.

4. For a "Date" Value Data Type, choose one of the following Operators from the dropdown: earlier than, later than, same as.

d. If specifying a "Date" Value Data Type, also choose one of two values to check. This allows you to specify "older than" or "newer than" by more than/fewer than x days to the current date.

Type the date/time of the client machine in mm/dd/yyyy hh:MM:ss format.

Choose the CAM date, + or - from the dropdown, and type the number of days.

e. Type the Value Data for a Registry Value search.


Note For the "String" Value Data Type, the maximum length for a string is 256 characters.


File Checks

File Existence—Checks whether a file exists on the system.

File Date—Checks whether a file with a particular modification or creation date exists on the system.

File Version—Checks whether a particular version of a file exists on the system.

Figure 11-16 File Check Types

a. For File Path, select:

SYSTEM_DRIVE - checks the C:\ drive

SYSTEM_ROOT - checks the root path for Windows 98 systems

SYSTEM_32 - checks C:\WINDOWS\SYSTEM32

SYSTEM_PROGRAMS - checks C:\Program Files

b. For Operator, select:

exists or does not exist - File Existence check

earlier than, later than, same as - File Date or File Version check

c. For a File Date check type, also choose one of two values to check for File Date. This allows you to specify "older than" or "newer than" by more than/fewer than x days to the current date.

Type the date/time of the client machine in mm/dd/yyyy hh:MM:ss format

Choose the CAM date, + or - from the dropdown, and type the number of days

d. For a File Date check type, select a File Date Type:

Creation date

Modification date

Service Check

Service Status - Whether a service is currently running on the system.

Figure 11-17 Service Check Type

a. Enter a Service Name.

b. Select an Operator:

running

not running

Application Check

Application Status - Whether an application is currently running on the system.

Figure 11-18 Application Check Type

a. Enter an Application Name.

b. Select an Operator: running or not running.


Create a Custom Rule

A rule is an expression made up of checks and operators. A rule is the unit used by the Agent to assess a vulnerability on a particular operating system. The result of the rule expression is considered to assess compliance with the Agent requirement. A rule can be made up of a single check or it can have multiple checks combined with Boolean operators. Table 11-2 shows the operators along with their order of evaluation.

Table 11-2 Rule Operators

Priority
Operator
Description

1

()

parens for evaluation priority

2

!

not

3

&

and

3

|

or


Operators of equal priority are evaluated from left to right. For example, a rule may be defined as follows:

adawareLogRecent & (NorAVProcessIsActive | SymAVProcessIsActive) 

The adawareLogRecent check and either the NorAVProcessIsActive check or the SymAVProcessIsActive check must be satisfied for the rule to be considered met. Without parentheses, the following would be implied:

(adawareLogRecent & NorAVProcessIsActive) | SymAVProcessIsActive

In this case, either SymAVProcessIsActive or both of the first two checks must be true for the rule to be considered met.

Use the following steps to create a custom Rule.


Step 1 In the Clean Access Agent tab, click the Rules submenu link and then New Rule.

Figure 11-19 New Rule

Step 2 Type a unique Rule Name.

Step 3 Enter a Rule Description.

Step 4 Select the Operating System for which the rule applies. If Updates have been downloaded, the pre-configured checks for that operating system appear in the Checks for Selected Operating System list below.

Step 5 Create the Rule Expression by combining checks and operators. Use the list to select the names of checks and copy and paste them to the Rule Expression text field. Use the following operators with the checks: () (evaluation priority), ! (not), & (and), | (or).

For example:

adawareLogRecent & (NorAVProcessIsActive | SymAVProcessIsActive) 

For a simple rule that tests a single check, simply type the name of the check:

SymAVProcessIsActive 

Step 6 Click Add Rule.

The console validates the rule and, if formed correctly, the rule appears in the Rule List. From there, you can delete the rule, modify it, or copy it (create a new rule by copying this one).


Validate Rules

The Clean Access Manager automatically validates rules and requirements as they are created. Invalid rules have incompatibilities between checks and rules, particularly those relating to the target operating system. These errors can arise when you create checks and rules for a particular operating system but later change the operating system property for a check. In this case, a rule that uses the check and which is still applicable for the formerly configured operating system is no longer valid. Rule validation detects these and other errors.

The Validity column under Device Management > Clean Access > Clean Access Agent > Rules > Rule List displays a blue checkmark if the rule is valid and a red "X" if the rule is invalid. Highlight this icon with your mouse to reveal which check is causing the rule to be invalid, in the form:

Invalid rule [rulename], Invalid check [checkname] in rule expression. 

Figure 11-20 Rule List

Use the following steps to correct an invalid Rule.


Step 1 Go to Device Management > Clean Access > Clean Access Agent > Rules > Rule List.

Step 2 Click the Edit button for the invalid rule.

Step 3 Correct the invalid Rule Expression. If the rule is invalid because a check has been deleted, make sure you associate the rule with a valid check.

Step 4 Make sure the correct Operating System. is selected.

Step 5 Make sure the Requirement met if: expression is correctly configured.

Step 6 Click Save Rule.

Step 7 Make sure any requirement based on this rule is also corrected as described in Validate Requirements.


Create a Custom Requirement

Custom requirements map a specified collection of rules for an operating system to the files, distribution links, or instructions that you want pushed to the user via Agent dialogs. Custom requirements can point to installation files or links where software can be downloaded. For local checks not associated with a specific installation file, the requirement can map the rule to an informational message, for example, instructing the user to remove software or run a virus check. A new requirement can be created at any time in the configuration process. However, the requirement must be associated to both a rule for an operating system and a user role before it can take effect.

Create File Distribution/Link Distribution/Local Check Requirement

Use the following steps to configure a custom requirement.


Step 1 In the Clean Access Agent tab, click the Requirements submenu link and then New Requirement.

Figure 11-21 New Requirement (File Distribution)

Step 2 Select a Requirement Type:

File Distribution - This distributes the required software directly by making the installation package available for user download using the Clean Access Agent. In this case, the file to be downloaded by the user is placed on the CAM using the File to Upload field. For the Clean Access Agent to download this file, a traffic policy allowing HTTP access only to the CAM should be created for the Temporary role. See Adding Traffic Policies for Default Roles, page 8-26.


Note The Cisco NAC Web Agent only supports Go To Link manual remediation functionality. Cisco NAC Web Agent does not support Update, Download, or Launch remediation actions, nor Auto Remediation.


Link Distribution - This refers users to another web page where the software is available, such as a software download page. Make sure the Temporary role is configured to allow HTTP (and/or HTTPS) access to the link.

Local Check - This is used when creating checks not associated with installable software, for example, to check if Windows Update Service (Automatic Updates) is enabled, or to look for software that should not be on the system.

Step 3 Choose an Enforce Type from the dropdown menu:

Mandatory—Enforce requirement.The user is informed of this requirement and cannot proceed or have network access unless the client system meets it.

Optional— Do not enforce requirement. The user is informed of the requirement but can bypass it if desired (by clicking Next in the Agent dialog). The client system does not have to meet the requirement for the user to proceed or have network access.

Audit—Silently audit. The client system is checked "silently" for the requirement without notifying the user, and a report is generated. The report results (pass or fail) do not affect user network access.

Refer to Configuring an Optional/Audit Requirement for details.

Step 4 Specify the Priority of the requirement. Requirements with the lowest number (e.g "1") have the highest priority and are performed first. If a requirement fails, the remediation instructions configured for the requirement are pushed to the user without additional requirements being tested. Therefore you can minimize processing time by putting the requirements that are most likely to fail at a higher priority.

Step 5 You can enable and configure Auto Remediation using the Clean Access Agent for a Link Distribution requirement type only. Refer to Configuring Auto Remediation for Requirements for details.


Note The Cisco NAC Web Agent does not support Auto Remediation.


Step 6 The Version field lets you keep track of various versions of a requirement. This is particularly useful when there are updates to the required software. You can use any versioning scheme you like, such as numbers (1, 2, 3), point numbers (1.0), or letters.

Step 7 If you chose File Distribution as the Requirement Type, click Browse next to the File to Upload field and navigate to the folder where you have the installation file (.exe) for the required software.

Step 8 If you chose Link Distribution as the Requirement Type, enter the URL of the web page where users can get the install file or patch update in the File Link URL field.

Step 9 For the Requirement Name type a unique name to identify the system requirement. The name will be visible to users on the Clean Access Agent and Cisco NAC Web Agent dialogs.

Step 10 In the Description field, type a description of the requirement and instructions for the benefit of your users. Note the following:

File Distribution displays a Download button on the Clean Access Agent.

Link Distribution displays a Go To Link button on the Clean Access Agent/Cisco NAC web Agent.

Local Check displays a Download button (disabled) on the Clean Access Agent.

Step 11 Select the Operating System for which the requirement applies (you must choose at least one).

Step 12 Click Add Requirement to save the settings for the download requirement.

Step 13 The requirement appears in the Requirement List.

Figure 11-22 shows an example of how requirement configuration fields display in the Clean Access Agent.

Figure 11-22 Example Optional Link Distribution Requirement


Configuring a Launch Programs Requirement


Note Version 4.1.0.0 or later of the Clean Access Agent is required to use this feature. This feature applies to Windows Vista, Windows 2000, and Windows XP machines only. Cisco NAC Web Agent does not support this requirement type.


The Launch Programs Requirement Type allows administrators to launch a qualified (signed) remediation program through the Clean Access Agent. The administrator can create a check/rule condition; upon its failure, the administrator can configure to launch any remediation program to fix the machine. Multiple programs are permitted, and they are launched in the same sequence as specified by the administrator.

The Clean Access Agent launches the programs in two ways, depending on whether the user has or does not have admin user privileges on the device.

Launch Programs With Admin Privileges

If the user has admin privileges on the client machine, any program that is an executable is qualified. The program is launched directly and digital signing and verification of the application are not required.

Launch Programs Without Admin Privileges

If the user does not have administrative privileges, the Clean Access Stub service must be installed on the client machine and the target executable is launched through the Agent Stub. (Refer to Clean Access Agent Stub Installer, page 10-17 for further details on the Agent Stub.) The Agent Stub will verify that the program is signed by a trusted certificate authority before launching the program. The executable must have:

A valid digital signature signed by certificates with specific field value(s)

File version information with specific item value(s)

How the Agent Verifies Digital Signature and Trust on an Executable Program

It is the administrator's responsibility to populate the required Registry Keys for the programs to be trusted by the Agent and Agent Stub, as described in this section. The Clean Access Agent Stub verifies the launch program for trusted digital signature as follows:

1. Verifies the digital signature - Ensures the digital signature is trusted.

2. Verifies the signer certificate information based on the information in the registry.

The related registry structure appears as follows:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CCAAgentStub\Trust<N>\

\Certificate\2.5.4.3 "Cisco Systems"

\FileVersionInfo\ProductName "Clean Access"

where <N> is a numeric number.

For the entries under Certificate, each value can be exact, and case-insensitive.

For the entries under FileVersionInfo, each value must appear in the corresponding value in the file information stream, and can be case-insensitive.

All the entries under Certificate and FileVersionInfo must be satisfied (AND operations) to qualify as a trusted target.

If any of the Trust<N> chain is satisfied, the target is qualified to launch.

Supported Value Names Under Certificate

2.5.4.3 - COMMON_NAME

2.5.4.4 - SUR_NAME

2.5.4.5 - DEVICE_SERIAL_NUMBER

2.5.4.6 - COUNTRY_NAME

2.5.4.7 - LOCALITY_NAME

2.5.4.8 - STATE_OR_PROVINCE_NAME

2.5.4.9 - STREET_ADDRESS

2.5.4.10 - ORGANIZATION_NAME

2.5.4.11 - ORGANIZATIONAL_UNIT_NAME

2.5.4.12 - TITLE

2.5.4.13 - DESCRIPTION

2.5.4.14 - SEARCH_GUIDE

2.5.4.15 - BUSINESS_CATEGORY

2.5.4.16 - POSTAL_ADDRESS

2.5.4.17 - POSTAL_CODE

2.5.4.18 - POST_OFFICE_BOX

2.5.4.19 - PHYSICAL_DELIVERY_OFFICE_NAME

2.5.4.20 - TELEPHONE_NUMBER

Supported Value Names Under FileVersionInfo

ProductName

CompanyName

FileDescription

FileVersion

InternalName

LegalCopyright

OriginalFileName

ProductVersion

Comments

LegalTrademarks

PrivateBuild

SpecialBuild

Refer to Launch Programs via Clean Access Agent Example for additional details.

Create a Launch Programs Requirement

Use the following steps to configure a Launch Programs requirement.


Step 1 Go to Device Management > Clean Access > Clean Access Agent > Requirements > New Requirement.

Figure 11-23 New Launch Program Requirement

Step 2 For Requirement Type choose Launch Programs.

Step 3 Choose an Enforce Type from the dropdown menu:

Mandatory—Enforce requirement.The user is informed of this requirement and cannot proceed or have network access unless the client system meets it.

Optional— Do not enforce requirement. The user is informed of the requirement but can bypass it if desired (by clicking Next in the Agent dialog). The client system does not have to meet the requirement for the user to proceed or have network access.

Audit—Silently audit. The client system is checked "silently" for the requirement without notifying the user, and a report is generated. The report results (pass or fail) do not affect user network access.

Refer to Configuring an Optional/Audit Requirement for details.

Step 4 Choose the Priority of execution for this requirement on the client. A high priority (e.g. 1) means this requirement is checked on the system ahead of all other requirements (and appears in the Clean Access Agent dialogs in that order). Note that if a Mandatory requirement fails, the Agent does not continue past that point until that requirement succeeds.

Step 5 If you want to enable and configure Auto Remediation for the Clean Access Agent:

a. Choose the Remediation Type [Manual | Automatic] from the dropdown menu. Choosing Manual preserves previous Agent behavior. The user has to click through each of the requirements using the Next button in the Clean Access Agent. Choosing Automatic sets the Agent to perform Auto Remediation, where the Agent automatically performs updates or launches required programs on the client after the user logs in.

b. If you configure the requirement to use automatic remediation, specify the Interval in seconds (the default interval is 0). Depending on the requirement type, this interval either sets the delay before the Agent re-attempts remediation or sets the total time allowed for a particular remediation process.

c. Enter the Retry Count []. Specifying a retry count sets a limit on the number of times the Agent automatically retries the requirement if it initially fails. (The default retry count setting is 0.)

For details on configuring Auto Remediation, see Configuring Auto Remediation for Requirements.


Note The Cisco NAC Web Agent does not support Auto Remediation.


Step 6 Configure the program to be launched as follows:

a. For the Program Name, choose the root location from which to launch the program from the dropdown: SYSTEM_DRIVE, SYSTEM_ROOT, SYSTEM_32, SYSTEM_PROGRAMS, or None, and type the name of the program executable in the adjoining text field.

b. If a more specific path or program parameters are needed, type them in the Program Parameters text field.

c. Click Add Program. This adds the Program Name and Program Parameters to the sublist of programs to launch for the requirement.

d. Configure more programs to add, or click the Delete checkbox to remove programs from the list.

Step 7 When done configuring the program or list of programs to added, type the Requirement Name.

Step 8 Type a Description to be displayed to users.

Step 9 Click the checkbox for the Windows Operating System for which this requirement applies.

Step 10 Click Add Requirement.


Note See Launch Programs via Clean Access Agent Example for additional details.



Launch Programs via Clean Access Agent Example

The following example shows how to use Launch Programs to launch a qualified (signed) program via the Clean Access Agent. If using a CA authority to sign the program, you can skip the steps related to how to perform your own application signing in the example.

If the user has admin privileges on the client machine, any program that is an executable is qualified. If the user does not have admin privileges, the target executable is launched via Agent Stub (refer to Configuring a Launch Programs Requirement for details).

Code or program signing is the process of attaching a digital signature to the program so that it can be considered "trustworthy" of launching. When NAC Appliance launches a signed program, the "Launcher" confirms that the signature is from a trusted source (i.e. CA certificate is in trusted store) before executing it. Application signing is needed because launching unsigned applications is a security risk. Anyone can mask a trojan/worm as the program that you are trying to launch and cause harm.

Certificate Authorities (CA), such as Thawte and Verisign, offer signing services.

To sign programs yourself, you need:

CA Server (Public or Private)

Certificate Issued by CA server

Private Key, CA server public key, for above cert

The .exe, .dll, .scr, .wsh that needs be signed

A signing tool (such as signcode.exe/signtool.exe)


Note Example references/tools:

http://www.pantaray.com/signcode.html

http://www.cryptguard.com/documentation_resources_tools.shtml


Add a Requirement


Step 1 Create a New Requirement of type Launch Programs.

Step 2 Indicate whether the Requirement is Optional, Mandatory, or Audit.

Step 3 Indicate the root location from which to launch the qualified Program:

System_Root = C:\Windows

System_32 = C:\Windows\System32

System_Programs = C:\Program Files

Figure 11-24 Choose Root Location

Step 4 A more specific path and program parameters can be added:

Figure 11-25 Specify Program Parameters

Step 5 Click Add Program to add the program to the Program Name list.

Figure 11-26 Add Program

Step 6 Click Save Requirement.

Configure Application Signing


Step 1 Obtain a certificate and Private Key that will be used to sign your .exe file. You can obtain this from a Private CA (e.g. MS CA server) or Public CA (Verisign/Thawte, etc.).The rest of the files are tools you will need.

Figure 11-27 Obtaining Certificate

Step 2 Use the cert2spc.exe tool to create a SPC file also known as Software Publishing Certificate.

C:\inetsdk\test>cert2spc prem1.cer prem1.spc
Succeeded

Step 3 This creates a prem1.spc file as shown

Figure 11-28 Create Software Publishing Certificate (SPC)

Step 4 Run signcode.exe

C:\inetsdk\test>signcode

Figure 11-29 Run signcode. exe

Step 5 Browse and pick the .EXE that needs to be signed (tftpd.exe, in this example).

Figure 11-30 Choose Executable to Sign

Step 6 Pick the "Custom" option

Figure 11-31 Choose Custom Option

Step 7 Click "Select from File" and select the prem1.spc file created earlier.

Figure 11-32 Select SPC File

Step 8 Click "Browse" to select the private key prem1.pvk file.

Figure 11-33 Browse to Private Key

Step 9 Enter the password needed to use your private key (if any).

Figure 11-34 Enter Password to Private Key

Step 10 Select the hash algorithm you want to use for the signature.

Figure 11-35 Select Hash Algorithm

Step 11 Leave default values for the screens shown.

Figure 11-36 Leave Defaults

Step 12 Click Finish.

Figure 11-37 Click Finish

Step 13 If prompted again for Private Key, re-enter it. You will see the message:

Figure 11-38 Re-Enter Private Key if Necessary

Step 14 Confirm that your EXE is signed by right- clicking the file and selecting "Properties." The digital signatures tab and the Certificate CN name will confirm it.

Figure 11-39 Confirm Signed Executable

Step 15 Next, create a custom check/rule on NAC Appliance to check if the application called TFTPD32.exe is running or not.

Figure 11-40 Create Check

Step 16 Finally, create a requirement that uses this rule as follows:

Figure 11-41 Create Requirement


Launch Signed Program: User View


Step 1 User logs in with Clean Access Agent. Cisco NAC Appliance detects that TFTPD32.exe is not running. User is quarantined and asked to remediate.

Step 2 User clicks on Launch and TFTPD32.exe is launched.

Step 3 User clicks Next and logs onto network.

Figure 11-42 Launch Signed Program: User View


Map Requirements to Rules

Once the requirement is created and the remediation links and instructions are specified, map the requirement to a rule or set of rules. A requirement-to-rule mapping associates the ruleset that checks whether the client system meets the requirement to the user requirement action (Agent button, instructions, links) needed for the client system to comply.

Use the following steps to map a requirement to rules.


Step 1 In the Clean Access Agent tab, click the Requirements submenu and then open the Requirement-Rules form.

Figure 11-43 Requirement-Rules Mapping

Step 2 From the Requirement Name menu, select the requirement to map.

Step 3 Verify the operating system for the requirement in the Operating System menu. The Rules for Selected Operating System list will be populated with all rules available for the chosen OS.

Step 4 For AV Virus Definition Rules (yellow background) and AS Spyware Definition rules (blue background), you can optionally configure the CAM to allow definition files on the client to be a number of days older than what the CAM has available from Updates (see Rules > AV-AS Support Info for the latest product file dates). This allows you to configure leeway into a requirement so that if no new virus/spyware definition files are released from a product vendor, your clients can still pass the requirement.

Click the checkbox for either:

For AV Virus Definition rules, allow definition file to be x days older than:

For AS Spyware Definition rules, allow definition file to be x days older than:

Type a number in the text box. The default is "0" indicating the definition date cannot be older than the file/system date.

Choose either:

Latest file date—This allows the client definition file to be older than the latest virus/spyware definition date on the CAM by the number of days you specify.

Current system date—This allows the client definition file to be older than the CAM's system date when the last Update was performed by the number of days you specify.


Note For AS Spyware Definition rules, the system will enforce this feature (allowing the definition files to be X days older then the current system date) until Cisco Update service is available to regularly update the date/version for Spyware definition files.

When this feature is configured for a requirement, the Agent checks for the definition date of the AV/AS product then verifies whether the date meets the requirement. If the Agent cannot detect the definition date (i.e., def date detection is not supported for that product), the system ignores this feature and the Agent checks whether the client has the latest definition version.


Step 5 Scroll down the page and click the Select checkbox next to each rule you want to associate with the requirement. The rules will be applied in their order of priority, as described in Table 11-2.

Figure 11-44 Select Rules to Map to Requirement

Step 6 For the Requirements met if option, choose one of the following options:

All selected rules succeed—if all the rules must be satisfied for the client to be considered in compliance with the requirement.

Any selected rule succeeds—if at least one selected rule must be satisfied for the client to be considered in compliance with the requirement.

No selected rule succeeds—if the selected rules must all fail for the client to be considered in compliance with the requirement.

If clients are not in compliance with the requirement, they will need to install the software associated with the requirement or take the steps instructed.

Step 7 Click Update.


Apply Requirements to User Roles

Once requirements are created, configured with remediation steps, and associated with rules, they need to be mapped to user roles. This last step applies your requirements to the user groups in the system.


Note Make sure you already have normal login user roles created as described in Create User Roles, page 6-1.


Use the following steps to map requirements to a user role.


Step 1 In the Clean Access Agent tab, click the Role-Requirements submenu link.

Figure 11-45 Role- Requirements Mapping

Step 2 From the Role Type menu, select the type of the role you are configuring. In most cases, this will be Normal Login Role.

Step 3 Select the name of the role from the User Role menu.

Step 4 Click the Select checkbox for each requirement you want to apply to users in the role.

Step 5 Click Update.

Step 6 Before finishing, make sure users in the role are required to use the Clean Access Agent or Cisco NAC Web Agent. See Require Use of the Agent, page 10-3.


Validate Requirements

The Clean Access Manager automatically validates requirements and rules as they are created. The Validity column under Device Management > Clean Access > Clean Access Agent > Requirements > Requirement List displays a blue checkmark if the requirement is valid and a red "X" if the requirement is invalid. Highlighting this icon with your mouse reveals which rule and which check is causing the requirement to be invalid, in the form:

Invalid rule [rulename] in package [requirementname] (Rule verification error: Invalid 
check [checkname] in rule expression)

The requirement must be corrected and made valid before it can be used. Typically requirements/rules become invalid when there is an operating system mismatch.

Use the following steps to correct an invalid requirement.


Step 1 Go to Device Management > Clean Access > Clean Access Agent > Requirements > Requirement-Rules.

Step 2 Correct any invalid rules or checks as described in Validate Rules.

Step 3 Select the invalid Requirement Name from the dropdown menu.

Step 4 Select the Operating System.

Step 5 Make sure the Requirement met if: expression is correctly configured.

Step 6 Make sure the rules selected for the requirement are valid (blue checkmark in Validity column).

Figure 11-46 Requirement List


Configuring an Optional/Audit Requirement

You can make any requirement Mandatory, Optional, or Audit-only using the Enforce Type dropdown menu in the New Requirement or Edit Requirement form. Optional requirements allow you to view administrative reports for an Agent user without blocking the client from the network if the optional requirement fails. If an optional requirement fails, the user is put in the Temporary role and will see "Optional" preceding the name of the requirement in the Agent dialog; however the user can click Next and either proceed to the next requirement or to the network if no other requirements are configured.

If you want to provide an extended period of time for users to meet requirements without blocking them from the network, you can configure an optional requirement with instructions to comply by a certain date. You can later enforce the requirement at the specified date to make the requirement mandatory.

If you want to ensure the client system is checked "silently" for the requirement without notifying the user, and a report is generated, you can configure an audit-only requirement that only reports results (pass or fail) does not affect user network access.

Use the following steps to create an Optional/Audit requirement.


Step 1 Go to Device Management > Clean Access > Clean Access Agent > Requirements > New Requirement.

Figure 11-47 Optional/Audit Requirement

Step 2 Choose a Requirement Type from the dropdown.

Step 3 Choose Optional (do not enforce) or Audit (silent assessment) as the Enforce Type from the dropdown menu.

For an Optional requirement, the user is informed of the requirement but can bypass it if desired (by clicking Next in the Agent dialog). The client system does not have to meet the requirement for the user to proceed or have network access. For an Audit requirement, the system generates audit reports, but no user dialogs appear on the client machine and the user's network access is unaffected.

Step 4 Choose the Priority of execution for this requirement on the client. A high priority (e.g. 1) means this requirement is checked on the system ahead of all other requirements (and appears in the Clean Access Agent and Cisco NAC Web Agent dialogs in that order). Note that if a Mandatory requirement fails, the Agent does not continue past that point until that requirement succeeds.

Step 5 If you want to enable and configure Auto Remediation for the Clean Access Agent:

a. Choose the Remediation Type [Manual | Automatic] from the dropdown menu. Choosing Manual preserves previous Agent behavior. The user has to click through each of the requirements using the Next button in the Clean Access Agent. Choosing Automatic sets the Agent to perform Auto Remediation, where the Agent automatically performs updates or launches required programs on the client after the user logs in.

b. If you configure the requirement to use automatic remediation, specify the Interval in seconds (the default interval is 0). Depending on the requirement type, this interval either sets the delay before the Agent re-attempts remediation or sets the total time allowed for a particular remediation process.

c. Enter the Retry Count []. Specifying a retry count sets a limit on the number of times the Agent automatically retries the requirement if it initially fails. (The default retry count setting is 0.)

For details on configuring Auto Remediation, see Configuring Auto Remediation for Requirements.


Note The Cisco NAC Web Agent does not support Auto Remediation.


Step 6 Configure specific fields for the requirement type.

Step 7 Type the Requirement Name for the optional requirement.

Step 8 Type instructions in the Description field to inform users that this is an optional requirement and that they can still proceed to the network by clicking the Next button on the Agent dialog. Note the following:

File Distribution displays a Download button on the Clean Access Agent.

Link Distribution displays a Go To Link button on the Clean Access Agent/Cisco NAC web Agent.

Local Check displays a Download button (disabled) on the Clean Access Agent.

AV Definition Update displays an Update button on the Clean Access Agent.

AS Definition Update displays an Update button on the Clean Access Agent.

Windows Update displays an Update button on the Clean Access Agent.

Launch Programs displays a Launch button on the Clean Access Agent.

Windows Server Update Service displays an Update button on the Clean Access Agent.

Step 9 Click the checkbox(es) for the Operating System.

Step 10 Click Add Requirement.

Optional requirements must be mapped to rules and user roles in the same way as mandatory requirements. Refer to the following sections to complete configuration:

Map Requirements to Rules

Apply Requirements to User Roles

Figure 11-48 Clean Access Agent Dialog for Optional Requirement


Configuring Auto Remediation for Requirements

You can configure Auto Remediation for all requirement types except File Distribution and Local Check.


Note Cisco NAC Web Agent does not support Auto Remediation.


Use the following steps to configure Auto Remediation.


Step 1 Go to Device Management > Clean Access > Clean Access Agent > Requirements > New Requirement, and select the Requirement Type. You can configure Auto Remediation for:

Link Distribution

AV Definition Update

AS Definition Update

Windows Update

Launch Programs

Windows Server Update Services

Step 2 Choose the Enforce Type [Mandatory | Optional | Audit] from the dropdown.

Step 3 Choose the Remediation Type [Manual | Automatic] from the dropdown.

Choosing Manual preserves the previous Agent behavior. The user has to click through each of the requirements using the Next button.

Choosing Automatic sets the Agent to perform Auto Remediation, where the Clean Access Agent automatically performs updates or launches required programs on the client after the user logs in. The Agent automatically performs different actions depending on the requirement type, for example:

Auto launches URL in the default browser for Link Distribution

Auto updates AV/AS definition files on the client for AV/AS Definition Update

Auto launches Windows Auto Update(s) (in background) for Windows Update

Auto launches programs for Launch Programs

Auto installs WSUS client updates for Windows Server Update Services

When you check the Automatic option, you can optionally configure how long the Agent waits before it retries the same requirement (Interval), and how many times the Agent retries the requirement if it initially fails on the client (Retry Count). The effect of these options is slightly different depending on the requirement type.

During Auto Remediation, the Agent dialog displays only two buttons: Details and Manual. Clicking Details shows additional progress messages for the Auto Remediation. If Auto Remediation fails, the user can click the Manual button to change the Agent back to Manual mode, where the user has to click through each requirement.

Step 4 Type the Interval[] Secs

Interval []secs - Default is 0. Depending on the requirement type, this interval either sets the delay before the Agent re-attempts remediation or sets the total time allowed for a particular remediation process. When the interval is set to 0, the Agent continues to attempt Auto Remediation until the temporary role times out.

AV Definition Update/AS Definition Update/Windows Server Update Services—when the initial remediation attempt fails, this interval defines how long the Agent waits before it restarts the next update attempt. For example, if setting this interval to 30 seconds for an AV Definition Update, at the end of the initial attempt to update the client's AV definition file, the Agent waits 30 seconds then starts the next update attempt if the requirement failed.

Link Distribution/Windows Update/Launch Programs—for these requirement types, the interval defines the total number of seconds the Agent allows for the remediation attempt to complete. For example, if setting this interval to 60 seconds for a Launch Programs requirement, the Agent launches the program(s) and allows 60 seconds for the programs to execute. If the client has not met the requirement at the end of 60 seconds, the Agent launches the programs again immediately.

Step 5 Type the Retry Count []

Retry Count [] - Default is 0. When the interval is 0, the Agent continues to attempt Auto Remediation until the temporary role times out. Otherwise, specifying a retry count sets a limit on the number of times the Agent automatically retries the requirement if it initially fails. If the Retry Count is reached before the Temporary role timeout, the Auto Remediation dialog displays red status text telling the user to click the Manual button.

AV Definition Update / AS Definition Update / Windows Server Update Services

Link Distribution / Windows Update / Launch Programs

If a Mandatory requirement still fails after the Retry Count, the Agent stops and does not perform the next priority requirement for the user role. Users will not have network access.

For an Optional requirement, the Agent always continues to the next requirement after the initial attempt finishes, regardless of the Retry Count specified and whether the initial attempt succeeded or failed. However, if an Interval is specified, the Agent waits that amount of time before continuing to the next requirement.

Figure 11-49 Auto Remediation Example—Windows Update In Process

If Auto Remediation fails, the user sees a failure message similar to the one in Figure 11-50 and can click the Details button to view the remediation results (Figure 11-51) or click Continue to return to the Clean Access Agent authentication process. The user can then either cancel the login session or accept "restricted" network access (Figure 11-52).

Figure 11-50 Auto Remediation Example—Windows Update Failed

Figure 11-51 Auto Remediation Example—Auto Remediation Details

Figure 11-52 Auto Remediation Example—Return to WSUS Requirement Authentication Dialog


Viewing Agent Reports

The administrator Agent Reports page (under Device Management > Clean Access > Clean Access Agent > Reports > Report Viewer) gives you detailed information about user Clean Access Agent and Cisco NAC Web Agent sessions. The information includes user access attempts and system check results.

Using the Reports page, administrators can log and search Agent reports to facilitate information gathering and export compiled report data to aid statistical analysis and Agent connection issue troubleshooting. The Reports page presents Agent report entry information using the following column headings:

Status—Green or red flag indicates successful or unsuccessful Agent connection

User—The user ID used to establish the session from the client machine

Agent—Specifies the type of Agent used to initiate the client session (Windows Clean Access Agent, Mac OS X Clean Access Agent, or Cisco NAC Web Agent)

IP—The client machine IP address

MAC—The client machine interface MAC address

OS—The operating system detected on the client machine

Time—The date and time the user attempted to initiate the Agent session


Note Report List entries with an orange background indicate clients who failed system checking.


Figure 11-53 Agent Administrator Report

The Reports page also enables you to filter the list of user session reports by activating and defining additional client report display criteria. For example, if you have a very large user access base where users log in every day (even multiple times per day) and you want to limit the number of reports to a more manageable total, you can choose to display user session information for a single user ID or all user sessions from a specific device. The filter parameters available in the dropdown menu are:

Status—Allows you to list either successful or unsuccessful, or both types of user sessions

Username—Allows you to specify all or part of a specific user ID to display in the client report list

IP—Allows you to limit the list of client reports to match all or part of a specified IP address (you could use this parameter to limit the user list to only IP addresses in the 10.12.4.<x> range by specifying "starts with" "10.12.4.", for example)

MAC—Allows you to limit the list of client reports to match all or part of a specified source MAC address

OS—Allows you to display client reports based on the operating system detected on the client machine

Time—Allows you to display client report entries either since or before a point in time (like within the last hour or before the last day, for example)

Software—Allows you to display client reports for specific installed AntiVirus, Antispyware, and/or any Unsupported AV/AS software

Requirement—Allows you to display only client reports associated with a specific Agent requirement

Requirement Status—Allows you to display client reports for successful or unsuccessful Agent requirements for the specified Requirement (above)

System Name—Allows you to display client reports associated with all or part of a specific client system name

System User—Allows you to display client reports associated with a specific system user (that is, the user logged in to the client machine at the time the actual user session was initiated, which is not necessarily the same ID as the Username, above)

System Domain—Allows you to display only client reports based on the system domain into which the client machine has been logged in

User Domain—Allows you to display only client reports based on the user domain with which client System User ID is associated

Click the Filter button after selecting and defining parameters for any of the search options to display a summary of all client report entries that match the criteria as well the detailed administrator report for each client.

You can click Reset to negate any of the optional search criteria from the filter dropdown menu and return the client report display list to default settings.

Click the View button (far-right magnifying glass icon) to see an individual user report, as shown in Figure 11-54.

Figure 11-54 Example Agent Report

In addition to user, operating system, Agent version, and domain information, the Agent report lists the requirements applicable for the user role (both mandatory and optional). Requirements that the user met are listed in green, and failed requirements are listed in red. The individual checks making up the requirement are listed by status of Passed, Failed, or Not executed. This allows you to view exactly which check a user failed when a requirement was not met.

Not Executed checks are checks that were not applied, for example because they apply to a different operating system. Failed checks may be the result of an "OR" operation. To clear the reports, click the Delete button. The button clears all the report entries that are currently selected by the filtering criteria.

Exporting Agent Reports

You can use the Export and Export (with text) buttons to save CSV files containing Agent report data to your local hard drive to search, view, and manipulate whenever needed for troubleshooting or statistical analysis purposes.


Step 1 Go to under Device Management > Clean Access > Clean Access Agent > Reports > Report Viewer (see Figure 11-55).

Step 2 Click Export or Export (with text).

Figure 11-55 Exporting Agent Reports

Step 3 Do one of the following:

Click Open to view the resulting Agent report file.

Click Save, navigate to a directory on your local machine where you want to save the Agent report file, enter a name for the file, and click Save in the navigation dialog so you can view the report at a later date.


Limiting the Number of Reports

You can limit the number of reports in the log under Device Management > Clean Access > Clean Access Agent > Reports > Report Setting. Specify the maximum number of reports as a value between 100 and 200000 (default is 30000).

Clean Access Agent/Cisco NAC Web Agent reports are stored in their own table and are separate from the general Event Logs.