The Network Access Control Challenge

Protect what you value.

The Network Access Control ChallengeRealistic Considerations for Strategy and Deployment

Solution Brief www.mcafee.com

Table of ContentsExecutive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

NAC Defined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Authenticate the User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Assess the Endpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Enforce the Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Network Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Business Problems Today . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

#1 Restrict Network Access for Unauthorized Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Allow Authorized Guest Users on Healthy Managed Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Allow Authorized Guest Users on Healthy Unmanaged Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Allow Authorized Users on Unmanaged Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

#2 Restrict Network Access for Unmanaged Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Unmanageable Device Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

#3 Regulatory Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

#4 Health of Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Wired LAN Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Edge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

802.1X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Inline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Gateway Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

DHCP Based Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Wireless LAN Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Remote Access VPN (IPSEC & SSL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Mobile Workers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Personal Systems from Home . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

McAfee’s NAC Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9


3

NAC Defined

The Network Admission Control concept, while based on the work and concepts from many other sources, is generally attributed to the Cisco marketing machine of 2003 that brought it to the market . The concept was simple – rather than spend your entire security budget on perimeter and endpoint defenses, why not add a layer that would only allow authorized users onto the network that have passed a simple test that ensures they are adequately “healthy” . It was not so much intended as a “catch-all” net for everything except an authorized user on a healthy system, it was more of a method of picking off the low hanging fruit of a company’s employee’s doing a poor job of protecting their corporate assets and bringing malware into the environment, which at the time was a significant origin of the malware within an enterprise . To this end, the common features and functions for NAC were also simple:

Authenticate the UserWhile not all approaches to NAC allow for role-based restrictions based on authenticated identity, a NAC product must minimally be able to block network access to every device until:

• The user has authenticated successfully, • The user is determined to be part of an exception / bypass

list, or• The system is determined to be part of an exception /

bypass list

Assess the EndpointSome method of assessment must take place to understand whether the endpoint is considered “healthy enough” to be allowed on the network, as defined in a NAC policy . This generally requires some kind of agent deployed onto the endpoint or a combination of quarantine and credentialed remote scanning . Whatever approach is used to endpoint assessment, the current state of compliance with the policy must be verifiable . Generally these include rules such as the existence of functioning anti-virus and firewall, the latest Microsoft security patches, and sometimes the non-existence of some blacklisted malware or applications . For “unmanageable” devices that cannot be assessed, some method of “exception” will generally be used, and preferably this will be combined with some method of verification of device type .

Enforce the PolicyGet authorized users onto the network with a healthy system as quickly as possible . Often this requires the capability for the system to automatically apply the correct policy based on who the user is, whether it’s a managed system, the location from which the user is connecting, and what operating system and applications are on the system . One of the most critical components of this objective is rapid remediation of any health problems within a quarantine zone, and the general customer expectation is that this happens in an automated fashion using their existing remediation solutions .

The Network Access Control ChallengeRealistic Considerations for Strategy and Deployment

NAC has several primary user scenarios that are simple to understand but that rely on various technical approaches that can be challenging to design and deploy correctly. This document is intended to lay out the most common use cases, the technical approaches most appropriate for each case, and to call out some of the typical problems with each of these approaches. The research for this document comes from an aggregation of customer and pros-pect interactions, input via direct conversations and articles with several industry analysts and press, and of course many conversations with internal experts at McAfee.


4

Network Access ControlOver time the NAC term has more generally come to stand for Network Access Control, with a significant portion of the attention from press, analysts, and vendors focusing on what were initially peripheral requirements:

• What about guests and contractors with their own equip-ment?

• What about users coming in from home via VPN?• If you know who they are and have the ability to control

their access, why not apply those controls to where they go and what they can do?

• What if they become unhealthy once they are on?• What about “unmanageable” devices like printers and

IP phones? If you just look at MAC, what stops someone from impersonating or tailgating?

Business Problems Today

As already mentioned, the concept of what NAC is and what problems it applies to have shifted over the last few years . It is also critical to consider who within the business is focused on each problem, and whether or not that tends to translate to real budget and spending . Available budgets will ultimately set the features and functions of the products considered .

An often overlooked barrier to NAC for many organizations is also the complexity of the political environment . In many cases, a given risk would most appropriately be mitigated with a control that requires cooperation and ownership of different functional groups . In some cases, a risk within one group would best be solved with a control that is wholly within the domain of another, and to further complicate the matter the control should be designed and tested by yet a third. For instance, in many cases the desktop / systems groups are really the owners of the risks posed by malware or unauthorized network access, the network group becomes the owner of implementing the control (and generally the actual buyer), and the security group will ultimately define the control and require a certain level of reporting . The network group in this situation may be averse to buying a solution which has a dependency on the systems group (such as Microsoft NAP, for example) or that puts any kind of workflow burden on them, but they may also be averse to any solution which allows the systems group any kind of access to the network infrastructure components (e .g . SNMP write credentials within McAfee’s ePO management system) . Appropriate separation of duties for configuration items, workflow items, policy, and reporting is critical .

Given these factors, the authors have attempted to prioritize the approaches which we have observed driving the purchase decisions in contemporary NAC projects .

#1 Restrict Network Access for Unauthorized UsersThe requirement that seems to have risen to the top for most organizations: “if an unauthorized user gains physical access to a network drop, they should be blocked immediately” . There seems to be several reasons that this functionality has taken prominence in most NAC discussions, including that it’s:

• An automated control that is easy to communicate to auditors

• Reasonably easy value proposition for executives to understand

• Well within the realm of traditional networking equip-ment vendors

• Well within the realm of traditional network engineering departments

• Very similar (if not identical – 802.1X) to the controls implemented for wireless security in many organizations

Generally this requirement cannot stand on its own, but it has become, in many cases, a deal-breaker if not well satisfied . For most customers, this requirement also makes several converse requirement assumptions:

Allow Authorized Guest Users on Healthy Managed SystemsA contractor / guest whom is attempting to access the network from a healthy managed asset must be allowed onto the network . Generally the guest would have to be added to the domain to log onto the managed system anyway, so should fall under the same case as a regular user on a managed system . However, in some consideration may need to be given for the specific policy that is applied to that user .

Allow Authorized Guest Users on Healthy Unmanaged SystemsA contractor / guest whom is attempting to access the network from an unmanaged system should have both a mechanism to authenticate (generally some kind of web form) and a method to be assessed for health . While many guest users do in fact have full rights to their systems for installing a temporary agent or for disabling their firewall or HIPS, many others do not .


5

Allow Authorized Users on Unmanaged SystemsIn most cases there is an expectation that some method exists for regular users to get on the network with organizational assets that fall outside the standard authentication mechanisms, or with their own systems, whether physically connected internally or the more common scenario of using a VPN from home. Generally this would mean extending their back-end user credentials (such as AD) to be used as part of NAC authentication, such as via a web form or VPN client. As in the case of the authorized guest users, some method of assessing the health of the system would be required .

#2 Restrict Network Access for Unmanaged SystemsClosely related to the above sub-requirement “Allow authorized user on unmanaged systems”, there are many customers who put the emphasis of NAC squarely on how well the solution deals with the “unmanaged system” problem . The distinction here is that the solution is capable of absolutely restricting access for everything that is not explicitly allowed via being “managed” or that isn’t explicitly an “exception” . There is often particular emphasis on those issues that seem to be problematic for many of the solutions on the market today, such as tailgating and impersonation (see 802.1X discussion). For those customers that have really thought through their scenarios, or that have actually attempted to deploy a NAC solution already, there also tends to significant usability concerns in dealing with “unmanageable” devices .

Unmanageable Device HandlingFor organizations with significant numbers of assets that are effectively “unmanageable”, the NAC solution’s ability to automate portions of the workflow necessary to ensure that the authorized devices are NEVER quarantined and that unauthorized devices are ALWAYS quarantined can be a significant consideration in the usability of the product . While some customers may be willing to import lists of devices as exceptions and others will prefer to use OUI vendor codes to dynamically assign the exceptions, virtually none will put up with manually typing in the MAC / IP’s or having them first quarantined and “clicking them out” .

One of the clearest use cases here is hospitals, many of which have thousands of IP-based devices that get unplugged, moved, and plugged back in anywhere in the hospital and which may literally be needed in a life or death situation at the moment they are connected . However, it is also critical that unauthorized users not get on the same network segment as those devices or on the same network as the health information systems full of regulated, private patient data . At the same time, most

hospitals today are operating in a competitive environment and are trying to be seen as cutting edge with patient internet access and direct interfaces for patients to access their own records .

#3 Regulatory ComplianceWhile many of the driving requirements for NAC can easily be tied back to compliance, most of the buying behavior at this point in the NAC lifecycle has not focused on compliance itself as the requirement . Most companies would consider it best practice to do what they can to keep unauthorized users and systems off their network and malware out of their environment, but to get budget to shop for a NAC solution and the belief that user intolerance of NAC can be overruled, there is some likelihood that someone up the chain is looking at a risk of regulatory non-compliance, avoiding a repeat performance of some kind of significant incident, or is operating in an industry where the risk of bad press from an incident is of sufficient risk to drive a major purchase . In each of these cases there is likely some requirement for either proving periodically (generally through good reporting) that compliance is being met, or even better for proving that the system is configured in a way that enforces compliance (automated control) .

One example of a very close link between compliance and NAC is the Payment Card Industry (PCI) requirements:

5.1 Deploy anti-virus software on all systems commonly

affected by viruses (particularly personal computers and

servers) Note: Systems commonly affected by viruses typically

do not include UNIX-based operating systems or mainframes.

5.1.1 Ensure that anti-virus programs are capable of

detecting, removing, and protecting against other forms of

malicious software, including spyware and adware.

5.2 Ensure that all anti-virus mechanisms are current, actively

running, and capable of generating audit logs.

This requirement could be met without NAC . However, the challenge to this kind of requirement is not necessarily in achieving compliance, it is proving compliance in some kind of reasonable and repeatable way . There are many approaches that auditors use to determine compliance for these kinds of requirements, but the further the available options move away from automated system controls, the more likely it becomes that some auditors will not accept the test plans or even controls that others would .


6

Example: The internal audit team or security team may feel that McAfee’s ePO is capable of making sure that VirusScan Enterprise is configured correctly, running, and the DATS are up to date . However, the auditor may not accept this as an automated control without proof that ePO is working effectively . Reports within ePO that can demonstrate the level of compliance of managed systems’ anti-virus are useful, but it is easy to then step into the problem of proving that ePO is managing all the systems . Rogue System Detection is an excellent monitoring control for this, so then the test takes on the form of proving that it is capable of bringing all detected “rogue” systems into compliance, or that some person actually monitors this closely enough to catch every one and deal with it in a timely manner . One method of testing this is to review the logs for every rogue system that has been detected and verify that they have all become managed (or an exception) . If the data population is very large, a sample of rogue systems may be acceptable, but this can still take a lot of work . Some auditors may also want to review a random or selective sample of systems to verify their state . If too many turn out to be not up to date or not even being managed by ePO, then the sample will widen or become 100%. This is the kind of snowballing control that has cost so many companies so much money from Sarbanes Oxley and PCI audits .

Clearly NAC is a much more effective control – by design, a user cannot get on the network without proving “health” . The policy that defines health can easily be shown to enforce AV, and every exception can be clearly demonstrated . The auditor can simply focus on testing the automated system control, which really only means testing once with no room for failure . Most of the work will then involve clearly documenting the configuration and workflows, showing a persistent audit trail, and demonstrating role-based controls that would not allow an administrator or help desk person to bypass the controls without going through the approved processes . It would take many of these regulatory requirements that can enforce before the potential savings in audit preparedness, consulting, and costs for the auditors themselves to validate controls before NAC may have a positive ROI . However, the savvy internal IT auditor or risk manager may who has recognized the potential of NAC is still unlikely to play much of a role in the selection process once handed over to the network engineering group as a required project .

#4 Health of SystemsThe assessment functionality of the NAC solution is, for many buyers, prematurely being considered a commodity technology that every solution should be able to do well . This not only seems to be the case for the persistent

(managed) agent, but also the “dissolvable” (unmanaged) agent . For most organizations the capabilities of the agent will ultimately hold a significant role in the success or failure of the NAC deployment, so getting the buyer to adequately consider what their requirements really are in this area and how the competition doesn’t always measure up is a challenge for the sales and marketing teams . This is especially true for McAfee Network Access Control (MNAC) product, generally considered a leading product in agent functionality and available checks (content) .

Most NAC buyers are looking for a lightweight agent which does a very quick scan, allows custom checks, and auto-remediates any problems . It should clearly communicate to the user its status if scanning or in quarantine . Once remediated, the agent should quickly get the user back on the network and let the helpdesk know what happened . Until healthy, there should be no access to the network .

For unmanaged guests and contractors, they would like a very small downloadable agent which does not require administrator rights or have to be installed on the system . It is also a common expectation to have some kind of remote scanning capability to both subsidize the capabilities of the agent as well as to pick up any platforms for which an agent is not currently available .

Deployment Scenarios

NAC has many different deployment scenarios, each of which often has more than one technical approach to implementation . Ultimately the technologies and deployment scenarios used should be associable to the goals for NAC and the unique aspects of the environment . It is also increasingly common to see organizations planning a staged roll-out of NAC over time, treating many of the deployment scenarios as an independent phase .

Wired LAN AccessThe most common requirement for NAC is to protect wired LAN from the traveling laptop, the guest or contractor, or even the unauthorized user who walks into a conference room . Key to this requirement is to somehow keep that system off the network until authentication and health assessment have completed . For the managed system, McAfee‘s Network Access Control endpoint software and a few other products on the market are capable of a self-quarantine via the onboard packet filtering firewall . However, for the unmanaged system there must be a mechanism within the network itself to enforce the quarantine and assessment .


7

EdgeAll things being equal, it is always preferable to deploy NAC enforcement as close to the endpoint as possible at Layer 2 . For typical wired LAN situations this would mean blocking the user at the first hop from the endpoint, which for most networks today would mean a manageable distribution switch . In theory the best approach would be to deploy intelligent switches across the entire distribution layer with stateful packet inspection on every port, where authentication, health, and identity based access would be enforced . However, the vendors attempting to sell this kind of solution today are not dominating the market for many important reasons, some of which include:

• Price per port is relatively high• There are other, more cost effective methods of achieving

NAC with the equipment that most organizations already have in place

Given these and other challenges, the more common approach is to utilize existing standards and technologies within the architecture that most organizations have in place already . While it is enforcing at the edge switches, the actual NAC component is often located somewhere within the network and commonly referred to as “out-of-band” enforcement .

802.1XMany of the currently deployed switches within core, access, and distribution layers are capable of 802.1X enforcement . Some are capable of authentication and basic VLAN assignment, some can assign ACL’s based on the authentication, and some can do both . The complexity and limitations of setting up VLAN’s across the organization generally favor implementing 802.1X with ACL’s when available. However, it is important to remember that 802.1X was not designed as a NAC protocol, and is generally focused completely on the user rather than the system .

If a system will remain static on the same port, then 802.1X will probably work well by assigning a static ACL or VLAN to that port to be used after authentication . However, if several users are coming in on one port (such as coming in from a hub, IP phone, wireless AP’s, VM’s, NAT / internet sharing), it is obviously not acceptable for systems to “tailgate” after one has authenticated . They must be individually recognized and authenticated . This is generally referred to as “multi-auth”, and it does seem to violate the 802.1X standard so different switch vendors will often have varying degrees of functionality to meet this challenge . It is critical that any NAC solution be able to take advantage of the functionality that the switch does offer .

If a system might move around and come in via different ports / access points, then an option of assigning a dynamic VLAN as appropriate for the user/system that is authenticating should be supported . Even better is the concept of dynamic ACL’s, though it’s not clear how commonly this is supported on the most deployed switches .

Where a user has failed to authenticate or the system lacks the proper supplicant, a restricted VLAN or ACL should be supported . Preferably this would be isolated as a private or dynamic VLAN or ACL to avoid cross-contamination or put other quarantined users at risk . Many switches today also support Web Auth capability, so that any system which lacks the proper supplicant is still given the opportunity to authenticate via web form .

Where a system is non-compliant with policy, an option must exist to move it to a remediation VLAN or apply a remediation ACL until the problem has been fixed . Because 802.1X was not designed with NAC in mind, there is really no concept of remediating the system and getting it back out of quarantine, so NAC solutions often have to get creative in how they can get either the switch or the endpoint to reset the connection once the remediation work is completed and force the switch to re-authenticate and re-assign the VLAN or ACL.

Where an authorized system is unmanageable or lacking a supplicant but needs to be on the trusted vlan, some method of MAC authentication bypass must exist which would allow the device to bypass based on MAC address or some kind of unique identifier . However, MAC addresses and some other identifiers are so easily spoofed, it is also important that compensating controls exist to mitigate the risk . Often this includes some level of fingerprinting capability, the ability to filter protocols that should not be used by these devices (such as printers), and/or some form of enhanced MAC auth or web auth .

InlineIt is not always possible to use all existing edge devices in an enforcement capacity or to replace them, in which case “inline” enforcement can be an effective alternative . The goal is to authenticate and assess the health of devices as close to the network entry point as possible, and to remediate any non-compliant systems as quickly as possible

so that they may get onto the network . Where layer 2 NAC is not possible then layer 3 NAC is the appropriate fallback .

Unfortunately the quality of inline device which many organizations would entrust to maintain wire-speed inline


8

enforcement with good failover capability may also be too expensive to scale to sit behind every edge device . For this reason inline enforcement may be better suited for specific network segments with a particularly high risk or value, such as gateway access points .

Gateway AccessIn this deployment scenario, NAC is enforced at the Layer 3 boundary in a distributed campus network . This deployment scenario may be useful as a stage in NAC deployment when edge enforcement isn’t viable, but can also be an effective enforcement method between network segments such as:

• between a trusted and less trusted network,• between a branch office and main campus, • between main campus or a visitor site and access to the

Internet, • between extranet and intranet, and • on access to protected servers in a data center.

By design an endpoint may need to cross the path of more than one enforcement point, so it important that the policy management server is able to accommodate a workflow that may otherwise put the endpoint through multiple rounds of authentication and assessment .

DHCP Based AccessDeploying NAC via DHCP alone will rarely meet the requirements of an organization’s NAC strategy since DHCP operates only at layer 3, and would only play a role in granting access if the system actually requests to lease an address . Assigning a static address can, in theory, completely bypass the control . In some cases it may even be possible to spoof a MAC address and/or an IP address of an exception in order to receive full access to the network relying on detection via DHCP . Any robust NAC solution utilizing DHCP based NAC must have some method of detecting all statically assigned IP addresses that are not excepted, remediating those nodes to use DHCP instead, and validating the exceptions for imposters .

There are actually several technical approaches to deploying DHCP based NAC:

• The NAC solution can run its own DHCP service to act as a complete replacement for the customer’s current service . When a lease request comes in, the NAC solution would give either a normal scope or a quarantined scope based on the state of the endpoint . This method provides a high amount of control, but can also be disruptive to the environment during the cutover . Many larger customers

are reluctant to trust a NAC provider to provide such a critical and core service, especially to vendors who are not known providers of high end networking services . This is also a solution that may be expensive to scale for those customers that have distributed environments with many DHCP servers .

•The NAC solution can run in a proxy capacity where DHCP requests are made to the NAC device which then passes on the requests to the customer’s primary DHCP server if the endpoint has been found to be healthy . Otherwise, the proxy gives out its own quarantine scope for reme-diation actions . This solution can be expensive to scale in distributed environments, since the proxy always needs to be in front of the primary DHCP servers .

• The NAC solution can be run in a mode where it sim-ply listens for DHCP requests and only intercepts those that are not known to be authenticated and healthy . The unknown devices (or those in unhealthy state) are either given a quarantine lease / scope or diverted to a quarantine network segment with its own DHCP service . This approach can be expensive to scale in environments with distributed DHCP servers, since the NAC device must always be inline between the DHCP server and the end-point . It often also requires that the customer bring up a new DHCP server for the quarantine environment if the NAC device itself is not capable of handling the quaran-tine scope .

• Some of the common DHCP services allow software plug-ins to be installed, which can interact directly with the service itself . In this way, a NAC component can be installed on each DHCP server to interject in those lease requests that come from unknown or unhealthy systems . Where available, this can be a cost effective way to deal with distributed DHCP environments .

Wireless LAN AccessIn this deployment scenario, NAC would also typically take place at the edge—the first Layer 2 device from the endpoint—but in this case it would typically be a wireless access point (WAP) . Wireless access points handle many users per device, and often have a variety of methods of handling the authentication process . Most WAP’s have long been making use of 802.1X as a standard method of authentication because of the heightened need for security . Some WAP’s have more capability than others for attempting to do a quarantine or remediation, and some even have very defined concepts of groups and ACL’s . However, it is often the process of re-checking after remediation and allowing the system automatically back on


9

to the network without completely confusing the user as to what is happening or expecting them to jump through hoops that separates the better NAC solutions .

It is possible to do the enforcement immediately behind a wireless access point (e .g . switch or inline device), but there are some critical aspects to be considered:

• The enforcement point cannot function at Layer 2, since every endpoint coming in will be from the same single port on the WAP . It is clearly not acceptable to quar-antine an entire WAP because a user comes on that is unknown or unhealthy .

• The enforcement point must be capable of sending some endpoints through remediation, some directly onto the secure network, some into quarantine that will require manual remediation, and some just out to the internet without ever being able to touch a private, enterprise system .

• The enforcement point should be able to pick up if an 802.1X or other form of acceptable authentication has already occurred as part of the WAP authentication process, and not require the user to re-authenticate . However, system health should still be assessed if the WAP was not capable of considering this as part of the authentication process that is used .

• If the system is being given some kind of bypass or exemption from health, then there should be some level of coordination between the enforcement point that is responsible for determining the MAC exemption and the system that is validating that the system using the MAC address matches the type that is expected .

Remote access VPN (IPSEC & SSL)In this deployment scenario, NAC is being enforced at the point where remote systems are granted access to the enterprise network . This is a common initial phase of implementing NAC since it can be done without impacting the rest of the network users and it is often a high risk gateway serving mobile workers and, in some case, even allowing connections from employee’s home systems .

In this scenario the “edge” device would really be the VPN termination point (e.g. the VPN concentrator), although at present attempting to enforce NAC on the VPN itself can be both challenging and limiting due to their proprietary nature . In many cases it is not particularly important whether the NAC enforcement is happening on the VPN device, inline just behind the VPN device, or

even at a switch that must be traversed prior to entering the secure network . What is important is that users can authenticate, be assessed (and remediated if necessary), and granted access to the internal networks for which they are authorized in a reasonably quick and easy workflow . Just as in other scenarios, it is critical that every user and system be considered independently and granted their own appropriate level of access .

Mobile WorkersFor mobile workers on the road or working from home, a smooth process of assessment and remediation is key . In many cases the policy used for the system when mobile is not the same as the policy that would be used once connecting to the corporate network, so the NAC solution must be able to assess based on the appropriate policy . It is also necessary that as part of the assessment, the NAC policy itself is checked to make sure it is not out of date .

Personal Systems from HomeCritical to this use case is that an authorized user must be able to authenticate from an unmanaged system via the VPN connection and be redirected to download a temporary or persistent agent . If found compliant after assessment, then the user must be automatically allowed onto the network as appropriate for their authorized level of access . If non-compliant, the NAC solution must give the appropriate instructions for self-remediation .

McAfee’s NAC Solution: Unified Secure Access

To date, NAC solutions have required customers to change; change their networks, change their policies and change the way they do business while increasing operation cost, complexity and errors . McAfee’s Unified Secure Access NAC solutions adapt to customers business and infrastructure while reducing operational cost, errors and complexity associated with other solutions .

McAfee’s Unified Secure Access NAC solutions uniquely enable enterprises to manage access to networks and systems based on in-depth knowledge of system health, compliance and user identity and enforce compliance both pre- and post-admission with a broad array of enforcement options, including end-point, in-line and infrastructure integration options . This along with McAfee’s industry leading policy management infrastructure enable, for the first time, highly simplified NAC implementations that reduce operational cost and resources while ensuring reliable access to approved systems and personnel . Compared to switch or router-based solutions which require expensive forklift upgrades to network infrastructure and complex and brittle policy definitions, McAfee’s Unified

Solution Brief

10

www.mcafee.com

McAfee, Inc . 3965 Freedom Circle Santa Clara, CA 95054 888.847.8766 www.mcafee.com

© 2008 McAfee, Inc. No part of this document may be reproduced without

the expressed written permission of McAfee, Inc . The information in this

document is provided only for educational purposes and for the convenience

of McAfee’s customers . The information contained herein is subject to change

without notice, and is provided “as is” without guarantee or warranty as to

the accuracy or applicability of the information to any specific situation or

circumstance . McAfee, Avert, and Avert Labs are trademarks or registered

trademarks of McAfee, Inc . in the United States and other countries . All other

names and brands may be the property of others .

5008brf_nac_challenge_1008

Secure Access Solutions adapt to the threat level you want to address, the applications you want to protect, the users you want to allow and the systems you want to conform to your security policies .

To learn more about how McAfee’s Unified Secure Access Solutions can solve your Security, Compliance and Access Control needs, please visit www .mcafee .com or contact your McAfee sales representative or partner .

1. Policy 2. Discover 3. Enforce

4. R

emed

iate

5.

Monitor

1 2 3

4

5

Step 1: Policy

Define health, machine/user identity,

application policy

Step 2: Discover

Scan forrogue devices,

alert and report

Step 3: Enforce

Pre or PostAdmissionhealth against

policy is checked.Malicious behavior

monitored

Step 4: Remediate

Take action basedonoutcome of policy

check or behavior

Step 5: Monitor

Monitor endpoint to ensure

ongoing compliance

Documents

The Network Access Control Challenge