NAC management can be a headachePolicy servers need to cross security, network and desktop boundariesNAC deployments present special problems in management because they cross boundaries between groups responsible for security, network configuration and desktop configuration. Any NAC management platform must have the ability to integrate into all three areas. We found that Cisco’s ACS is definitely clear on the division of labor between security and desktop configuration. The ACS server punts all decision-making processes regarding the status of the security of an end-point to external posture checking tools. In return, the tools send back to ACS a simple status token, such as “Compliant”, that can be included in policy decision making. This separation of control initially seems crude, but is actually a good design. After working with patch management tools, which are complex in their own right, it’s clear that having a simple and clear-cut interface between the posture-assessment side of the organization and the access control side is the only workable option. Cisco has also been very open about the protocols and interfaces needed for third parties to integrate audit and end-point health information into ACS. This clear demarcation has given the CNAC framework the upper hand over TCG/TNC both in terms of the number of third parties that participate with the respective NAC schemes, and in the breadth of the options supported. But the TCG/TNC is not devoid of workable management options. Juniper's UAC appliance offers two ways to go: the defined “hands off” approach that clearly separates access control from posture assessment, or a more integrated one where posture assessment and access control are controlled from the same interface. This second option is a legacy of the UAC appliance’s roots, as an SSL VPN policy engine, where these two functions are traditionally closely tied. It’s nice to have a choice of the two configurations, although we suspect that most large deployments will go for a fairly strong separation of duties, because expertise and responsibility for network security and desktop security is generally separate. We’ve already discussed our dissatisfaction with the policy configuration tool set in Cisco Secure ACS in the enforcement section of this test report. Because ACS is designed to operate as a RADIUS server, not as an active part of network security, it is also missing monitoring and status tools that would have been helpful for both debugging and light network monitoring tasks. Cisco is aware of the bottleneck ACS causes and says it is working on plans to remedy it. While Juniper’s UAC appliance has much better policy configuration, status and monitoring tools, Juniper has also tackled the harder problem of integrating the additional features of its RADIUS server into the management interface. We’ll be very interested to see how well Juniper does in its next version of UAC (Version 2.1 expected to ship in the fall) at exposing the features that are needed for a comprehensive deployment with a single appliance. Lessons learned about NAC management One of the most important parts of NAC management is being able to draw the line between network security configuration and end-point posture assessment. Both Cisco ACS and the UAC appliance we used in the TCG/TNC framework do a very good job of making a demarcation between the two functions. However, the number of options for third-party additions to CNAC far outweighs the number of announced products in the TCG/TNC camp. If CNAC has an Achilles' heel, though, it is the security management functions within Cisco ACS. Juniper’s policy management is not only more usable, but offers the security manager greater options to manage access and a finer-grained set of controls to handle diverse user communities. What can NAC do for you now? Part 1 of 5 NAC authentication with XP clients is a snap Part 2 of 5 NAC enforcement tools fall short Part 3 of 5 Cisco, TCG deliver on basic end point security Part 4 of 5
|