Network Access Protection
[LEFT]Security Watch Network Access Protection John Morello
Prerelease information in this column about Windows Server “Longhorn” is subject to change.
One of the biggest security threats facing organizations of all sizes today is rogue devices behind the network perimeter. Regardless of how well an organization may have protected itself against external threats from the Internet, its security may be at risk from a well-intentioned employee unwittingly turned into a vector of
malware transmission by a worm or trojan. Nowhere is this more true than in the IT environments of small and medium-sized organizations, where staff members’ personal and business laptops may be one and the same and where network access control technologies are often too expensive and too complex to deploy. However, it’s usually precisely these organizations that pay a high price for downtime, so protecting against these threats is critically important.
Network Access Protection (NAP) technology from Microsoft allows organizations of all sizes to proactively check the health of computers as they join the network and to persistently ensure that they stay healthy throughout the time they’re connected. NAP provides a flexible, policy-based architecture for organizations to protect themselves from non-compliant computers intentionally or inadvertently brought on to their networks by employees, vendors, and visitors. NAP is built around four basic pillars: policy validation, isolation, remediation, and ongoing compliance.
NAP Overview
The first core service provided by NAP is policy validation. Policy validation is the process in which NAP evaluates a system against a set of administrator-defined rules and classifies the system’s state of health.
IT administrators specify a set of policy elements that NAP uses for comparison purposes when computers attempt to connect to the network. Computers that match the policy elements are considered healthy, while those that fail one or more of the checks (as specified by the administrator) are deemed unhealthy. These policies can check for things such as the presence of antivirus and antispyware software, whether a host firewall is active, and whether the computer is missing any security updates. Additionally, because NAP is built to be extensible, independent software vendors can create their own plug-ins for NAP that allow for application-specific checks to take place.
Another core service provided by NAP is network connectivity restriction. Depending on the policies defined by an administrator, NAP can place machines into various states of network connectivity. For example, if a machine is deemed to be unhealthy because it’s missing critical security updates, NAP can place that machine into a quarantine network, where it can be isolated from the rest of the environment until it is returned to a healthy state. Without NAP, the unhealthy client would have unfettered access to the organization’s network. If malware were able to compromise the machine through holes the missing updates would’ve plugged, it would be able to actively attempt to spread its infection to the rest of the network. [B]Figure 1[/B] gives you a general idea of the architecture.
[IMG]http://i.technet.microsoft.com/cc162368.fig01_L%28en-us%29.gif[/IMG] Figure 1[B] General NAP architecture [/B](Click the image for a larger view)
Simply restricting connectivity, though, is not an efficient way to handle unhealthy machines (after all, your users still have work to do). So NAP also provides remediation services in which unhealthy, quarantined machines can correct their health problems without administrator intervention. In the example above, the restricted network would only allow the unhealthy computer to access specific network resources required to install the missing updates, such as the organization’s Windows Server® Update Services (WSUS) computer. In other words, with NAP in place, the unhealthy machine is only able to access those network resources that allow it to get healthy; it cannot send traffic to the rest of the network until it is cured.
The final pillar of NAP is ongoing compliance, in which these health policies are enforced throughout the time the computer is connected to the network, not just at the initial connect. From our example, consider what would happen after the computer updated itself and became healthy (and thus was granted unrestricted network access). If that computer later fell out of compliance because, for example, the Windows Firewall was disabled, NAP could automatically re-quarantine that machine. NAP also allows administrators to configure auto-remediation, in which the noncompliant state is automatically corrected without additional user intervention, even long after the initial network connection is complete.
NAP can utilize several different techniques for controlling network access. For organizations with managed network switches, 802.1X can be utilized to provide port-based access control at the network hardware layer. NAP also provides the ability to utilize IPsec-based enforcement, where secure networks are created through IPsec associations and are layered over physical networks. With IPsec-based enforcement, NAP controls access to the secure zone by dynamically creating and removing certificates used by the IPsec engine. Finally, NAP can provide DHCP-based enforcement. In this case, the DHCP server provides unhealthy clients with IP leases from restricted pools. These leases use separate DNS suffixes and IP routes to control which resources a restricted client can access.
The NAP server component is built on the next version of Windows Server, code-named "Longhorn," specifically into the new Network Policy Server (NPS), the greatly enhanced successor to Internet Authentication Services. For organizations utilizing 802.1X-based enforcement, the network hardware must support 802.1X authentication and dynamic VLAN capabilities (the NAP Partners site in the "NAP Resources" sidebar provides more detail about specific hardware vendors). For DHCP-based enforcement, a NAP-enabled DHCP service, such as the one available in Windows Server "Longhorn," is required. On the client, NAP support comes built-in to Windows Vista™. NAP support will also be available as an add-on to Windows® XP, along with a new 802.1X supplicant which will enable 802.1X enforcement on Windows XP.
In addition, NAP integrates into the Windows Security Center, as well as third-party health agents, to report health information. Because of this, NAP is able to make policy validation decisions based on any of the data exposed through the Security Center.
NAP is a highly capable enterprise-level policy-management solution, so it’s impossible to cover all the features and deployment strategies in a single article. Thus, this article is focused on deployments for small and medium-sized organizations where IT staff time is already spread thinly and where a NAP deployment can be streamlined to provide a rapid return on the investment required for deployment. Many of the lessons and general guidance, though, are equally applicable to any NAP design in any size organization. Note, however, that my example walkthrough is not designed to be a step-by-step setup guide, but rather a general overview of the major focus areas of a successful DHCP based NAP deployment. See the "NAP Resources" sidebar for a link to a more detailed setup guide.
Contoso’s Problem Set
To take a closer look at how NAP can address the unique needs of small and medium-sized organizations, let’s use Contoso, Inc. as an example. Contoso is a fictitious medium-sized organization with 250 computers in three main offices. It has a highly mobile workforce, with many users telecommuting or connecting back to the main office from remote customer locations. As a result, about half of its total computer population is made up of laptops and Tablet PCs. Like many organizations, Contoso has faced increasing security challenges as its workforce has become more mobile. Some users with mobile computers have picked up malware from customer sites or home offices and have brought infected computers on to the internal Contoso network.
Contoso has also struggled with ensuring that these remote computers are kept up-to-date. Often, users work from customer locations for long periods before returning to a Contoso office. In these situations, the machines they have are often months behind on security updates, which increases the overall risk to the rest of the machines on the Contoso network. Contoso needs a solution that can ensure that all machines connected to its network, whether remotely or locally, are secure and healthy.
How can NAP help Contoso achieve its goals? Recall the main pillars of NAP. Through policy validation, NAP can check the health of all machines connecting to Contoso’s network. Policy validation can determine whether a machine has timely antivirus signatures and whether it is fully patched with all security updates. When the NAP policy validation routines determine a machine is unhealthy, NAP can restrict network connectivity for the unhealthy hosts. This ensures that a machine that was used offsite and has contracted malware is unable to spread the problem to other parts of the network. NAP will restrict the unhealthy computer’s connectivity so it can access only the remediation resources defined by Contoso’s IT administrator. For example, the unhealthy computer would have access to the Contoso WSUS server and the server hosting antivirus signatures. Finally, NAP can ensure that after the machine becomes healthy, it will be kept in a continuously healthy state. In the example I’ve shown you here, if the unhealthy host was used by a telecommuter over VPN and the user turned off the host firewall, NAP would automatically remediate the problem. As soon as the firewall was disabled, the NAP infrastructure would quarantine the computer, re-enable the firewall, re-evaluate the health of the machine, and, after determining that it’s healthy, place the machine back on the unrestricted network. NAP’s four pillars directly address key security needs for Contoso’s dynamic and mobile computing environment.
NAP Design
For many small and medium-sized organizations, DHCP-based enforcement for NAP is the fastest and easiest implementation option. This is because DHCP enforcement requires no additional network changes and no additional services beyond DHCP and NPS. While IPsec and 802.1X enforcement options are more flexible, they also require additional changes in the network and new services to deploy. For lower complexity environments, using DHCP provides the major benefits of NAP at a much lower implementation cost and with less ongoing operational commitment.
In Contoso’s environment, a computer running Windows Server "Longhorn" is used as the core of the NAP deployment. Because NAP requires a Windows Server "Longhorn" NPS, it cannot be deployed on previous releases of Windows Server. DHCP-based enforcement for NAP also requires a Windows Server "Longhorn" DHCP server. To consolidate services, Contoso can deploy both NPS and DHCP on the same server; they coexist without issue. So, the basic NAP server infrastructure for Contoso is quite simple: a single computer with Windows Server "Longhorn" runs both the policy and enforcement components.
On the client-side, Contoso’s computers running Windows Vista already have the necessary capabilities to support NAP. The only client-side change required for the machines running Windows Vista is to enable the NAP functionality, which can be accomplished through Group Policy. For Contoso’s computers running Windows XP, a NAP client package must be installed separately. Computers running Windows XP that are domain-joined have, by default, the Windows Security Center functionality disabled. If the NAP policy uses status information from Security Center to evaluate computer health, the Security Center must be running for NAP to operate properly. So, for Contoso’s computers running Windows XP, the admins have turned the Security Center on through Group Policy. Beyond these changes, nothing else is required on the client side in order to support NAP.
Contoso NAP Deployment
After Contoso has made the required Group Policy changes discussed earlier, installing Windows Server "Longhorn" is the next step in the NAP deployment. All versions of Windows Server "Longhorn" include the required NAP components, so Contoso can use whatever edition best fits its needs. Once the installation is complete, the IT administrator will use the Server Manager tool to add new roles to the machine. For the DHCP-based enforcement that Contoso is using, the required roles are Network Access Services and DHCP Server. The Add Roles Wizard will assist the administrator in handling any dependencies and including any additional features that may be desired on the server. Once the roles are added, Contoso is ready to begin configuring NAP.
Contoso’s administrator will use the Server Manager tool to access the DHCP snap-in for the Microsoft Management Console (MMC) and add a new scope. Configuring the Windows Server "Longhorn" DHCP server will cause all existing DHCP services on the IP segments it services to be replaced. Once the scope has been created and populated with the right options based on Contoso’s network, NAP must be enabled on it. This is done on the Network Access Protection tab of the scope properties (see [B]Figure 2[/B]).
[IMG]http://i.technet.microsoft.com/cc162368.fig02_L%28en-us%29.gif[/IMG] Figure 2[B] Enabling NAP [/B](Click the image for a larger view)
NAP switches machines between either restricted or unrestricted network access within the same scope by using a new NAP user class scope option. This special set of scope options (including DNS servers, default DNS suffix, and so on) is used when leases are provided to unhealthy clients. For example, whereas healthy clients would be provided a default DNS suffix of "contoso.com", unhealthy clients are given a suffix of "restricted.contoso.com" as shown in [B]Figure 3[/B]. Once the DHCP scope options are configured, the Network Policy Server can be set up and rules created.
[IMG]http://i.technet.microsoft.com/cc162368.fig03_L%28en-us%29.gif[/IMG] Figure 3[B] Restricted access [/B](Click the image for a larger view)
The NPS policy is made up of four major components. System Health Validators (SHV) define what checks are performed to assess the health of a computer. Remediation Servers Groups contain the list of systems that unhealthy machines are allowed to access to become healthy (WSUS, for example). The System Health Validator Template component is used to define the actual health states. For example, Contoso could say a "Compliant" machine is one that passes the Windows Security SHV, but allows the client to fail another SHV check provided by its antivirus vendor. Finally, these components are combined into a set of Network Policies, which contain the logic that determines what happens to machines based on their health state.
System Health Validators are lists of items that the NAP agent checks and reports the status of to the NPS. A default NAP deployment includes the Windows SHV, which plugs into the Windows Security Center and allows NAP to check the status of all security components reported through the Security Center. This includes firewall, antivirus, automatic update, and antispyware components.
Recall that NAP is designed to be extensible and to allow third parties to create their own SHVs to provide more detailed checks of individual components (see [URL="http://microsoft.com/windowsserver2003/partners/nappartners.mspx"]microsoft.com/windowsserver2003/partners/nappartners.mspx[/URL] for more information). For example, the Windows Security SHV allows NAP to check whether or not antivirus is enabled and up-to-date. However, the Windows Security SHV cannot perform more detailed checks about the antivirus application, such as how frequently the machine is scanned or other application-specific options. The antivirus vendor, however, could create its own SHV that plugs into its application more deeply and exposes more application-specific checks than the default Windows SHV. This SHV would work in concert with the Windows SHV and any other SHVs that may exist; a NAP deployment may have many SHVs in use simultaneously (see [B]Figure 4[/B]).
[IMG]http://i.technet.microsoft.com/cc162368.fig04%28en-us%29.gif[/IMG] Figure 4[B] Windows Security SHV [/B]
Remediation Server Groups are used to specify what resources an unhealthy machine is able to access. These groups often include resources such as WSUS or Systems Management Server (SMS) servers, as well as antivirus update servers. It’s critical to include not only the servers themselves, but also the name resolution servers used by clients to find them. Because Contoso’s clients are configured via Group Policy to use the server called wsus.contoso.com for Automatic Updates, the Remediation Servers Group must include not only the IP address of the WSUS server, but also that of the DNS server that clients use to convert the fully qualified domain name (FQDN) into a numerical IP address. Without allowing access to these name resolution resources (which may be both DNS and WINS, depending on how clients are configured), clients will not be able to resolve the IP addresses of the remediation resources and, thus, will not be able to access them. [B]Figure 5[/B] shows the DNS and IP settings for the sample.
[IMG]http://i.technet.microsoft.com/cc162368.fig05_L%28en-us%29.gif[/IMG] Figure 5[B] DNS names and IP addresses [/B](Click the image for a larger view)
System Health Validator Templates are used to define what constitutes a healthy computer. Validator Templates take the results of SHV checks and states whether a machine is healthy or unhealthy based on whether they pass or fail one or more of these checks (see [B]Figure 6[/B]).
[IMG]http://i.technet.microsoft.com/cc162368.fig06_L%28en-us%29.gif[/IMG] Figure 6[B] Compliance checks [/B](Click the image for a larger view)
In the Contoso environment (as with many small and medium-sized deployments), there are only two states defined. A healthy computer is one that passes all SHV checks. A noncompliant machine is one that fails one or more of these checks. Organizations can choose to implement more complex logic if needed (for example, creating different compliance standards for users based on role, department, geography, and so on), but should be aware that doing so has the potential to make problem identification and troubleshooting more difficult and time-consuming.
All these components are brought together with Network Policies. Network Policies are defined by administrators and instruct the NPS how to treat computers based on their health state. These policies are evaluated from top to bottom (as displayed in the NPS UI) and processing stops once a policy rule is matched.
Again, simplicity is the goal for the Contoso network, so only a few policies are required. First is the Compliant-FullAccess policy. This policy states that machines that pass all SHV checks are granted unrestricted network access. Specifically, when a machine’s health is evaluated, and all checks pass, the NPS will instruct the DHCP server to offer the machine an IP lease with "normal" scope options. This Compliant-FullAccess policy should normally be listed first in the processing order, since most machines should be compliant when checked. Having this policy listed first reduces processing load and time on the NPS.
The next policy used is Noncompliant-Restricted. In the Contoso environment, any machine that fails one or more SHV checks (thereby matching the Noncompliant System Health Validation Template) corresponds to this policy. When this policy is matched, the NPS instructs the DHCP server to offer the client an IP lease with the special NAP "restricted" scope options. This allows the noncompliant computers to access only those resources defined in Contoso’s Remediation Servers Group.
The third policy used is for backwards compatibility. Recall that, by default, NAP support is available for Windows XP and later operating systems (though independent software vendors may develop NAP clients for older Windows versions and non-Windows operating systems). If Contoso has Windows 2000 still in production, it may create a rule (Downlevel-Full-Access in our example) that allows machines that are not NAP-aware to be granted normal access to the network (given default scope options by the DHCP server). This policy should be evaluated last and only needs to be created and enabled when downlevel machines require network access (see [B]Figure 7[/B]).
[IMG]http://i.technet.microsoft.com/cc162368.fig07_L%28en-us%29.gif[/IMG] Figure 7[B] Access settings for downlevel machines [/B](Click the image for a larger view)
What if Contoso has resources on its network that are not and will never be NAP-capable, such as printers or other hardware? Further, what if Contoso has machines that are NAP-capable but that it wishes to exempt from policy checks, either permanently or on a temporary basis? An easy way to exempt these machines is by MAC address. To provide these machines with a bypass around NAP checks, Contoso administrators can create a new policy (Exempt by MAC) that grants full network access. This policy uses a condition statement where the RADIUS client property of Calling Station ID matches the MAC address of those devices that require a NAP bypass. When a machine matches this policy statement, NPS will instruct DHCP to offer a lease with "normal" scope options. This policy should be listed first in the evaluation order to reduce overall processing time and load on the NPS. Machines matching this policy do not need any SHV evaluation, so there’s no purpose in devoting cycles on the NPS to checking them (see [B]Figure 8[/B]).
[IMG]http://i.technet.microsoft.com/cc162368.fig08_L%28en-us%29.gif[/IMG] Figure 8[B] Ignoring certain machines [/B](Click the image for a larger view)
When combined, these policies will help ensure that Contoso’s NPS quickly and accurately evaluates machines connecting to the network. They also provide for exemptions when needed for downlevel computers and devices or for times when a temporary bypass is required for NAP-capable devices.
Conclusion
NAP encompasses a broad set of technologies and, particularly in more complex scenarios, requires thorough planning and testing. While I focused on a less complex scenario, the NAP Web site includes more detailed guidance for deployments of all sizes. The Web site also includes planning assistance for 802.1X and IPsec-based enforcement technologies, which are often a better fit than DHCP-based enforcement for enterprises.
NAP provides a capable and extensible platform for evaluating the health of computers connecting to a network. For small and medium-sized organizations, DHCP-based enforcement can provide many benefits with low implementation and management costs. NAP is a key benefit of Windows Server "Longhorn" and can help your organization improve security and compliance.
[/LEFT]
