NAP and FCS
For some more technical depth on the Solution Accelerators Forefront Integration Kit for Network Access Protection (NAP), I'd like to introduce Dan Griffin. The following blog post was written by him.
The purpose of this blog post is twofold. First, to briefly answer the following question: how does NAP (see the acronym reference at the bottom) implement sandboxing for non-compliant clients – in other words, how are unhealthy computers are kept separate from the healthy computers?
The second purpose is to answer this question: what does this have to do with the new Forefront/NAP integration kit from Solution Accelerators?
However, before I get to either point, or to the example in the next section, I need to provide some NAP guidance.
Namely, I’ve been asked to clarify that there are in fact five different enforcement methods supported by NAP: 802.1x, DHCP, IPsec, Terminal Server Gateway, and VPN. The example I’ll discuss is DHCP, but you should keep in mind that it suffers from some security shortcomings.
First, DHCP enforcement puts non-compliant client in a restricted network. However, that really only consists of a simple set of default routes, plus the lack of a default gateway. Thus, sophisticated users with administrative access may be able to bypass the restriction and route traffic into the compliant network.
Second, because of inherent limitations in the public DHCP standard, it doesn’t offer server authentication or message integrity. That is, someone with access to your LAN could maliciously modify DHCP traffic without the client or server being able to detect it.
Neither limitation exists in a NAP deployment over certificate-based IPsec, for example. The IPsec client and server are mutually authenticated and the network traffic is protected by encryption and cryptographic checksums.
However, for the purpose of learning about NAP, and for doing a proof-of-concept deployment in a lab, DHCP is tough to beat. It’s less complex to setup than the other scenarios and can thus be done more quickly. For instructions on doing so, see the step-by-step guide here.
That’s it for the introductory stuff – onward to the example.
FCS/NAP Architecture
Suppose, despite the caveats above, that the NAP enforcement scenario is DHCP. Client computers won't be given full access to the corporate network unless they are deemed compliant by NAP.
The first step is that the NAP agent on the client sends a Statement of Health (SoH) along with the request to the DHCP server. In the following diagram, the client could be either of the laptop-shaped images on the left-hand side. The server in this picture, at the bottom of the larger oval, is playing two roles: DHCP server as well as Network Policy Server, or NPS.
The DHCP server receives the DHCP request from the client, extracts the SoH, and relays it to the NPS to be evaluated. In this example, that's just a question of one service talking to another service on the same server.
If the SoH is considered to be compliant, then the DHCP server responds with an IP lease on the main, NAP-compliant, corporate network. If the SoH is not compliant, then the DHCP server grants the client an IP lease on the restricted, non-compliant, sandbox network.
So how does the new FCS/NAP solution play into this? It's a question of what information is included in the SoH, and how it's evaluated by the NPS. FCS/NAP consists of two plug-ins: a System Health Agent (SHA) for the client and a System Health Validator (SHV) for the server (NPS).
Data Flow
The client SHA adds Forefront-related information to the SoH to be evaluated by the SHV. Think of the SoH as a list of answers to preset questions. For example, one item is an answer to the question “Is the Forefront client currently running?” (That’s determined by the data path represented by arrow #2 in the following diagram.) Another is an answer to the question “Are the client’s virus signatures are up to date?” (See arrows #1 and #3.)
When the FCS/NAP SHV receives that SoH (arrow #5), it evaluates each of the answers against the health policy configured by the administrator. For example, if the answer to the question about whether Forefront is running is “No,” then the SHV checks whether the current policy indicates that Forefront must be running on healthy clients.
After evaluating each answer in the SoH in that way, there are two possible states the SHV can report to the NPS:
1. The client is healthy/compliant, or
2. The client is un-healthy/non-compliant.
In the latter case, for each non-compliant policy item, the SHV provides a message to explain to the user the reason, or reasons, why the machine is non-compliant. For example, “The Forefront client isn’t running,” and “The virus signatures are out of date,” etc. These messages are visible via built-in tools such as napstat.exe and netsh.exe.
Additional Configuration Considerations
There are a few NAP configuration scenarios that aren’t distinguished by these diagrams.
The first is NAP in “reporting” mode. In reporting mode, NAP doesn’t actually quarantine non-compliant clients; it simply reports on their health. This is a good configuration for customers who are evaluating or piloting NAP. Reporting mode doesn’t affect the SHV; it still works as described above.
The second scenario is NAP in enforcement mode. Non-compliant clients get quarantined.
Regardless of whether NAP is doing enforcement, there’s also the option of auto-remediation. How does this affect how the SHV behaves?
Without auto-remediation enabled, the SHV again behaves as described above. That is, each aspect of non-compliance is addressed with a string explaining what’s wrong.
However, with auto-remediation enabled, the SHV must place different information into the SoH response when the client is non-compliant. The auto-remediation response information consists of two things:
1. Different strings are used to distinguish between the scenarios in which the user is expected to take corrective action manually (“instructive”), versus the scenarios in which corrective action will be taken automatically by the SHA (“informative”). The latter is what auto-remediation is all about.
2. The SoH response must also include programmatic instructions from the SHV to the SHA about what specific auto-remediation actions to take. For example, if one of the required Forefront services isn’t running, and policy requires that it must be running, then the SHV will set the bit in the SoH bitmask instructing the SHA to attempt to automatically start the service.
Acronym Reference
· DHCP = Dynamic Host Configuration Protocol
· FCS = Forefront Client Security
· NAP = Network Access Protection
· NPS = Network Policy Server (the NAP server)
· SHA = System Health Agent (client-side NAP plug-in)
· SHV = System Health Validator (server-side NAP plug-in)
· SoH = Statement of Health (sent by the client)
More Information
For more information about FCS/NAP, please see:
· My blog
· The Solution Accelerators Security & Compliance blog
· The Forefront blog
· The NAP blog
Bio
Dan Griffin is a software security consultant in Seattle, WA. He previously spent seven years at Microsoft on the Windows Security development team. Dan can be contacted at www.jwsecure.com.
Disclaimer
This posting is provided "AS IS" with no warranties, and confers no rights.