United States-English

Archie Reed's Secure Observations Blog

NAC (Network Access Control) - Some Best Practices #1

Published 26 February 2008, 04:09 PM

A few thoughts (not comprehensive) as you review the NAC capabilities available today, and consider preparing for the changes and additions to NAC requirements going forward:

  • Standards
    • Choosing one single standard today is a challenge given the core variants - NAP, CNAC and TNC. Add to that efforts in the IETF, Open Group, and others, and the need for a framework to align and match your business needs to your network architecture, ensure that your approach can do so.
    • As of today (early 08) the standards are not entirely interoperable outside of custom integrations, and therefore, choosing the approach to meets a majority of your needs is the key direction to take. Think the 80/20 rule for now.
  • Vendor experience and stability
    • There are a multitude of NAC vendors out there. Many smaller players align with the TCG TNC model and then integrate with CNAC and/or Microsoft NAP. However, the key consideration is whether the vendor will be in business in the long term. Validation from a larger partner is good, but make sure you understand what has been implemented before accepting the delivery.
    • For comprehensive integration of NAC, you must incorporate your Governance requirements into the definition, delivery and ongoing assessment of your NAC. So, implementation experience is important, but consider the need to work from business drivers down to actual NAC policy and network ACL and whether the vendor alone can mediate between all those layers in your environment.
  • Phased deployment is critical
    • Start slow – attempting to implement NAC using a big bang approach will likely result in end-user discontent and increased work for the help desk.
    • Implement a non-enforcement mode as early as possible – before implementing a NAC solution it is hard to ascertain what the impact will be. If the chosen NAC solution allows for a reporting mode only, implement that first and analyze the data you receive. This data will assist the organization in developing the enforcement policies and know up front where the pain points will be.
    • Secure your open areas as soon as possible - Attack low hanging fruit first – if the chosen solution allows you to address a certain “limited” part of the network first, start there. For example, if you can begin by implementing NAC on VPN concentrators first you will impact a subset of the total population as opposed to the whole. Also you could start with just a single concentrator as opposed to all of them assuming you can control which users hit that concentrator. Instead, you could implement NAC just on a subset of 802.1X network access points; maybe ones the organization views as high risk.
    • Undertake an asset inventory as soon as possible – very few environments have a single vendor solution, and interoperability is not guaranteed.
    • Assess the enforcement points before starting deployment – if the chosen NAC solution takes advantage of hardware based access points (i.e. wired/wireless switches) ensure that a) they support 802.1X and b) have the correct firmware/patches/upgrades/OS. As an example, each model may or may not support enforcement, each may require an upgrade or a unique set of patches, and each may have completely different configuration commands.

As a set of best practices, HP considers these as the starting point.

look for future posts on more best practices...

Posted By ArchieReed | No Comments | Trackbacks | Permalink


Comments

No Comments

Leave a Comment

(required)  
(optional)
(required)  


Type the digits above:
Information disclosed in this community becomes public. Exercise caution when deciding to disclose your personal information. HP reserves the right, but is not obligated to, edit or remove your comment if it contains personally identifiable information or other content HP deems unacceptable.  Opinions expressed are your personal opinions or those of the original authors, and not of HP. Please see HP's web Terms of Use for more details.