Deploy port-level access control. Port-level access control utilizes 802.1x, or similar network access control protocols, such as certificates, and may incorporate user and/or device authentication. (CIS 13.9)

Network Access Control is heavy. It requires big investments in the most expensive network gear, requires a fair amount of work to maintain, and can break systems if people make mistakes. It provides good protection from expert onsite attacks: nothing gets to talk unless it’s allowed. Almost everyone implements NAC imperfectly, mostly to compromise on resiliency, political reasons, or for cost reduction.

There are also ways of implementing the spirit of NAC in non-traditional networking models such as a 0-trust or Software Defined Networking, most commonly via a PaaS like AWS or Azure. These approaches can provide the benefits of NAC with less cost and more stability; see the below section on Alternate Models for more.

Note: this control used to be #1.7 and 1.8 in previous versions. I think CIS has correctly responded to criticisms like those described in this blog post, and moved the idea to a lower priority: #13.

Reducing NAC pain

If you’re going to structure your network to prevent anything that you don’t know about, you need to make sure that everything plugged in is on your inventory. Every unregistered asset is going to stop working – are you prepared for that?

It is also essential to communicate to all the people who plug things in that NAC is coming, and what it will practically mean to them. Don’t forget anyone – remember that CMO with an Alexa device and internet-enabled juicer in her office? Those are going to break too, and she’s gonna be mad. Even if you add them to the inventory, she’s still going to be mad next week when she brings in her new internet-connected aromatherapy diffuser and it doesn’t work. You have to explain the change.

Before you do NAC, make sure your standard asset registration processes are strong and are being followed. This will go the farthest in reducing frustration within your company. You may want to do a simulated period first, where you watch for new devices that don’t get added by the normal methods, then reach out to the people that did it. Did they know about the asset registration process? Maybe it doesn’t work for them - did you miss a use case?

Your intent is not to block legitimate devices attached in good faith. If this happens a lot because of inadequate education or because you didn’t give them a path to authorize their asset first, you’ll create unnecessary pain, unplanned work, and ultimately resentment within the organization for your team. Don’t skimp on the organizational readiness for this project.

Sensible Device policies

Good NAC goes hand-in-hand with good segmentation. Assets should be categorized and segmented appropriately. For instance, nothing good can come from an IP phone talking to your ERP or a manufacturing kiosk. Customer Service desktops shouldn’t need to talk to each other, and almost nothing should talk to the IPMI interfaces for all the blades in your datacenter.

A note about wireless: When done right, NAC doesn’t care about the transport mechanism – it works just fine for ethernet-connected stuff, VPN-connected stuff, or wifi-connected stuff. Many teams start their NAC journeys on the wifi segments – it works great.

802.1X is the standard protocol for authenticating and authorizing devices. There are a bunch of ways you authenticate devices, some pretty old and lots of them bad. I’m going to skip the historic rabbit hole and mention only the two main options:

A cryptographic certificate. The most common way to do this is EAP-TLS.
Matching a Mac address pattern. Use this for assets that can’t do EAP-TLS. This is not 802.1X, but is a necessary complement to it.

There is other governance you can do as part of NAC that ties in nicely. For instance, when devices authenticate, you can also chain in user authentication and configuration verification. This is especially popular in 0-trust device authentication, where user and device are authenticated simultaneously, and some spot-checks are performed for top configuration priorities like AV status or OS/browser patch levels. See the upcoming sections on CIS 5 for configuration assurance.

Cryptographic certs

Unique certs using EAP-TLS are the way to go for almost every organization. Each Asset Inventory record needs a cert that NAC checks against when authenticating that asset. With modern network gear, it’s not much harder to do than other NAC methods; the hard part is making sure things stay up to date. If you’re doing 0-trust, it may be easier to authenticate the cert in a different protocol than 802.1X, but you should be able to use the same device-specific cert. Assume this cert will be viewable to sophisticated computer users, especially if you’re using it for 0-trust. While user awareness is a security gap, it’s not big and other security practices are well-suited for addressing it. Say it with me again: no control will address all security risk.

