We’re currently working on an update to the GTP document “Architectural Alternatives for Enforcing Network Access Control Requirements” (Doc# G00227091). As part of this process, we’ve spoken with vendors, vendor references, and clients about what they’re doing with NAC, what sort of technical and social challenges they may be encountering, and even what they view as qualifying as “NAC.” Overall, it’s been a very interesting project, even though I’m not much of a netsec guy these days.
One of the challenges on this topic is defining what NAC actually is. As best as I can tell, what vendors call “NAC” can be grouped as follows:
- NAC (traditional & BYOD-oriented) – Actually focused on controlling network access, including use of 802.1x and certificate-based authentication. Guest networking also generally falls under this category today, as does the ability to manage network access without supplicants or agents of any sort (particularly prevalent in healthcare, manufacturing, and other industries with myriad legacy equipement).
- Endpoint posture and compliance assessment – Running an scan and/or agent on an endpoint to check for patches, AV, other security tools and configs, etc. There seems to be considerable focus on using these tools for endpoint compliance assessment in support of various audit requirements.
- Continuous monitoring and incident investigations – Networking monitoring, especially around devices in specific places, possibly anomaly detection of sorts, and then pulling profile data later as part of a help desk inquiry or incident investigation (“Was this device compliant?” or “Where did that endpoint device come from?”).
- Endpoint discovery & inventory – In some ways, NAC seems to be to network device inventory what DLP is to information/data inventory. Most products come with some form of network device inventory capability today, which can be leveraged to varying extents.
- Device & config mgmt (incl. QOS and SDN, to a degree) – At least one vendor said that you could run their product for a while, pull the physical switch out, put a new switch in, and they could configure the switch to match the prior config, even if you plug the cables into different ports. There also are integration considerations with MDM solutions that can further extend “NAC” capabilities.
Of these capabilities, the first two points are likely what best qualify as “NAC,” while everything else is “in addition to.” Overall, we’re hoping to define common use cases and architectures, as well as provide clients with a good starting point for undertaking a NAC project. Have you worked with NAC or 802.1x recently? Have any stories to share?
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.