This chapter covers the following topics:
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.
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.
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.
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.
— 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
— Ideally the CSO/CIO would be a core member
— Security group
— Networking group
— Server group
— Desktop support group
— Operations group
— Security incident response team
— Human Resources group
— Legal group
— Audit group
— 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 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.
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.
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.
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:
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.
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.
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:
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:
As you can see, user roles are integral to the functioning of NAC Appliance.
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.
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.
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:
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:
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.
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:
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:
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.
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:
In general, an acceptable use policy will include these parts or sections:
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.
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:
Table 6-1. Checks
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
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.
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.
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.
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.
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.
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:
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:
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:
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:
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.
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
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.")
This chapter examined the intricacies of creating a host security policy for a Cisco NAC Appliance deployment. The following recommendations were made: