How ‘bout some NAP perspective from the field
Hello NAP Bloggers! My name is Mark Foust, a Windows Server Networking Technical Specialist working down in Tampa Florida (USA). I wanted to share a bit of my perspective on the world of { NAP } .
7 things you may not have considered about NAP:
1. NAP enforces minimum consistency levels, not maximum security
NAP should be looked at as a mechanism to enforce the minimum machine / device requirements, not maximum levels. NAP is not meant as a lockdown mechanism, rather an enabler of IT by automating minimum security levels during connection (as well as on-going compliance). NAP is not a holistic security template, nor a point of control for managing the patch levels for every device. NAP is enforced at entry points in your infrastructure DHCP, VPN, IPSEC and 802.1X entry points. As with every technology there will be some devices that need exceptions….see #6
2. NAP doesn’t care much about your user login
Assuming you are in the same forest/domain as your workstation---a somewhat safe assumption. NAP is typically device / machine based and not user based; an important distinction as it is the hardware device object, in Active Directory, that requires the Group Policy objects to be applied, not users. Note that Group Policy is applied in a L>S>D>OU fashion---Local, Site, Domain and OU. In that order and last writer wins any conflicts.
The exception to this is 802.1X + NAP – you are able to do machine AND user authentication at the hardware layer and can create user based NAP policies. Also notable is that NAP functions in a “workgroup” and doesn’t require a domain at all!
3. NAP’s greatest initial advantage is REPORTING
You may not have considered this, but enforcing something as simple as a single AV engine or update may have unintended consequences on your network. For example, what if you found out that 17% of your users were not running standard up-to-date AV signatures? NAP would/could lock out 17% of your company for failing to comply. You’d probably find a lot of lab machines, vendor laptops (guests), virtual machines and line of business (LOB) devices that may have been granted such AV exceptions in the past. Be careful. You will want to initially only report on each policy violation. This is going to give you information you’ve long needed to report on LOB compliancy, vendors and a cadre of other statistical variances that you have probably not considered.
4. NAP should not be viewed as a forklift type of upgrade or enforcement mechanism.
You must exercise caution when implementing restrictive policies on an enterprise. Reasonable preparation before enforcement should include testing, piloting, communication to your end-user community, and training of help desk to assist in remediation of issues that occur. Also, a good back-out plan should be in place should there be too restrictive a setting enforce or errors. Proper lab testing and production pilot testing involving sample groups is always a best practice. Allow for time to do administrative knowledge transfer---should the main NAP administrators be away for a couple days. In other words, don’t wait for an implementation issue to bite you before you plan.
5. NAP will highlight your weak operational issues.
This is a good thing. If you’ve not spent much time considering how you remediate the automation types of issues that NAP will remediate, you are going to get a chance. If you’ve felt like you’ve not had much executive support to enforce patching / update minimums in the past, NAP will help push that conversation. The key word here is automation to remediate patching / updating types of issues. This will help you enforce security maturity across your enterprise. With NAP, it becomes harder to exclude the guilty client workstations / device---a very different way to govern for you. Every enterprise has silos and fiefdoms. NAP helps bridge this gap with a constant, consistent, enterprise-wide, minimum enforcement mechanism. You are not the bad guy anymore. When someone comes to you mad that you patched their machine, you are able to defer patching enforcement discussions to a higher power---NAP in the cloud. :->
6. You will need to make some exceptions for NAP
NAP provides a mechanism to support your administrative needs to ensure everyone is at least on a minimum patch / security level. This may not play well with certain applications that only support a standard like n-2 or an old legacy Server 2003 SP1 machine. Realize that this constant enforcement of updating does not replace your testing needs around application compatibility testing. You may find that NAP will cause you to mature your OU structure. Application Servers may get their own OU now---which is a best practice for Active Directory Security anyway….to break your servers down into roles and possibly applications as sub-sets of those roles, then apply more/less restrictive policies on those servers.
7. NAP will become a foundational part of your infrastructure
NAP is not just a simplistic feature; it is a service running on your OS [for Windows Server 2008, Vista RTM/SP1, and XP SP3]. This service will bring stability, security, maturity through automation to your enterprise. Your homework: Figure out why this is so important at a high level.
NAP the world baby!
- Mark