No 802.1x ≠ No NAC

[#1]

"I want to deploy NAC in my network, but there are older components in my wired/wireless infrastructure that do not support 802.1x, so I can't deploy NAC yet, right?"  As a PLM for a NAC product, I hear this question constantly.  True, 802.1x is the most visible and prevalent type of NAC enforcement, but it is not the only type of enforcement provided with available NAC architectures.  In fact, depending on your security and access control needs, and your existing network architecture, one of the other options might actually be a better choice for your deployment.  Let's take a look at some of the available methods of enforcement:

• 802.1x Enforcement - This is supported by most of the primary NAC solutions on the market today.  This provides ultimate control in that an end user is unable to pass a single packet until they have been authenticated and their machine has been checked for the appropriate patches, endpoint security applications, etc.  One downside, however, is that 802.1x must be enabled on every switch and wireless access point in your network.  The first switch port, for example, that is not 802.1x enabled represents a potential security hole in your NAC solution. 
• Client Enforcement - In this model, a software agent running on the endpoint performs the enforcement.  When the user logs on to the network, the software-based agent contacts the NAC system to do the authentication, endpoint integrity scans, and apply the appropriate access control rules to the user's session. 
• DHCP Enforcement - With DHCP enforcement, the DHCP protocol is used to assign differing network configurations to devices connecting to the network based on user authentication and endpoint integrity.  One of the traditional downsides of DHCP enforcement has been from a security perspective, with spoofed and/or static IP addresses being an easy way to bypass these types of access control mechanisms
• Inline Appliance Enforcement - This approach leverages an appliance through which all end user traffic passes in order to perform access control.  A positive attribute of such a scheme is that it does not require any changes to the existing network configuration, nor does it require hardware upgrades.  In addition, many of the solutions out there enable a much more granular set of policy types that can be enforced versus other types of enforcement.  A downside, however, is that from a deployment perspective, a large enterprise network might potentially need to deploy a large number of these across their network in order to contain traffic sufficiently.  Some such enforcement models use existing security devices such as firewalls and IPS devices - appliances that might already be deployed in your network, minimizing even further the need to deploy additional network/security gear.

In actuality, most NAC solutions on the market today will provide more than one of these options, for additional flexibility.  The key point is that 802.1x is not the only approach to NAC out there.  For example, if your primary goal when deploying NAC is to restrict access to key financial applications and data stored in your primary data centers, 802.1x might not be the best alternative.  You might instead look towards an inline appliance solution, where the appliances are deployed in front of the data center.  When a Finance user needs to access that information, they authenticate to NAC.  This is a solution that is faster to deploy than an enterprise-wide 802.1x solution, but still meets the needs for this specific deployment. 

Remember: always start with your organization's security needs and then seek out the appropriate solution rather than the other way around.  You might miss more suitable solutions if you jump on the technologies presented to you before determining your true needs.