2. Considerations for NAP Enforcement
When
deliberating between the types of NAP enforcement methods to institute
within your network, you need to know the strengths and weaknesses of
each method. How does each method deal with non-NAP capable computers?
What is required in each method to administer unmanaged computers
(computers not part of the internal AD DS)? In planning a NAP solution,
consider that all the NAP enforcement methods have one or more of the
following aspects:
NAP does not stop attackers.
NAP, to some degree, implies a trust with the NAP client.
NAP does not remove harmful software from connecting computers.
NAP should be treated as an assurance feature.
NAP cannot stop an attacker. A malicious user,
whether an employee, guest, or outside user, might provide all the
necessary compliance for access to your network but still launch an
attack when inside your network.
NAP indirectly assumes that the client has not
provided false settings, configurations, or modifications to installed
software to attain a false positive of compliance. Remember, you are
essentially asking the computer owner whether everything on the computer
is fine and he or she has not falsified, concealed, or knowingly
allowed anyone to configure or install software on this computer. Does
this sound similar to the security warnings you might hear a dozen times
an hour at any airport?
NAP provides a health statement based on the
appearance of sound security configurations, settings, and installed
software. It does not scan the computer for malicious software but,
rather, assumes that the verified health state of a computer means that
another subsystem or configuration on an installed security software
application performs that feature.
Finally, NAP is an assurance feature. You are
determining that the computers connecting to your network and
communicating with the secure internal environment have applied the
necessary security precautions to prevent an outbreak. Remember, if
someone with malicious intent were to circumvent your NAP solution, the
assurance that all other computers have complied with your NAP policies
will help deter an attacker from damaging your environment or possibly
acquiring sensitive information. As an enterprise administrator, realize
your NAP solution was not meant to stop an employee or would-be
attacker intent on stealing information; that is not the role a NAP
infrastructure is meant to play.
3. Planning NAP IPsec Enforcement
When looking for the strongest enforcement method
to apply within your network, NAP IPsec enforcement provides the most
robust and tamper-resistant solution compared to all other NAP
enforcement methods. IPsec enforcement has these advantages:
Tightly controlled enforcement that not even the local administrator is capable of bypassing
Upgrades to network infrastructure devices such as hubs, switches, and routers to support NAP are unnecessary
Granular control to network access
Easier avenue to end-to-end encryption of sensitive communications
Even by manipulating settings and the
configuration of the local computer, administrators cannot bypass health
certificates issued by the Health Registration Authority (HRA). Because
all other computers are also protected by the same means, there is no
way to subvert this requirement. Introducing new switches or other
network devices provides no means around the required legitimate health
certificate to communicate with hosts expecting the certificate during
the IPsec negotiation.
IPsec works at layer 3 and uses a logical
connection that is above the physical layers in the network; bypassing
it would require modification or extensive reconfiguration of physical
hardware.
IPsec allows an administrator to control
communication pathways end-to-end. An administrator can create hardened
IPsec policies that dictate source and destination IP addresses along
with source and destination ports that are allowed for communication and
must be encrypted. IPsec enforcement can also control access to the
network stringently but use a general approach to managing
communication. If you use IPsec enforcement to tightly control access to
the secure network, you have already taken a large leap toward
encrypting sensitive traffic within your environment.
The disadvantages of an IPsec enforcement solution deserve serious consideration as well:
It requires creation and maintenance of network zones for the logical separation of network communication.
It
requires the establishment of an internal PKI. If one already exists,
it might need a minor overhaul if its creator did not anticipate the
additional load that an IPsec enforcement solution will incur.
It
requires another series of servers, which must be managed for
configuration, load balancing, and high availability. Loss of the
ability to issue health certificates would mean a catastrophic loss of
communication within the environment.
When weighing the advantages and disadvantages of
a NAP solution using IPsec enforcement, an organization has to consider
the increased security that would be provided. IPsec enforcement
provides not only the direct benefits offered by a NAP solution but also
the increased benefits of data confidentiality when communicating
throughout the network environment.
Designing NAP IPsec Enforcement
When
planning NAP IPsec enforcement for any organization, you need to
establish the security zones first and determine which services to offer
in the boundary network. The three security zones for an IPsec solution
are:
Restricted network
Boundary network
Secure network
Restricted Network
The restricted network, also referred to as the
remediation network, is not the same as the perimeter network. The
restricted network is a select network where noncompliant computers have
limited access to services to perform remediation. Computers placed
into the restricted network consist of either noncompliant NAP clients
or non-NAP-capable clients. For IPsec enforcement, the restricted
network includes only these devices.
Computers in the restricted network can
initiate communication with computers in the restricted and boundary
networks. Neither communication is protected by IPsec. Computers in all
three networks, however, can initiate communication with computers in
the restricted network. This communication is not protected by IPsec
either.
Non-NAP-compliant computers have already
attempted communication with an HRA and have received a System Statement
of Health Response (SSoHR) that contains the Statement of Health
Responses (SoHRs) stating which system health agents (SHAs) are
noncompliant. The non-NAP-compliant computer in the restricted network
will initiate contact with servers in the boundary network to perform
remediation. After remediation has been performed, the non-NAP-compliant
computer will try again to attain a health certificate. The computer
will go through the process of accumulating, across all SHAs, a
Statement of Health (SoH) and submit a System Statement of Health (SSoH)
to an HRA. The HRA, using System Health Validators (SHVs), will process
all SoHs on the SSoH to formulate its SSoHR.
Upon receiving the SSoHR that shows the NAP
client as compliant, the HRA also issues a health certificate so that
the NAP client is now part of the secure network and initiates
IPsec-authenticated communication with computers in either the boundary
network or the secure network.
Non-NAP-capable computers are those of guests
and other unsupported operating systems such as any version of Windows
earlier than Windows XP SP3, Apple Macintosh computers, and UNIX
computers. A guest computer can be NAP capable but, because it is
unmanaged (not part of AD DS), will more than likely be treated like a
non-NAP-capable computer unless network policies dictate otherwise.
Boundary Network
The boundary network contains computers
responsible for remediation as well as for the HRAs, support services
such as DNS, AD DS, and DHCP servers, WSUS and possibly, the NAP CAs.
Because the boundary network requires communication from computers
residing in the restricted and secure networks, IPsec policies should
allow for IPsec-authenticated traffic as well as for unauthenticated
traffic. Computers in the boundary network should be managed computers.
This enables them to receive their IPsec policies and changes to those
policies through Group Policy.
Boundary servers, when communicating with
computers in the restricted network, allow unauthenticated communication
because computers in the restricted network do not contain the
necessary health certificates. When boundary servers communicate with
servers in the restricted network, IPsec-authenticated traffic is
required.
There is a twist to this last statement. The
boundary computers themselves are the ones that offer the update
services, have the necessary configuration for compliance, and are part
of the NAP components. To ensure that they are capable of initiating
IPsec-authenticated communication, they also require a health
certificate. To provide these computers with a health certificate,
create an IPsec NAP exemption group whose membership includes all the
computers of the boundary network. Configure a Group Policy setting that
sets the NAP IPsec exemption group for certificate autoenrollment to
acquire the necessary health certificate. Because the computers of the
exemption group need to hold onto this certificate for the period of
time they are performing their services, ensure that the template used
to issue the certificate has been set for an extended period of time.
Computers from the restricted network as well
as the computers in the boundary network need authentication services.
Domain controllers located in the boundary network should be RODCs.
Secure Network
The secure network includes all computers that
have passed health validation and have acquired a health certificate.
The remaining portion of the NAP components related to IPsec enforcement
also resides here. These components consist of the following:
Computers within this network should be managed
computers (part of AD DS). This enables them to acquire their IPsec
policies and any configuration changes to your NAP environment through
Group Policy.
Scaling NAP IPsec Enforcement for Small Environments
When deploying components for NAP IPsec
enforcement, you have the opportunity to decide which components can be
installed together. In smaller environments, it might be appropriate to
consolidate several services on one computer. The issue becomes deciding
which services to install together.
The
HRA must be able to support unprotected communication from NAP clients,
and you should, therefore, install the HRA in the boundary network.
Because the load on the HRA in a small environment might not be that
heavy, you might decide to install it on a computer that has one or more
of the following services other computers in the boundary network also
need:
If your environment is expected to grow, it
would be wise to move some of these components to another server. You
can then assume that the server installed with the HRA would be deployed
in the boundary network, and another computer with the remaining
services would be deployed in the secure network.
Important:Splitting the HRA and the NAP Health Policy Server role
If you split the HRA and the NAP Health Policy
Server role to two computers, you still need to install the NPS role on
the HRA computer. Then configure a RADIUS server group and a connection
request policy for the local NPS service to forward requests to the
remote RADIUS server group in the secure network.
Administrators of extremely small sites of 15 or
fewer computers might consider employing ISA Server 2006. ISA Server
can create a site-to-site VPN link to the main office boundary network.
The connection from the VPN server in the boundary network can be
treated like any other local connection requiring IPsec enforcement to
obtain a certificate initially. After a computer at the remote office
has obtained a health certificate, IPsec rules can be managed granularly
to ensure that the branch office computer is able to communicate only
with the necessary services at the remote office, through the
site-to-site VPN, and in the boundary network for remediation and
renewal of certificates. ISA Server would require a certificate as well
and should probably be included in the IPsec exemption group. Ensure
that a computer certificate is issued to the computer running ISA Server
for an extended period of time.
Scaling NAP IPsec Enforcement for Larger Environments
For larger environments, several components
require a thorough design review to ensure high availability and load
balancing of specific components. You can begin by deciding which of the
following services will be installed individually on at least two or
more computers in the boundary network at the corporate office:
By
providing fault tolerance for the HRA, the RODCs, and the NAP CA, you
are ensuring a healthy environment. Remember that by employing IPsec
enforcement, you are required to have these services running constantly.
If one or more of these services become unavailable, health
certificates will expire, and communication within the network will
fail. Ensuring the ability of NAP clients to acquire health certificates
is essential because all communication depends upon the necessity of
each computer to present a valid health certificate when attempting to
communicate with another computer.
In the secure network, deploy at least two NAP
health policy servers. Configure the HRA computers as RADIUS clients of
the NAP health policy servers. To ensure proper load balancing when
configuring the remote RADIUS server group of the NPS service on the HRA
computers, use the same priority and weight settings for all members of
the RADIUS server group on each of the HRA computers.
For deployments at the branch offices, consider
using the deployment models discussed previously for a small company.
The services offered at the branch offices would model the same
considerations given to a smaller company with a single site.
PKI Support for IPsec Enforcement
IPsec enforcement use of health certificates
requires you, as the enterprise administrator, to reexamine the role PKI
currently has within your environment. If a PKI does not exist, you
need to deploy one. If one already exists, consider the additional load
balancing and management that will be needed.
Smaller environments that already have a PKI
probably require only the creation of a subordinate CA for NAP. This CA
can be deployed in the boundary networks on the HRA to conserve server
resources.
Larger environments require more planning
because you now need to consider additional aspects of PKI when employed
for use with NAP IPsec enforcement. The load on the CA issuing health
certificates will be directly proportional to:
The number of NAP clients is not something that
you can truly control because deploying a NAP solution would entail
using it pervasively throughout the environment.
The lifetime of the health certificate is
something you can administer, and it has a direct influence over the
load on your NAP CAs. Microsoft recommends for best practices to keep
the lifetime at a minimum, preferably four hours. Reducing this time
increases the load on the NAP CAs for renewals. Increasing the time,
although reducing the load on the NAP CAs, also increases the likelihood
that a computer can be out of compliance for a longer period due to
changes in the health requirement policy.
Structure of the PKI
For
most environments, adding an additional subordinate CA to issue health
certificates for NAP is sufficient. Microsoft recommends that, in large
environments, administrators create an entirely new PKI for NAP. You
need to install a new root CA on a server within the secure environment
and secure its private key with a hardware security module (HSM). Create
subordinate CAs for NAP to issue the health certificates. These can be
deployed in the boundary network and given the same security
consideration as the RODCs deployed there. This would mean the removal
of all unnecessary services and provide a limited attack surface.
Securing its private key is not as critical as securing the root CA
because certificates issued by it will have a limited lifetime.
You do not need to worry about issuing timely
certificate revocation lists (CRLs) for this portion of your PKI because
the certificates will expire long before the CRLs are published. In
addition, an OCSP responder service is also unnecessary due to the
limited lifetime of your health certificates.
Configuring Additional NAP Components on Clients
System health agents from third-party members
need to be installed on all NAP clients. A variety of software
distribution methods is available to an administrator. You can use any
one of the following not only for IPsec enforcement but also for VPN
enforcement, 802.1x enforcement, and DHCP enforcement:
Software deployment or logon scripts through Group Policy.
Desktop management software such as Microsoft System Center Configuration Manager
2007.
Manual installation for unmanaged computers.
Shares on remediation servers. Configure the troubleshooting URLs to instruct the user to install the missing SHAs.
Note: Troubleshooting URLs
Troubleshooting URLs are configured as part of
the remediation experience in case clients that fail compliance do not
have the Configuration Manager client installed. On one of the
remediation servers installed in the restricted network, configure a Web
URL to help instruct remediation clients on the location of software
and options to choose to help acquire a successful health validation.
Configuring NAP Health Policy Servers
The NPS server running the NAP health
policy server can be configured with additional third-party SHVs.
Installation instructions for the third-party SHVs are provided by the
third-party vendor. The SHVs must be installed on all NAP health policy
servers participating in the NAP solution for IPsec as well as for VPN
enforcement, 802.1x enforcement, and DHCP enforcement. Windows Server 2008 provides the
default Windows Security Health Validator SHV that provides security
settings for the Windows Security Center on Windows NAP clients.