The best way to make this work seamlessly is to bake certificate generation into device provisioning and registration. You want people to use advertised, standard processes for creating or adding assets. Applying NAC is one of the most effective: unless they go through the standard provisioning script, their new shiny server can’t talk to anything. This means that your standard asset data maintenance processes needs to automatically take care of certificates in all use cases, otherwise you’ll be in a world of exceptions and grumpy IT. Make the desired path the easy path.

You can do 802.1X with a generic cert that you provision to every device. This eliminates some of the outage risk of NAC – fewer moving pieces means fewer things can go wrong. However, it eliminates most of its benefits – all it means is that for a given “authorized asset”, the person who created it also had access to an authorized device (and thus the generic cert). It doesn’t mean that the device is in the inventory, and it becomes much harder to shut it down if malicious. You get all these same benefits if your asset data maintenance processes rigorously address certificate management as mentioned above – just do it that way.

There are some situations in which certificates aren’t going to be totally unique, and shouldn’t. For instance, if you have a JVM or container that may scale up and down to multiple instances depending on load, it usually makes more sense for each image to have a certificate provisioned during build (remember, use a different one for each nonprod: they are different!). Then, each instance of that image will have the same certificate. This matches your asset approach, too: the container image maps to a unique asset record, of which there may be multiple instances. This is the right path: you want to think of all these instances as the same thing – if you ever want to block it at the NAC level, it’ll knock the whole application offline. If there are misbehaving instances, there are better tools in the cluster engine to whack them individually.

You can also use the device certificate to authenticate server-side assets to each other for authorized communication routes. Be careful of this, though: it’s still important to restrict access to only intended communications, and often it’s easier to apply those rules with service accounts, which should do their own authentication. You can do both; this is the default authentication strategy within Linux: first authenticate the server, then the user account.

MAC address matching

Many assets can’t speak EAP-TLS – think of VoIP phones, WAPs, or robots in your manufacturing plant. In almost all these cases, these kinds of devices need special provisioning and ongoing services. Here, NAC can use the MAC to identify the device type, and put it into a class-specific vlan containing only a provisioning/registration service. Further access to ongoing services can be chained to depend on successful provisioning. Technically, this is not 802.1X. However, almost every organization has network-connected assets like this, so using MAC pattern matching is an implied complement to it.

Consider the following: If an evil hacker snuck into your building and plugged an evil laptop into an innocent network jack, it’s easy to adjust the outgoing MAC address to match the brand of the IP phone sitting on someone’s desk. So, the NAC shouldn’t just let my computer talk to anyone just because it has the right MAC address vendor. Heck, even if each MAC was registered in the Inventory and validated by NAC, the hacker could briefly unplug the phone, connect it to her laptop, learn its MAC, adjust the evil laptop’s MAC to perfectly match, and even plug into the port formerly occupied by the phone.

The NAC must not allow unrestricted access to “the network” based on MAC matching. If the NAC further restricted “phones” to only speak to a phone-registration service, that dramatically increases the further effort of the attacker: she must either continue to pretend to be a VoIP phone and somehow convince the registration service of it, or somehow break into the registration server in the position of an unknown phone that needs to register. Even if she successfully registers as a new phone, she’ll only be able to perform actions as a phone, talking to other phone-related services. This approach dramatically reduces her options to break in.

Even if these devices don’t need special provisioning or services, they usually aren’t sophisticated and should be protected from bad folks. As a rule, anything that can’t speak EAP-TLS should go on an isolated segment without access from regular people.

Other segmentation guidance will be discussed in section 14.

Alternate Models

Software-Defined Networking

Some infrastructure platforms provide integrated registration, control, and management of assets and communications. Hypervisors like vsphere can do this: all the VMs are assets, and Vsphere allows you to control the communications between them without relying on network gear. New VMs can be manually or automatically provided access to each other or the outside world.

