Chapter 6. Building a Cisco NAC Appliance Host Security Policy

This chapter covers the following topics:

• What Makes Up a Cisco NAC Appliance Host Security Policy?
• Determining the High-Level Goals for Host Security
• Defining the Security Domains
• Understanding and Defining NAC Appliance User Roles
• Establishing Acceptable Use Policies
• Checks, Rules, and Requirements to Consider
• Defining Network Access Privileges

For any host-centric security solution to be successful, a solid host security policy (HSP) must first be in place. After a policy is in place, NAC Appliance enforces that policy networkwide. A host security policy defines, in as much detail as is practical, the protection strategy for the different clients within an organization. Given that host security threats are constantly changing, a host security policy must also be a living, changeable document. This book does not attempt to assemble an all-encompassing host security policy but instead focuses on the building of policies that are relevant to a NAC Appliance solution. This chapter will guide you through the process of creating a comprehensive host security policy that can be used in a NAC Appliance environment. Building a host security policy is not always straightforward and can be frustrating at times, but stick with it; your hard work will be rewarded in the end.

What Makes Up a Cisco NAC Appliance Host Security Policy?

One of the hardest things about writing a comprehensive host security policy is figuring out what should be included in the policy. This chapter will guide you through the parts and pieces that, at a minimum, should be included in any host security policy written for a NAC Appliance solution. For your NAC Appliance solution to be most effective, it is necessary to first determine exactly what an acceptable host security posture is under different circumstances. After this is done, you can then easily translate your host security policy into the proper checks and security requirements that NAC Appliance will use to posture assess hosts. For example, if the host is a corporate asset and connected to the wireless network, a strict host security policy should be enforced. However, if the same host moves to the wired network, a less strict security policy should be in place. It is also necessary to determine what the host security policy should be for different types of hosts, either based on their operating system or based on who the end user is. For example, if a contractor logs on to your network using a Windows XP laptop, the security policy would differ from the same user logging in with a Mac OS X system.

Host Security Policy Checklist

Here is a checklist of the most common steps considered necessary to create a NAC Appliance host security policy. Each checklist item will be explained in detail in the subsequent sections of this chapter. Use this checklist, along with the detailed explanations, to give you a head start in the creation of your own unique host security policy.

Obtain senior management sponsors who will support you through the creation of the host security policy and the deployment of the NAC Appliance solution.

Determine what people and departments need to be involved in the creation of the host security policy. Make sure that they are included up front, right from the start of the project.

Determine what your high-level goals for host security are.

Break up your organization into security domains. The requirements of the host security policy can then be customized for each security domain as necessary.

Define user roles that are relevant for your organization.

Establish an acceptable use policy (AUP) for your network.

Define NAC Appliance's host security checks, rules, and requirements for each user role.

Define the network access privileges that should be granted to each user role.

Establish an HSP lifecycle process that allows for the regular updating and changing of the host security policy's checks, rules, and requirements.

Involving the Right People in the Creation of the Host Security Policy

At the very beginning of the planning for a NAC Appliance deployment or purchase, it is extremely important to obtain project sponsorship from senior-level management. Given that NAC Appliance will force a change on the user community's behavior and network access, this is a mandatory step. Without senior-level sponsorship, your NAC Appliance deployment could be derailed by a few users who are not happy with or willing to accept the new policy changes.

Having the endorsement of senior management grants you the power to push back on those users in a constructive way. Too often the security group spends the time to develop sound security policies and practices only to be told that they are too restrictive and need to be changed. This can be avoided by making sure that you keep your sponsors involved and up to date on the progress and content of your host security policy. It is also critical that you have your final version approved by your sponsorship committee prior to releasing it to the public. Try to anticipate the type of reaction, resistance, and questions the user community will have. Be ready with solid rebuttals, facts, and collateral to combat their arguments, answer their questions, and make them feel more comfortable that the new host security policy is the correct one.

One of the first steps in the creation of any HSP is the creation of the host security policy committee. This committee should be made up of the principal persons whose group or users will be most affected by or have some ownership in the new policy. It is a best practice to try and keep the committee small in the beginning phases of the policy creation. After this core team has an HSP with a clear direction, some substance, and some content, the HSP committee should be expanded to include more key persons. When the HSP reaches a completed draft format, the HSP committee should again be expanded. This time the expansion is to include those principal persons who do not have any direct ownership or responsibility for the creation of the HSP but do have a sizeable user community that will be directly affected by the policies' proposed changes.

This last group will serve to scrutinize the policies in your HSP draft to make sure that the policies do not inhibit business practices or workflow, are practical, and have achieved the proper balance of security risk versus network access for the organization. After a final HSP version has been created, the entire committee must agree to present a united front once the new policy begins to be enforced inside the organization. A nonunited, or splintered, HSP committee almost always results in the splintering or haphazard adoption of the host security policy within the organization.

Here is a list of the most common principal persons that should be a part of the creation of a host security policy. You should adapt this list for your environment.

• Sponsorship
  

  — CSO/CIO must be a sponsor or core committee member

  — At least one CxO level sponsor other than the CSO/CIO

  — At least one company board member sponsor

  — One sponsor or core committee member from the legal department

• Core HSP committee members should be made up of key persons from the following groups:
  

  — Ideally the CSO/CIO would be a core member

  — Security group

  — Networking group

  — Server group

  — Desktop support group

  — Operations group

  — Security incident response team

• Extended HSP committee members should be made up of key persons from the following groups:
  

  — Human Resources group

  — Legal group

  — Audit group

• Final HSP committee members should be made up of key persons from the following groups:
  

  — Managers of large end-user groups within the organization (such as division heads, department heads, and so on)

  — Key individuals from the end-user community for feedback

This list should be used as a guideline and is not meant to be all-inclusive. The goal of HSP committee member selection is to ensure that the committee has adequate representation from all key stakeholders, budget holders, management, legal council, and technical staff. Each group will have a slightly different role to fulfill on the committee.

Determining the High-Level Goals for Host Security

Determining what your high-level goals are for host security is a critical step toward the completion of a comprehensive host security policy. These high-level goals will serve as your benchmarks and guides throughout the HSP creation process. The final HSP document should represent a detailed plan that achieves these high-level goals. It is important to periodically refer to these high-level goals to ensure that your HSP remains focused and on target to meet your stated security goals.

