The basis for Network Access Control
In the circumstances corporations now find themselves because of the Covid-19 pandemic, network segmentation deficiencies have been spotlighted as an alarmingly weak spot in modern network enterprises.
A recent example was provided by an attacker penetrating an IoT-based HVAC system that ultimately provided the attacker a nearly unrestricted path all the way to the victim corporation’s Point of Sale systems.
While re-architecting many infrastructures to provide more granular and secure segmentation would be an enormous ask, the first part—of low-security IoT devices being able to provide a starting point for a path through the network—is an easier one to address.
Network Access Control, or NAC as it’s commonly referred to, is a process by which before network access is given, a user or a device (or both!) must first authenticate to the network.
What we’re NOT talking about: We’re not talking about logging on to a workstation when you first walk into your cubicle; in this instance your workstation is already connected to the network and you’re just providing your user credentials to log on to, for example, the Windows Domain.
What we ARE talking about: Rather, we’re talking about when you first connect your device—connect your laptop to the wired network, or connect your smartphone to a wireless network’s SSID, as examples—your device must first provide some kind of authentication, be it a MAC address or a certificate, and the network switch or wireless controller authenticates that MAC address or certificate against a centralized source.
Pass this authentication, and the device is allowed onto the network (for example, put into a certain VLAN) and further user authentication can take place from there.
Fail the authentication, and the device is either put into a guest VLAN for Internet-only access, or placed into an isolated VLAN with an explanatory page telling the user how to fix the situation by contacting a certain person or following a certain procedure to get the device properly registered, or else not allowed connection to the network at all.
Taking this concept further into the IoT realm, devices which do not have a user-facing GUI—headless devices like printers, security cameras, thermostats, HVAC systems, “smart-building” alarm sensors, etc.—are notoriously vulnerable via unpatched operating systems or known hardware security flaws, and need to be handled with care.
Devices like these should NEVER have an unrestricted pathway to secure/sensitive internal systems.
Network Access Control solves this by automatically authenticating these types of devices and placing them into cordoned-off zones (VLANs) with access only to their “phone home” destination.
A common misconception is that Network Access Control is only applicable for wireless, or that “it’s that 802.1X thingy that never really caught on, so it’s an ‘old’ technology that is not applicable today.” That latter perception is particularly troubling, because 802.1X as a technology is painted as old/non-applicable because of the lack of quick-start guides and software wizards at the time.
Today’s NAC solutions are nothing like yesteryear’s NAC solutions, the latter of which required almost exclusive hands-on to the command-line configuration of all devices involved.
Setting up a NAC policy in today’s NAC solutions is as easy as following a “Start Here” wizard that quite literally walks you through setting it up, with resulting configuration statements that you install with copy/paste into the end-user-facing switch, controller, etc.
Network Access Control solutions aren’t an “all or nothing” solution, either.
What a NAC solution is NOT: It’s not like an entire switch or controller is either under NAC control or it’s not, and if it is and the NAC solution isn’t working, the entire population of users connected to that switch or controller are locked out from the network.
What a NAC solution IS: Instead, NAC can be implemented on end-user-facing devices in a hybrid way, where only certain switch ports or certain SSIDs are under NAC control, and as well as being in a “fail-through” configuration where if the NAC doesn’t respond, the switch port or SSID will allow a predefined “default” access.
Naturally, a caution is warranted with a hybrid configuration like this (especially with the availability of the “fail-through” feature), as NAC’s security itself can be eaten away with production connectivity emergencies. One example of this is service ticket troubleshooting where, instead of troubleshooting the user’s reason to need to authenticate to that particular security domain, the “resolution” carves away some of NAC’s security policy and the ticket is closed out, leaving a weakened NAC policy in place.
Network Access Control also offers improved visibility into the devices connected to the network, via the fact that many/most of them will “profile” the device as it connects to the network.
Profiling can be agentless—where the device’s own communication characteristics on the network are captured and leveraged—or agent-based, where an agent is installed on the device to determine the health before access is allowed.
This profile information is subsequently used for policy determination even before access to the network is given. This is how network segmentation through device type—and how IT devices versus OT (operational technology) devices—can be achieved without having to hardcode switchports, SSIDs, or the devices themselves.
News headlines of the latest hacks demonstrate not only the need for authenticated network access, but device-specific network segmentation as well.
Network Access Control is just one part of a more-encompassing IT security policy, of course, but an ever more crucial one. And today’s NAC solutions make it easy to implement, which is unusually low-hanging fruit in the information security realm.
The CBTS Security Solutions team has Network Access Control subject matter experts on staff to not only assist with the selection, testing, and implementation of a NAC solution, but also to help build that more-encompassing IT security policy.