AWS extends this concept with its IAM capability. Each instance advertises available methods of access, and IAM allows you to write specific rules as code to allow instances to communicate, with almost infinite detail and nuance. This flexibility makes it famously hard to configure well, with “incorrectly configured S3 buckets” one of the most popular data breach types. Azure uses a similar model.

Using asset-based access control provides most of the value of NAC: only allowed assets are allowed to communicate. If an asset is created in such an environment, it is authorized. We could argue about whether the authorization was appropriate (maybe someone’s vsphere access was compromised) but you automatically avoid the case where you don’t know a list of all the assets and who created them. If you govern the environment correctly, you also easily capture how a particular asset was added, what it does, how scary it is, and what it needs to talk to. The inventory is intrinsic to the platform.

0-trust networking

Google pioneered this model when they realized that it was too hard to infer how much to trust a service or supplicant based on its network location. Their solution? ditch the idea of an “internal network” entirely. Instead, apply consistent authentication rigor for access regardless of its purported network origin. A side effect is that networks are much easier to design: every asset is an island and trusts supplicants and services only if they meet a high bar for authentication. Usually, this means that each asset authenticates itself with a cert and users authenticate themselves with tokenized SSO. This ends up looking a lot like NAC, with unique asset certificates and a common service to authenticate them to each other. In 0-trust, the conversation isn’t restricted to a particular network path or segment – it can be routed anywhere, relying on strong encryption to prevent compromise over uncontrolled networks. In addition to being more scalable and secure, employees working from home/hotels/client networks doesn’t involve individual effort from the network team.

Some elements of NAC are still good ideas in a 0-trust design. In particular, the following are excellent additional factors of authentication. They each rovide additional assurance and telemetry without adding friction to the worker login experience.

unique cryptographic signatures on each user device

running device health checks during authentication
super-strength: u2f from a yubikey or similar

CIS does not yet proscribe 0-trust, though this may change in future revisions.

Noncompliant NAC

Some network gear companies let you do “NAC” without 802.1X. Fortinet is a great example. Instead of cryptographically authenticating each asset against the inventory, it bundles an active discovery engine, a database, and a port blocker together in one appliance. For the purposes of CIS, this kind of solution doesn’t satisfy 1.7 or 1.8 – it’s more in the CIS 1.1 and 1.4 space.

Compliance

PCI

PCI DSS 9.1.2 requires that you “Implement physical and/or logical controls to restrict access to publicly accessible network jacks.” While many people interpret this as a NAC mandate, you can address it in other ways. Here are several:

Don’t have network jacks in public places where you have unescorted visitors.
If you need network jacks in public places, just turn them off at the switch.
Phone it in (see below).

Phoning it in

Sometimes your customers are idiots. Sometimes they will demand that you do a security thing even if it doesn’t meaningfully reduce risk. Because reasons, you may decide that doing what they want is worth it. Fine.

If your customer asks you to do NAC, it is one of the easier things to fake, avoiding most of the cost and care I’ve described. Usually, your auditor is usually just looking to check the “NAC” box on their vendor compliance sheet and they don’t ask too many questions about what exactly that looks like. Here are some popular ways of satisfying them:

Sometimes 0-trust will make them happy. You can say, “It’s NAC, except even stronger – all the cool companies are doing it!” Sometimes it won’t because 0-trust isn’t a box on their checklist.
Only apply NAC to wireless segments. Popular and much cheaper.
Only apply NAC to one or two “high risk” segments. “yes, we do NAC.” Waaay cheaper, much lower risk of outage.
Skip NAC on your servers or datacenter segments. Extremely popular, not cheaper, but lower risk of outage.
Don’t tie your NAC back to your inventory, maybe just use generic certs or just user creds. Not cheaper, but lower risk of outage.

Summary

If there’s a credible threat that smart, evil people have access to your organization and you have a lot of physical and network infrastructure, NAC is a great way of making their jobs waaayy harder. It will stop major avenues of attack by preventing invisible asset creation.

If that does not describe your organization, NAC is probably not worth it for you. There are easier and cheaper ways of maintaining your asset inventory. Spend your money and influence on something better like 0-trust.