Reimagining NAC - Part 1 1/2
Post 1 sparked a handful of comments on LinkedIn around identity, PKI, 802.1X, etc. which I would fully expect when discussing traditional or Enterprise NAC.
It also reminded me to expand a bit on the functionality of Enterprise NAC because what I’m proposing is NOT that.
“What are the capabilities of Enterprise NAC?"
Below is excerpted from this Fortinet page, but you can easily find similar listed on Cisco, Portnox, and a dozen other Enterprise NAC solution pages:
“This all sounds great; what’s the problem?"
Everything listed above IS great but what those solutions require in infrastructure, integration/deployment, management and expense goes far beyond the infrastructure and resources of most small to medium industrial network operators I have worked with in the last 15 years. It’s worth noting I have worked primarily in Food & Beverage, Manufacturing, Water/Wastewater, Oil & Gas, and Materials Handling/Logistics - NOT regulated Electrical Utilities.
This is exactly why NAC is rarely seen in OT, I'd argue NEVER for the masses with the tiny (read: 1-2 person) controls team often reliant on external SIs just to keep the system up and running.
My entire OT networking career has been focused on helping customers take some basic steps forward and in such a way they can actually maintain it: unmanaged to managed switches, unconfigured managed switches to actually managed 🤣, VLAN segmentation and routing, ACLs/Firewalling between those segments for the really adventurous, network monitoring/management, and secure remote access. These steps, while admittedly barely being CCNA level networking, increase the robustness and scalability of those networks many times over.
Against that list of improvements above (which many times is only partially pursued and completed), it becomes obvious why NAC seems like a stretch. I'd go as far as to say Enterprise NAC is unachievable in most of those systems.
“So if Enterprise NAC isn’t a fit small to medium systems, what are you proposing?"
How about something simpler? Am I talking about host profiling and posture assessment, Active Directory integration, quarantine VLANs, guest captive portals etc. - NO. I'm talking about a very basic system:
“So what you’re proposing won’t give me full visibility about where a device is plugged in, whether certain software is installed on it, and validate identities through 802.1x and certificates etc?"
NOPE! If above is what you’re looking for or need, this is NOT the solution for you.
What I’m proposing is an option for those overburdened, time and resource-limited, small to medium systems so that overburdened controls engineer responsible for a sprawling system can effectively deploy a bouncer in front of their club (network).
The bouncer has a list of approved guests on their clipboard and when a new guest arrives can look at the clipboard or radio the owner “Hey, there’s a Peter Parker here at the door and he’s not on the list. Are we letting him in?” The owner can allow or deny entry, and at any given time change his mind. Maybe the owner lets Peter in and decides an hour later they no longer want Peter in the club. No problem. Owner radios the bouncer “Peter’s no longer welcome” and we know what the bouncer does next - buh bye!
Easy. Peasey. Lemon. Squeezy.
“Are you ever going to explain how this would even be possible? This doesn’t sound feasible, especially without any switch integration and sounds even less likely with unmanaged switches. Are you just a liar?"
It was important to first confirm what the solution is NOT. In future posts I will provide both layman’s and technical explainers for the mechanism I’m proposing. Spoiler alert: the mechanism is not remotely novel but it seems the application into an OT network is. I’m excited to get additional feedback about that from all of you.
Stay tuned!