The following comes from RFC 2196, "Site Security Handbook" (http://www.ietf.org/rfc/rfc2196.txt):

Your goals will be largely determined by the following key tradeoffs:
(1) services offered versus security provided -
Each service offered to users carries its own security risks. For some services the risk outweighs the benefit of the service and the administrator may choose to eliminate the service rather than try to secure it.
(2) ease of use versus security -
The easiest system to use would allow access to any user and require no passwords; that is, there would be no security. Requiring passwords makes the system a little less convenient, but more secure. Requiring device-generated one-time passwords makes the system even more difficult to use, but much more secure.
(3) cost of security versus risk of loss -
There are many different costs to security: monetary (i.e., the cost of purchasing security hardware and software like firewalls and one-time password generators), performance (i.e., encryption and decryption take time), and ease of use (as mentioned above). There are also many levels of risk: loss of privacy (i.e., the reading of information by unauthorized individuals), loss of data (i.e., the corruption or erasure of information), and the loss of service (e.g., the filling of data storage space, usage of computational resources, and denial of network access). Each type of cost must be weighed against each type of loss.

Note

For more detailed information about the creation of host security goals and security policies in general, see the IETF's RFC 2196 at http://www.ietf.org/rfc/rfc2196.txt.

Your final high-level host security goals will be the result of the fine balancing act of the above trade-offs. The result of each trade-off will be different for each organization or possibly division within an organization.

Common High-Level Host Security Goals

Here are some examples of host security goals that are frequently instituted in organizations that deploy a NAC Appliance solution. These examples are meant to be a sampling and not a comprehensive list.

• Protect the network from unauthorized access, both internally and externally originated.
• Authenticate all users attempting access to the network.
• Authorize all users attempting access to the network. Restrict access for nonemployees and guests.
• All users must acknowledge an acceptable use policy before being granted network access.
• All hosts must be running an approved antivirus program that is up to date.
• All hosts must be running an approved antispyware program that is up to date.
• All hosts must be running an approved operating system that is up to date.
• All hosts must pass a network scan for virus and worm activity before being granted network access.
• Any host found running banned software applications will be denied network access.
• All hosts must be running an approved personal firewall or Host Intrusion Prevention System before being granted network access.
• All guest hosts will be granted access only to the Internet and not internal resources.
• All guest hosts will be bandwidth limited to 256 kbps.

It is common for an organization to modify its host security goals based on a specific network location or access type. For example, an organization might have a policy that states all hosts connecting through wireless in the Denver data center must be running an approved antivirus program that is up to date in order to gain network access.

Many organizations choose to gradually enforce their host security policies and the deployment of a NAC Appliance solution. Initially, host security policy enforcement is instituted at the highest risk areas of the network. This would include virtual private network (VPN) or remote access, wireless, conference rooms, guest access, and common areas. Then, as the adoption of the NAC Appliance solution grows, the host security policy enforcement is spread ubiquitously throughout the organization.

Figure 6-1 summarizes the process for determining the exact host security policy that will be enforced for a given host or in a given network location.

Figure 6-1. Host Security Policy Decision Matrix

Here is the explanation of the host policy decision steps shown in Figure 6-1. Following this list are several sections that will describe these decision steps in greater detail.

1. The host connects to a location of the network.

2. The host is determined to be a member of a certain security domain. The HSP must define what the security domains are for the organization.

3. The HSP must define one of three choices for each unique security domain.

a. Which security domains will not have NAC Appliance deployed, thus allowing unrestricted network access. The host security policy for this security domain states that no host security policies are to be enforced in this domain.

b. Which hosts or devices will be a member of the exemption list and thus will be able to bypass the NAC Appliance authentication and posture assessment phases.

c. Which security domains will force hosts to comply fully with the NAC Appliance solution.

4. If the host is a member of the exemption list, it will flow directly to the network access privileges. The remaining steps in this list are bypassed. The HSP must define exactly what the network access privileges will be for each type of exempt host. It is possible to have different network access policies for different types of exempt devices. For example, you can have an exempt host security policy that allows IP phones to access the network unrestricted, but exempt printers are restricted to communicating using TCP port 9100 only.

5. If the host is part of a security domain that requires full compliance with the NAC Appliance solution, the client is forced to authenticate. The HSP should determine exactly how the user's credentials are authenticated and verified.

6. After successfully authenticating, the client is then moved to the user role it is a member of. The HSP should identify how user roles are defined and which users are members of which user roles.

7. The host is checked to make sure that it meets all the host security requirements defined for that user role. The HSP should define what the security requirements are for each user role.

8. If the host complies with all of its security requirements, it is moved to the network access privileges. The HSP should define the type of network access that should be granted to clients. This is typically defined per user role.

9. If the host fails to meet its security requirements, it is moved into network quarantine. Typically, self-remediation functions are also provided here. The HSP should clearly specify what network access privileges, remediation functions, and time limits should be imposed on quarantined hosts.

Defining the Security Domains

A security domain is used to group network areas, host types, and locations under a common host security policy. The goal of creating security domains for a NAC Appliance solution is to define which networks and locations will require hosts to use the NAC Appliance solution and which locations will not. It is also necessary to define the devices that will require exemption from the NAC Appliance solution within a given security domain. Figure 6-2 shows an example of security domains.

Figure 6-2. Sample Security Domains

Most organizations will need to define the security domains that are depicted in Figure 6-2. Almost all organizations have an Internet connection, use VPN, have a WAN and campus LAN, and use wireless. Each one of these network access types or locations usually requires its own unique host security policy and thus should be its own security domain. The separating of these areas into unique security domains allows you to create unique host security polices for each. The more compartmentalized your HSP is, the more granular and targeted it can be. This results in a more locked-down host security policy for your organization. To make the point, if you had an HSP that did not use security domains and treated all hosts the same no matter what, you would be forced into using a global policy based on those hosts that required the weakest security policies. That said, however, sometimes it makes more sense to keep your security policy as simple and global as possible. This could be for political reasons or business reasons. As long as it meets your security objectives and is effective, go with it. Again, there is a trade-off: a comprehensive multidomain policy versus a simple global policy. A multidomain policy should be inherently more secure, but a simple global policy could be easier to manage and maintain.

Here are some commonly used security domains:

• Remote Access This domain includes any host that is accessing the network remotely via VPN or dial-up modems.
• OOB Management This domain includes any host that resides on the out-of-band network management network. This is typically a highly secured domain.
• Internet This domain includes any host that accesses the Internet. A sample policy here could be the following: Before a host is allowed to access the Internet, its operating system and antivirus software must be up to date.
• Guest This domain includes any host that is a guest on the network. Many times this domain is segmented into access types as well, such as guest wireless, guest VPN, and guest LAN domains. This allows for the creation of granular host security policies for guests.
• Campus LAN This domain includes any host that connects to the network via a wired switch port. It is common to separate security domains by virtual LAN (VLAN) or location at the LAN level. This allows the HSP to have policies for specific VLAN and locations instead of one generic policy for all wired hosts.
• Wireless This domain includes any host that uses wireless to access the network. It is common for the wireless domain to be separated by VLAN or location, such as a guest wireless security domain or a Denver campus wireless security domain.

This is by no means a comprehensive list, but it should serve to give you a good start in the creation of your own security domains.

Here is a list of devices that are commonly exempted from the NAC Appliance solution in all security domains. If a device resides on an untrusted domain and is not capable of authenticating itself and running through the remediation process, it must be exempted. A device exemption is made up of either a device's MAC address or its MAC and IP address pair. It is possible to use wildcards and ranges for MAC addresses. An exemption can also be defined using IP subnet and mask values.

• IP phones Phones do not have the capability to participate in the NAC process today. A best practice is to segment voice onto its own VLAN and make sure that VLAN never passes through NAC Appliance. With Out-of-Band mode, make sure that the MAC addresses of all phones are put into the exemption list.
• Printers Printers do not have the capability to participate in the NAC process today. However, they can still be subjected to the network access controls. This can be effective in limiting the ports and protocols that can reach your printers.
• Network-attached fax machines Same as printers.
• Servers Given that nobody sits at the console of servers, and servers are usually in a secure area, NAC Appliance should be bypassed for servers. However, network access controls can be used if necessary to control what traffic can flow to and from servers. Bandwidth rate-limiting can also be used if applicable.
• Wireless access points If wireless access points are permitted, they should bypass NAC Appliance. The clients that connect to them, however, will not be exempt.
• Routers and routing protocols When deploying NAC Appliance in Virtual Gateway L3 In-Band mode, it is possible to have routers present on the untrusted side. In this case, they should be exempt and their routing protocols should be allowed to pass.
• Switches Same as for routers.
• Game consoles Given that game consoles do not have the capability to participate in the NAC process today, they should be exempt. However, it is a best practice to deploy bandwidth rate-limiting and tight network access control rules on this device type.

This is by no means a comprehensive list, but it should serve to give you a good start in the creation of your own exempt device list. It should be noted that several non-Cisco products are available that can auto-discover exempt devices for NAC Appliance; Great Bay Software has such a product.

Understanding and Defining NAC Appliance User Roles

The effective use of user roles is a key component to any successful NAC Appliance deployment. NAC Appliance is role based; a user role defines the host security policies that will be required for its members. The concept of user roles is the backbone of NAC Appliance. User roles are analogous to groups in Active Directory (AD). Like groups, users are assigned membership to a specific user role. Unlike groups, however, users can be a member of only one user role at a time. NAC Appliance moves clients into a user role as soon as the client system is detected on the network. The moment an Ethernet frame is seen from a new client, it is moved into the Unauthenticated role by NAC Appliance. Given that a client or user can be a member of only one user role at a time, it is important to understand the role assignment priority. The order for role assignment is as follows:

1. MAC address The physical MAC address of the client is matched to assign it to a user role.
2. Subnet/IP address The IP address or IP subnet of the client is matched to assign it to a user role.
3. Login information The login credentials of the client are matched to assign it to a user role.

The login information could consist of the user's login credentials, the VLAN ID of the host, or attributes obtained from an external authentication server such as the Lightweight Directory Access Protocol (LDAP) or RADIUS.

Tip

It is a best practice to map attributes from an external authentication server (such as LDAP or RADIUS) to a user role in NAC Appliance. A common attribute matched on is MemberOf in Windows AD. This allows user roles to be based on existing AD groups within your organization. For example, an LDAP user Conor is a MemberOf AD group employee. A mapping can then be configured in NAC Appliance that reads if MemberOf=employees then map the client to user role employee.

The user role has policies that determine which NAC Appliance functions will be performed on client members. All clients that are members of the user role will be subjected to its security requirements. Some of the functions that can be controlled by user roles are as follows:

• Dynamic VLAN assignment
• Authentication method
• Bandwidth restrictions
• Traffic policies
• Session duration
• Clean Access Agent posture assessment
• Network Scanner
• Acceptable use policy
• Quarantine policy
• Clean Access Agent use
• Web login features
• External authentication server features

As you can see, user roles are integral to the functioning of NAC Appliance.

Built-In User Roles

NAC Appliance comes with three built-in, or default, user roles and one user role type. These roles are used for the basic policy functions of NAC Appliance. The traffic control and bandwidth control policies can and should be modified on all the built-in user roles. Let's examine each role in detail.

Unauthenticated Role

Clients are members of this role until they are successfully authenticated, scanned, and posture assessed. The one built-in role that must be used and cannot be deleted is the Unauthenticated role. The reason for this is NAC Appliance moves users into the Unauthenticated user role as soon as the client system is detected on the network. Specifically, the moment an Ethernet frame is seen from a new client, NAC Appliance implicitly moves that client into the Unauthenticated role.

Normal Login Role

The normal login role is not a role in and of itself but rather it represents a type of user role. The user role that a client is moved to when it has passed authentication, scanning, and posture assessment is always of type normal login role. The final or desired user role that a client will be in if it successfully authenticates and is found to be clean is always of type normal login role. Another way to define it is that any role that is not a Temporary, Quarantine, or Unauthenticated role will be of type normal login role. User roles of this type will make up the bulk of the roles you will define in your NAC Appliance solution.

Here is a sample scenario: User Liam passes authentication, scanning, and posture assessment. NAC Appliance then does an LDAP lookup to find the normal login role that Liam should be a member of. The LDAP server responds that Liam is a member of group student. Group student has been mapped to user role student. Liam is now moved to user role student, which is of type normal login role.

Clients can be assigned to a normal login role in the following ways:

• By MAC address, MAC/IP address pair, or IP subnet of the client.
• By mapping attributes from an external authentication server to a NAC Appliance user role. This is the most common method.
• By creating users in the local user database in NAC Appliance and assigning the users to a role. This is not common for production environments and should typically be used only for testing purposes.

Temporary Role

The Temporary role is reserved for only those clients that use the Clean Access Agent software to log in to NAC Appliance. If web login is used, the Temporary role does not apply. Clients must have passed authentication to be eligible for membership in the Temporary role. After successful authentication, clients are moved to the Temporary role only if they fail any of the Clean Access Agent security requirements or checks. The Temporary role has a session timer setting. When the timer reaches zero, the client is kicked out of the Temporary role and moved back to the Unauthenticated role. The user must then reauthenticate.

The purpose of the Temporary role is to quarantine the host on the network and provide access to remediation resources. For that reason, hosts in this role should be granted network access to the resources necessary for them to remediate and nothing more. In fact, while the user is clicking through the remediation screens shown by Clean Access Agent, the client is in the Temporary role. Therefore, it is critical that the proper network access be granted to clients in the Temporary role in order for the remediation methods to work. It is equally important that clients in the Temporary role be restricted from accessing network resources they do not absolutely require. This will serve to keep those noncompliant hosts from potentially doing harm to the rest of the network. For noncompliant hosts, the Temporary role serves as a policy stopgap between the Unauthenticated role and the normal login role.

If you enable Network Scanner for Clean Access Agent clients, it is important to note that a failed scan will result in the host being moved into the Quarantine role, not the Temporary role. Note that performing network scanning when using Clean Access Agent is possible, but it is not commonly done. The scan of the host happens after the Clean Access Agent security requirements and checks are performed. The following is a possible scenario:

1. The client connects to the network. NAC Appliance detects the new client and moves it into the Unauthenticated role.
2. The user successfully authenticates using the Clean Access Agent software. The client moves into the Temporary user role.
3. Clean Access Agent checks the host to see whether it meets the security requirements defined in the client's desired final normal login role.
4. The client fails a check and is presented with a remediation option to download a file. The client downloads and installs the file.
5. The client now passes the security checks. Network Scanner kicks off and scans the host for viruses and worms.
6. Network Scanner finds a worm on the host. NAC Appliance moves the host to the Quarantine user role. The user is presented with a web link to a tool to clean the worm.
7. The user uses the tool to clean the worm. The user is rescanned, and the scan now passes.
8. The user is moved to the normal login role of student.

Quarantine Role

The purpose and function of the Quarantine role is identical to that of the Temporary role. The difference is that this role is used by hosts that use web login, or clientless mode, and Network Scanner. As mentioned previously, it is also used by Clean Access Agent hosts that are found to have a vulnerability during the network scan. The purpose of the Quarantine role is to restrict the client's network access to only those resources it requires to fix the vulnerabilities found during the network scan. This role also has a session timer that, if allowed to expire, will kick the user out of the Quarantine role and move it back into the Unauthenticated role. The user will then have to reauthenticate to NAC Appliance.

It is possible to have more than one Quarantine role in NAC Appliance. Each Quarantine role is assigned to a normal login role and, optionally, to an operating system type. For example, clients in the Employee user role that are using Windows XP will be quarantined using the employee_winxp_quar role. Clients in the Guest role that are using Mac OS will be quarantined using the guest_mac_quar role. Consequently, it is possible to have the quarantine security policies change to match the needs of different user groups or roles and different operating systems. This allows for the creation of much more granular host security policies. For instance, it would be possible to have a Windows Quarantine role and a Mac OS Quarantine role for a particular normal login role. The Windows policy would allow access to http://www.windowsupdate.com. The Mac OS policy would not have that access but would instead have access to http://www.apple.com.

Commonly Used Roles and Their Purpose

This section will focus on the normal login roles commonly found in the host security policies of organizations that use the NAC Appliance solution. The goal is to present you with a solid starting point on which to base the user role needs of your organization's host security policy.

Start with the built-in user roles. As discussed previously, it is mandatory that you use the Unauthenticated user role. Therefore, make certain that your HSP has a section that addresses the Unauthenticated role. If you use Clean Access Agent for posture assessment, it is also mandatory for you to use the Temporary user role. Again, make sure that your HSP has a section for this. If you must use the Network Scanner function, it is mandatory for you to use a Quarantine user role and have a supporting HSP section.

However, given that NAC Appliance Manager can accommodate more than one role of type Quarantine, you do not necessarily have to use the Quarantine role provided by default. It is typical for a larger organization to create separate Quarantine roles. The purpose is to allow for the creation of separate quarantine HSP sections. These quarantine HSP sections are then assigned to hosts in quarantine either based on their operating system, their normal login role membership, or both. The following are some sample HSP sections for using multiple Quarantine roles:

• Guest users Quarantine role While in quarantine, all guest users should have access to only Internet remediate resources and Domain Name System (DNS). No access to internal remediation servers or other network resources should be allowed. Commonly allowed Internet remediate resources could include, but are not limited to, http://update.microsoft.com, http://mcafee.com, http://nai.com, and http://trendmicro.com. It is recommended that the default remediation hosts listed under the Quarantine role in NAC Appliance be allowed.
• Employee Quarantine role While in quarantine, all members of the employee role should have access to only internal remediation resources and DNS. No access to external remediation servers, Internet, or internal resources should be allowed. Commonly allowed internal remediation resources could include, but are not limited to, corporate Windows Server Update Services servers, antivirus servers, and antispyware servers.

Next you will explore some of the most commonly used normal login roles. Remember, a normal login role defines the rights and privileges that a client will have after it passes authentication and posture assessment. All organizations must have their own customized normal login roles. The number and purpose of these roles will vary according to your environment. Each of the roles you choose should have a separate policy definition section in your host security policy document. The following are some of the most commonly configured roles; all are of type normal login role:

• Guest/visitor role
• Employee role
• Corporate user role
• Contractor/temp role
• Student role
• Faculty role
• Roles based on network location, such as Denver user role
• Job-based roles, such as sales, engineering, and so on
• Admin role
• Staff role
• Wireless user role
• VPN user role
• Printers and other exempt devices role

The printers and other exempt devices role can be used to put noninteractive network devices, such as printers, faxes, IP phones, and so on, into a user role. This allows for the creation of strict network access policies for these devices. These policies should allow them to communicate only using protocols that match the services they provide.

Tip

Creating roles for exempt device types is optional and can be time-consuming. The other option is to allow exempt devices full network access. However, taking the time to lock down the network access polices for exempt devices can greatly increase the security of those devices and your network as a whole.

Establishing Acceptable Use Policies

A network acceptable use policy is a clear and concise document that defines what users can and cannot do on a network. However, the focus of the AUP is on communicating to users what they cannot do. It also lays out the penalties for noncompliance and gives contact information. Ideally, before users are granted network access, they must first accept the organization's AUP. The problem has always been enforcing this requirement. Without some kind of network admission control system, ubiquitous enforcement is not possible. The NAC Appliance solution supports the enforcement of acceptable use policies.

Before creating your acceptable use policy for NAC Appliance users, determine who needs to be involved and what the approval process for a final policy will look like. Create an AUP committee that includes, at a minimum, persons from the Legal and IT departments. Draft a flow chart of the expected approval process the AUP will have to go through. Next, decide what documents the committee will have to produce to successfully complete the AUP. For example, to have an AUP approved in the education space, it is customary to need the following documents:

• Justification and purpose for creating an AUP This typically needs to be presented to the school board and must be approved in the beginning to allow for the creation of the AUP committee.
• A high-level AUP specifically created for or by the school board to establish the framework from which the final detailed AUP will be crafted It establishes the major security goals and network use guidelines. This must be approved by the school board.
• A parent letter and permission form informing them of the AUP and the use of NAC Appliance to enforce this AUP This must be approved by the school board.
• The final acceptable use policy document Typically, this is created by the committed and presented to the school board for approval. This is the document that will be used by the NAC Appliance solution.

In general, an acceptable use policy will include these parts or sections:

• AUP Overview or Purpose Serves as an introduction to the AUP.
• AUP Scope or Coverage Defines who must comply with this acceptable use policy.
• Acceptable Network Use Guidelines Conveys the appropriate use of the network.
• Unacceptable or Prohibited Network Uses This section might have several subsections, such as a subsection each for e-mail, copyrighted material, virus and worms, unauthorized access, illegal activity, and so on.
• Violation or Enforcement Policy Communicates the penalties and legal action that could be taken against AUP violators.
• Privacy Disclaimer Indicates that the organization assumes no responsibility or liability for a user's privacy while using the network.
• Definitions Fully defines all acronyms and terms used in the document.
• Legal Disclaimer Releases the organization from any and all legal liabilities resulting from the AUP itself or network use. Let the lawyers define this one.
• Right to Modification This disclaimer communicates your ability to modify this policy at any time without notice.
• Contact Information Provides users with a contact for additional information, questions, and complaints.

Your AUP might include additional or fewer sections than those listed here. The sections in the previous list should give you a rough idea of what to include in your AUP.

Tip

To find additional information on AUPs, such as how-to guides and examples, search Google using the keywords network acceptable use policy. For AUP samples, check out the SANS policy site at http://www.sans.org/resources/policies/. For K-12 organizations, check out the state of Washington's AUP guides at http://www.k12.wa.us/K-20/AUP.aspx.

The NAC Appliance solution has two methods for enforcing an acceptable use agreement. One is called a user agreement page and is used only by users who log in via web login. The other is called a network usage policy and is used only by users who log in via Clean Access Agent. Both methods can, and typically do, use and enforce the same acceptable use policy. Both methods enforce the policy by denying users network access until they acknowledge or accept the network acceptable use policy. After they accept the policy, they are granted network access.

The enforcement of an acceptable use policy is an optional feature. Enforcement can be selectively enabled as well. Enforcement can be turned on and off based on the client's user role, operating system type, or a combination of both. Additionally, it can be enabled and disabled based on the use of web login or the Clean Access Agent. For example, you might want to enable AUP enforcement for clients in the user role of Guest using a Windows XP host and either Clean Access Agent or web login. Figure 6-3 illustrates such a configuration for web login clients on NAC Appliance Manager.

Figure 6-3. NAC Appliance Manager Web Login AUP Configuration

Figure 6-4 illustrates the same configuration for Clean Access Agent clients.

Figure 6-4. NAC Appliance Manager Clean Access Agent AUP Configuration

It is important to understand the different delivery mechanisms and user experiences provided by the two enforcement methods. The user agreement page method used only by web login users makes use of a web page AUP delivery mechanism. After users have passed authentication and network scanner checks, the user agreement page can be presented to the user for acceptance. Users will be granted network access only if they accept the user agreement presented. Figure 6-5 shows a screen shot of the web login user agreement page that is presented to end users.

Figure 6-5. Web Login User Agreement Page

Figure 6-6 shows an example of the web page that displays if the user declines the user agreement. As you can see, network access is being blocked.

Figure 6-6. Web Login—Declined User Agreement

The network usage policy method used only by Clean Access Agent clients makes use of the Clean Access Agent dialog box to deliver the AUP for acceptance. After users have passed authentication and posture assessment, the user is presented with a link to the network usage policy and asked to accept it. If accepted, network access will be granted; if declined, network access will be denied. Figure 6-7 shows the Clean Access Agent–displayed network usage policy screen.

Figure 6-7. Clean Access Agent Network Usage Policy Screen

Figure 6-8 shows a screen shot of Clean Access Agent if the user declines the network usage policy. As you can see, network access is being blocked.

Figure 6-8. Clean Access Agent—Declined Network Usage Policy

If users decline the AUP using either method (web login or Clean Access Agent), they will be moved back into the Unauthenticated role and forced to complete authentication again.

Checks, Rules, and Requirements to Consider

This section covers how to include the host posture assessment and remediation checks, rules, and requirements into an organization's host security policy document. One of the major benefits to using Clean Access Agent is its capability to perform granular host posture assessments and remediation on Windows hosts. Therefore, your host security policy should contain the checks, rules, and requirements that NAC Appliance should look for, enforce, and remediate on Windows hosts. Because Clean Access Agent is loaded on the host, it has the capability to read into the host's registry, applications, services, and file system. Clean Access Agent also offers robust remediation capabilities for a host that fails a security requirement. The remediation capabilities include file distribution, link distribution, delivery of instructions, and auto update mechanisms for Windows, antivirus, and antispyware programs. The host security policy should include the details on how hosts will be remediated under different circumstances.

All posture assessment and remediation configuration is done at NAC Appliance Manager. It is here that you will configure the checks, rules, and requirements that will satisfy the policies contained in your corporate HSP document. Before creating your host security policy for NAC Appliance, it is important to understand the process that NAC Appliance goes through for posture assessment. This process uses a combination of checks, rules, and requirements that are applied to user roles and optionally operating system types. Checks like the one shown in Figure 6-9 are configured at NAC Appliance Manager.

Figure 6-9. Check Configuration Example

NAC Appliance rules, like the one shown in Figure 6-10, can be made up of several checks combined using Boolean operators. They can also be operating system specific.

Figure 6-10. Rule Configuration Example

A NAC Appliance requirement, like the one shown in Figure 6-11, defines what remediation mechanism is offered to any noncompliant users. In this example, the Windows auto-update service is being turned on and configured to download and install the most current updates.

Figure 6-11. Requirement Configuration Example

A requirement to rules mapping, like the one shown in Figure 6-12, is then performed.

Figure 6-12. Requirement-Rules Mapping Configuration Example

This mapping specifies that all the rules must succeed in order for the requirement to be met. The two rules that must succeed are pr_AutoUpdateCheck_Rule and pr_XP_Hotfixes. It also specifies a specific operating system type: Windows XP Pro/Home.

Finally, the requirements are mapped to one or more user roles. In addition, it is possible to further classify the requirements by operating system type. The order of operations NAC Appliance uses is as follows:

• Checks are condition statements that examine the client to find the state or presence of a file, service, application, or registry key. Table 6-1 presents the different check categories and their associated check types and operators.

Table 6-1. Checks

• Rules are made up of one or more checks that can be combined into an expression using the Boolean operators and "&", or "|", not "!", and evaluation priority parentheses "()". If the result is true, the client passes the rule.
• Requirements are made up of one or more rules. A requirement can specify that a host must pass any selected rule, all selected rules, or no selected rules in order for the host to pass the requirement.
• Requirements also define the mechanism to use and the instructions that will allow the client to remediate any failed rules. For example, distribute a file or link with the instructions "Click the link and download, install, and run the XYZVirus cleaning tool."
• Requirements are mapped to user roles and operating system types.

Figure 6-13 illustrates the order of operations.

Figure 6-13. Clean Access Agent Posture Assessment Process

This posture assessment process can be thorough or simple. The flowchart in Figure 6-14 shows an example of the authentication and remediation process NAC Appliance could follow.

Figure 6-14. Sample Authentication and Remediation Flowchart

Sample HSP Format for Documenting NAC Appliance Requirements

As discussed, the NAC Appliance uses several mechanisms to define what it should look for, or posture assess, on a given host. It also has several mechanisms for the proper remediation of any failed security requirements. Ultimately, the host security requirements and remediation steps that are performed on a client are based on the user role of the client. With this in mind, your HSP should have sections for each user role. Under each user role section, you would have the checks, rules, and requirements that pertain to clients of that user role. The following is a nice example of an HSP formatted in this way:

The NAC Appliance solution has lots of prebuilt checks and rules that you can use to build your requirements. All the built-in checks have a pc preceding their name, such as pc_AutoUpdateCheck. The built-in rules have either a pr preceding their name, such as pr_AutoUpdateCheck_Rule, or are special antivirus or antispyware rules. It is recommended that you use the newer special antivirus and antispyware rules rather than the pr rules where applicable. pr rules can only check whether an antivirus definition version is exactly equal, whereas an antivirus rule understands greater than as well. These checks and rules are constantly updated by Cisco and are automatically downloaded by your NAC Appliance Manager. Out of the box, NAC Appliance has auto-update support for Microsoft Windows, 24 antivirus vendors, and 17 antispyware vendors. This means that NAC Appliance automatically keeps up to date with the latest versions, .dat files, and hotfixes available for each of the supported vendors. Keep this in mind when creating your NAC Appliance host security policy. It is recommended that you use these built-in checks and rules wherever possible.

Common Checks, Rules, and Requirements

Here are some of the most common checks, rules, and requirements implemented by administrators of the NAC Appliance solution. All the examples given have corresponding built-in checks and rules written and are auto-updated by NAC Appliance.

• An antivirus program must be installed, running, and up to date. Most organizations specify specific antivirus programs for certain user roles. For example, employee user role clients must use the corporate Trend Micro antivirus client, whereas guest user role clients are allowed to use any of the 24 NAC Appliance–supported antivirus vendors.
• An antispyware program must be installed, running, and up to date. Most organizations specify specific antispyware programs for certain user roles. For example, employee user role clients must use the corporate Webroot antispyware client, whereas guest user role clients are allowed to use any of the 17 NAC Appliance–supported antispyware vendors.
• All Windows XP clients must be running Service Pack 2. The built-in check is called pc_Windows-XP-SP2.
• All Windows 2000 clients must be running Service Pack 4. The built-in check is called pc_Windows-2K-SP4.
• All Windows XP and 2000 clients must have the Windows auto-update service running. By default, NAC Appliance looks to make sure that the wuauserv service is running. The built-in check is called pc_AutoUpdateCheck. The built-in rule is called pr_AutoUpdateCheck_Rule.
• All Windows XP, 2000, NT, Me, and 98 clients must be running the latest Microsoft security hotfixes as defined by the NAC Appliance rules pr_XP_Hotfixes, pr_2K_Hotfixes, pr_NT_Hotfixes, pr_ME_Hotfixes, and pr_98_Hotfixes, respectively. These rules, and their corresponding checks, are continuously updated by Cisco. They include the most critical security hotfixes for XP, 2000, NT, Me, and 98. They do not, however, include every security update that Microsoft has ever released for each operating system. If you require additional hotfixes, you can edit the relevant pr_??_Hotfixes rule to include them.
• All Windows clients must have either Cisco Security Agent or Symantec Personal Firewall installed and running.
• All requirements dealing with the updating of antivirus and antispyware programs use the built-in AV Definition Update type. These rules are preconfigured to map to the matrix of 24 antivirus and 17 antispyware vendors and products supported by NAC Appliance. These rules do not require you to configure any checks and are continuously updated by Cisco. If the user fails these requirements, the user is presented with an Update button. When clicked, the Update button auto-launches the update program for the antivirus or antispyware program that failed to pass the policy.

Method for Adding Checks, Rules, and Requirements

Many organizations do not have a process in place that they can follow to determine if, when, and how a security update should be added to their host security policy document. Organizations that lack this type of process, or method, are in greater danger of making bad decisions about the security updates they choose to install. For this reason, it is important for organizations to establish and follow a formal method for adding checks, rules, and requirements. This subsection will deal with this topic as it pertains to the initial creation and subsequent revisions of the host security policy document. Knowing which security patches to enforce using NAC Appliance is a big job. The goal is to provide the information necessary for you to set up your own method, or process, for determining which checks, rules, and requirements you want to include in your initial host security policy for NAC Appliance. A secondary goal is to provide the information necessary for you to set up your own method, or process, for determining when to add, change, and delete new checks, rules, and requirements to your HSP.

Research and Information

The NAC Appliance solution comes with many preconfigured checks and rules, such as the ones described previously. Simply implementing these built-in policies goes a long way toward increasing the security posture of most organizations' hosts and networks. However, these are by no means the only security checks and rules available. In many cases, your organization might choose to implement checks, rules, and requirements beyond the scope of the built-in policies. When this occurs, it is vital that you are able to find the information and research needed to make the most informed decision possible. Regardless of whether the security fixes you put in place use the built-in policies, custom policies, or a combination of both, it is vital that you understand what the fixes are for, their impact, and their severity level. It is also necessary to remain informed about the emergence of new vulnerabilities, exploits, and viruses. Obtaining this information is not always trivial. Here are some of the commonly used security websites, blogs, and resources available online. Most are free, but some also offer a paid service.

• SecurityFocus (http://www.securityfocus.com) This is one of the best websites for obtaining security information.
• Full Disclosure Mailing Lists (http://seclists.org/#fulldisclosure) This site is made up of various security mailing lists, like the extremely popular bugtraq list and the sometimes controversial full disclosure list. New vulnerabilities and exploits are frequently announced on bugtraq before anywhere else in the world.
• Microsoft TechNet Security Center (http://www.microsoft.com/technet/security) This web portal serves as a good jumping-off point for investigating any Microsoft security vulnerabilities, updates, and exploits.
• Microsoft Security Bulletin (http://www.microsoft.com/technet/security/bulletin) This website has a nice search engine for Microsoft security bulletins. The site also has a link to sign up to receive security bulletins via e-mail, Really Simple Syndication, or instant message. The search engine allows you to search for vulnerabilities based on severity level and operating system type and version.
• McAfee Threat Center (http://www.mcafee.com/us/threat_center/) McAfee has a well laid out and informative security information portal here.
• Cyber Alert System (http://www.us-cert.gov/cas/) The national Cyber Alert System was created to ensure that you have access to timely information about security topics and threats. You can sign up to receive the alerts here.
• Government sites like National Vulnerability Database (http://nvd.nist.gov) and U.S. Computer readiness team (http://www.us-cert.gov) These are filled with timely security alert information and are vendor agnostic.
• metasploit (http://www.metasploit.com/) This site does not offer any security information but does provide an easy-to-use security tool to help you test the security of your hosts.
• Cisco MySDN (http://www.mysdn.com) This website, hosted by Cisco Systems, serves as a security portal to find information regarding security bulletins from all the major application and operating system vendors. It also has a paid service called IntelliShield that provides customers with a customizable, web-based threat and vulnerability alert service.

These websites and others like them can be found throughout the Internet. They can be powerful tools for gathering the security information you need to make an informed decision on which security patches NAC Appliance should enforce.

Establishing Criteria to Determine the Validity of a Security Check, Rule, or Requirement in Your Organization

A host security policy should have a section that documents the criteria to be used to decide whether a proposed security check, rule, or requirement needs to be added to NAC Appliance. The establishment of set criteria will serve to improve the accuracy of the decision process. The criteria used should be tailored for your specific environment and should refrain from using generalities whenever possible. The more fine-grained the criteria used, the more informed the decision process will be.

For every security fix proposed for and existing in the HSP, and subsequently in NAC Appliance, you should be familiar with or know where to obtain the following information regarding a security vulnerability:

• What products, applications, and versions are affected?
• What is the vulnerability's severity level?
• What is the potential impact or risk to the organization if the vulnerability is exploited? This point should be explored in detail, noting a best and worst case scenario.
• Can the vulnerability be exploited remotely?
• Are the exploits publicly available?
• Is the use of the affected software widespread in your organization?
• Are the ports, protocols, and hosts in question already being blocked using a firewall, Intrusion Prevention System, Personal Firewall, or NAC Appliance? If so, to what extent does this mitigate the exploit risk?
• Is a patch available for the vulnerability?
• If yes, is it possible to test the patch to make sure that it works as advertised?
• If no testing can be done, is the risk of deploying a faulty patch less than the risk of the vulnerability?
• If no patch is available, is it possible to use any of the security features in NAC Appliance to help mitigate this feature? If no, is it possible to use any other security products to do so?

Before taking action, it is important to understand what the expected overhead on the IT staff might be if the new patch or fix is implemented. This should be explored in detail, noting the best case and worst case scenarios. The following are some of the topics for consideration:

• Will there be additional help desk load?
• Will there be additional IT staff load?
• What is required of the end-user community?
• Will there be additional network load created due to deployment of new patches? If deploying patches over the WAN, what is the potential impact?
• Who will perform any testing needed? What resources are required to perform the testing?
• What is needed to set up the deployment method for distributing the patch or update?
• What is the expected impact on and reactions from the user community if the fix for the vulnerability is rolled out?

Method for Determining Which User Roles a Particular Security Requirement Should Be Applied To

After it is decided that a security fix or patch should be deployed in your environment, the next step is to decide what user roles should receive the fix. Additionally, it is important to determine whether the fix should be mandatory or optional. This might vary based on user role; some roles will be deployed as optional, whereas other roles will be mandatory. It is a best practice to deploy new security requirements as optional first and then, after a set amount of time, make them mandatory. This results in the least impact possible on the user community. However, if a vulnerability poses significant risk to the organization, the new security requirement should be rolled out as mandatory. The following are some things to consider when deciding what roles should receive a new security requirement:

• Do all roles run the affected software?
• Do any of the roles pose a greater risk than others if the patch causes adverse affects on clients? In other words, do certain user roles contain clients that, if debilitated due to a bad patch, would significantly affect the organization? If so, would starting with less risky user roles first to further assess the robustness of the patch make sense?
• Do any user roles have an elevated exposure to the vulnerability in question? If so, does this elevated exposure warrant mandatory enforcement of the new security requirement?
• Does the security requirement apply to the guest user role?

Method for Deploying and Enforcing Security Requirements

After it has been decided that a security requirement should be added to the HSP and NAC Appliance, it is necessary to come up with a deployment strategy. The security requirement could be made up of one or more files, actions, or patches. Keep in mind that deployment of the security patches will happen while clients are in either a Quarantine role or Temporary role. If they are using Clean Access Agent, patch deployment will always happen while in the Temporary role.

The requirement type chosen might affect the decision process regarding deployment type. As previously discussed, a requirement type has the following options for remediation: File Distribution, Link Distribution, Message Only, AV Definition Update, AS Definition Update, Launch Program, and Windows Update. The easiest types to deploy are the update types. This is because they use the already built-in deployment and updating mechanisms configured on the local host. For example, the requirement type of Windows Update uses the Windows update service already present on and configured for the client that needs the updates. Regardless of the requirement type chosen, the following deployment questions should be considered:

• Should the deployment method be the same for all user roles?
• Which deployment method would be the most efficient in reaching the user roles in question?
• Should the enforcement of the new security requirement be optional or mandatory in the beginning? Does this vary by user role?
• If optional, should the requirement be made mandatory at some point in time? If so, define the period between optional and mandatory. Does this vary by user role?
• Do clients in the Quarantine and Temporary user roles have privileges to access the proposed deployment resources? For example, if you use a link to http://www.fixme.com as your deployment method, you need to ensure that access to this URL is not restricted. To be sure, it is always best to test it.

Defining Network Access Privileges

The NAC Appliance solution has several methods available to grant and restrict the network access privileges of clients. Most of these methods are defined per user role; however, it is possible to define some of them per MAC or IP address. A host security policy for NAC Appliance should include details on what network access privileges should be given to what user roles and devices. Device details are typically reserved for devices, such as printers, that are exempt from NAC Appliance authentication and posture assessment but are still subjected to network access restrictions.

Here is an example that uses traffic control rules in NAC Appliance. A client in the guest user role should be granted access only to the Internet on TCP ports 80 and 443; all other network access should be denied. The following common and easily understandable syntax can be used for documenting NAC Appliance traffic control policies in the HSP. Typically, these rules would be found under their corresponding user role section in the HSP.

<line #> Permit|Deny <protocol> from <host(s) | network(s)> to <host(s) | network(s)> equaling | not equaling port(s) <list of port numbers or names>
Description: <explanation of rule>

The previous example would be written in the HSP under the guest user role/traffic control subsection as follows:

10 Deny IP from any to any internal network.
Description: Block IP traffic from anyone to any internal subnet or host.
20 Permit TCP from guest user role to any equaling port 80 or 443.
Description: Allow web traffic from clients in the guest user role to the Internet.
30 Deny IP from guest user role to any.
Description: Block everything else.

Formatting the rules in this way not only makes them unambiguous but allows them to be easily translated into the traffic control rules configured in the NAC Appliance Manager.

Enforcement Methods Available with NAC Appliance

Not all enforcement methods supported by NAC Appliance are supported in all modes of operation. This issue applies mostly to the In-Band and Out-of-Band operating modes. Many of the features are not available for out-of-band clients that have passed authentication and posture assessment. This is because once clients are certified, they are moved to the appropriate access VLAN. This access VLAN completely bypasses the NAC Appliance solution, making the use of some enforcement methods unfeasible. Table 6-2 lists the different network access control methods available, gives a brief description for each, and shows whether they will work with Out-of-Band and In-Band modes.

Table 6-2. NAC Appliance Network Access Control Methods

Commonly Used Network Access Policies

In short, a network access policy defines what a host can and cannot do on the network. The exact rules that make up any network access policy are customized for a particular environment but, nevertheless, there are some commonalities between organizations. This section will focus on those common elements. The network access policy defined in your HSP will typically cover all the enforcement methods that NAC Appliance supports. To review, those enforcement methods are VLAN segmentation, traffic control (access control lists or ACLs), bandwidth control, and session duration limits.

VLAN segmentation applies only if you use Out-of-Band mode. Additionally, for OOB mode traffic control, bandwidth control and session duration limits apply only while the client is in the authentication VLAN. After the client moves to the access VLAN, these controls no longer apply. You can optionally and manually configure switch or router ACLs and QoS to control clients while they are on the access VLAN. Traffic control policies are always tied to a user role in NAC Appliance. Some user roles (such as guest) have restrictive network access policies, whereas others are wide open (such as employee). In addition, it is always a best practice to lock down the network access policy on any Unauthenticated, Temporary, or Quarantine user role.

Here are some popular or mandatory user roles shown with a common example of their associated network access policy. This is formatted for a NAC Appliance host security policy. You can choose to use this HSP format or develop your own. The important thing is that your network access policy is well documented. Note that these pick up where the earlier sample HSP left off, at section IV. (See the section "Sample HSP Format for Documenting NAC Appliance Requirements.")

Summary

This chapter examined the intricacies of creating a host security policy for a Cisco NAC Appliance deployment. The following recommendations were made:

• Create and follow an HSP checklist.
• Make sure to get executive buy-in for the creation and subsequent enforcement of an HSP.
• Create an HSP committee. Be sure to involve the right people.
• Determine your organization's high-level host security goals. Use these as guides when creating the detailed host security policy.
• Break up your organization into security domains. Determine which security domains will use NAC Appliance and which will not. For those that will, you must determine what modes NAC Appliance should use in each domain (for example, In-Band, Out-of-Band, Real-IP-Gateway, and so on).
• Determine and create the user roles necessary for your organization.
• Create one or more acceptable use policies.
• Determine what checks, rules, and requirements will be enforced for each user role.
• Establish and follow a method for adds, moves, and changes to user role checks, rules, and requirements.
• Determine a method for deploying Clean Access Agent and remediation resources.
• Determine what network access policy should be assigned to each user role.
• Either use the host security policy formatting shown throughout this chapter or pick your own formatting. The important thing is to document your host security policy in a concise and easily understood manner.