4.1. Creating Policy

One of the most important pieces of any network access control infrastructure is the policy engine. The policy engine is central to a NAC deployment because it controls your entire NAC deployment by creating user access rules and controlling enforcement point in the network infrastructure.

The policy engine is responsible for determining whether a device or a particular usage should have access to the network. The policy engine also controls all the enforcement points on the network, whether the policy engine is a network appliance or a software agent running on a desktop machine or network server.

One of the primary roles of a policy engine is to make network access decisions based on access control policies determined by the NAC administrator. The core of the NAC policy typically includes three pieces of information:

4.1.1. Controls

With NAC, this policy includes network, user, and device information, using the policy engine and its primary job functions.

4.1.1.1. 802.1X control

The policy engine provides a RADIUS service with which the switch can communicate.

In an 802.1X deployment, the policy engine provides the RADIUS server to provide an authentication source for the switch or access point. The policy engine makes the final decision about whether the client should be allowed on the network and what restrictions the client should have. These restrictions can include access controls such as Virtual LANs (VLANs) or Access Control Lists (ACLs).

4.1.1.2. Layer 3 control (inline enforcement)

For a Layer 3 deployment, the enforcement points are controlled by the policy engine, meaning that the enforcement points enforce the policy that the policy engine creates.

4.1.1.3. User authentication

The policy engine verifies user or device identity for any device that connects to the network. For instance, when a corporate user connects to the network, the policy engine verifies the user's credentials against the authentication server (we talk about authentication servers in the section "Authentication server," later in this chapter). If the user has valid credentials, the policy engine performs a group lookup to see what kind of a user is connecting — for example, the user might be an employee in human resources. The controller then knows that the user is a valid employee and should have access to the human resources network or servers. If user authentication is the only part of the policy being enforced, the policy engine can now signal an enforcement point and push a policy that gives the user access.

4.1.1.4. Endpoint posture

The policy engine verifies endpoint posture for any device connecting to the network.

One of the greatest benefits of a network access control deployment is the ability to be able to verify the state of an endpoint before it connects to the network. This ability gives you a lot more control over your network. You can now create a policy that says, "If you're an employee (who has valid user credentials that have been verified via user authentication) and you're connecting to the network with a corporate asset that's compliant, you can have access to the network."

If a device goes out of compliance (for example, if it doesn't run the correct antivirus software that has the latest virus definition files), you can

• Remove the user from the network.

• Quarantine the user to another network.

• Block the user's access to certain parts of the network.

4.1.2. Continuous monitoring

The policy engine creates dynamic network policies that are pushed out to devices on the network and therefore must keep track of them.

For instance, a user receives access to the network because his or her device is compliant and meets all the NAC policies that you've defined, but after gaining access, the user changes his or her device so that it goes out of compliance. You want to make sure that endpoint agent recognizes the changes, communicates the changes with the policy engine, and then takes action on them. You could configure remediation messages so that the user receives a simple message or the network changes to give the user limited access.

Don't leave open holes in your network. Holes defeat your whole NAC deployment and increase your risk whenever a user unplugs from the network. Remove the policy that you have set (typically static network policy on firewalls) so that the next user can't just piggyback on the access created for the prior user.

Although all these functions are relatively simple to manage on their own, the usability and flexibility of the policy engine becomes critical to the success of your deployment when you combine these functions to create complex access policies. There is a potential for management to become very difficult when many functions are used together.

4.1.3. Location

The policy engine's location in your network is a critical deployment consideration.

If your network access control deployment is going to control access for all your users who get on and off the network by controlling devices deployed in the network, you need to place the deployment in a location where all the devices that it's controlling can reach it.

For most networks, it makes sense to put the policy engine in the datacenter. But you need to consider these high availability concerns: Datacenter survivability: Make sure that you have a redundant datacenter or backup policy engine store that Layer 3 devices (such as switches and access points) can contact if your primary datacenter falls off the face of the Earth. If your network access control deployment is controlling access for all users getting onto the network and you lose a datacenter, you lose the policy engine that allows people to get onto the network. Branch survivability: If an off-site central policy engine controls access to your branch locations, you need a backup plan. Otherwise, if you lose your WAN link to the central datacenter, you can't get users on the network.

4.1.4. Oh, one more thing...

You're adding a layer on top of your network called NAC that can potentially block all users from getting access to the network. Hmm. Users aren't going to be too thrilled if something happens to the policy engine and they can't work. If your NAC goes down, access goes down. Your NAC implementation is a service that controls your network which must always work and be available.

Because you want your NAC to always be on, you need to identify a solution that has high-availability options (such as an active/passive pair of policy engines) that protect you from a large network access outage if one of the policy engines were to explode. High availability means redundancy and backup, and it requires a combination of network design, hardware, and software configurations.