Jeff was very kind to invite me to the Q&A session to end his TechEd talk today (http://blogs.technet.com/nap/archive/2008/06/09/nap-ing-teched-orlando-2008.aspx), and to let me take a question about locking down NAP clients. Specifically, the NAP health model is based on receiving information from clients. Can’t it be spoofed?

In short, yes. But it’s important to understand two things:

Number one, NAP is about compliance. (A) what are the network policies? And (B), what’s the reality? NAP helps customers answer the second question. In fact, many NAP deployments today are finding that quarantine enforcement isn’t even necessary. Simply by creating awareness, among both administrators and users, about which machines are violating which network policies, the compliance bar is quickly being raised.

Number two, NAP, like many client security features, is dependent upon trustworthy client administrators from an enforcement perspective. That is, if a user can muck with the system binaries, then the NAP Statement of Health data can be spoofed. Ditto, with injecting network traffic, depending on the scenario. If your users are local administrators on their workstations, then you are implicitly trusting them to behave themselves.

Of course, life is much more complicated than that in practice – there are a number of situations in which not providing users with local admin access is just too difficult to support. It’s debatable whether that’s going to change any time in the near future.

An alternative solution to the above problem, which also may or may not be available in the near future, is a supportable TPM key hierarchy and deployment story. In that case, the integrity of the system, from BIOS to user-mode start-up, can be cryptographically verified. In that beautiful utopian world, spoofing data from a NAP client will in theory require compromising a tamper-resistant chip on the motherboard.

No Comments »