In a perfect world, your network would heal itself. In a not-so-perfect world, your users fix their own problems. In a nightmare scenario, a single Administrator has to do it.
In IT, sometimes our desire to automate is manipulated by vendors to help sell their products. For companies that are looking at Network Access Control (NAC) products, it is important to know how to adjust your expectations. In this article we cover five things your NAC vendor may say yes to that is never going to happen.
5. Pre-Auth Security Checks
When I first installed an SSL-VPN for a client over a decade or so ago, I remember my client was very interested in one feature. He asked that we make sure "Grandma's PC", as he called it, was checked for a minimal security standard before allowing users on untrusted computers to connect. It was simple; we would have the user connect using their browser and the VPN would provide a dissolvable agent that would check their machine agentless (so Grandma wouldn't install anything). Done. Every SSL-VPN would do this, all firewalls with an agent would do this and nobody complained.
Years later, we would return to these customers and they would ask the same question about their internal network and BYOD users. I explained that the captive portal on the firewall, wireless AP/Controller or Switch was the same as their SSL-VPN. Managing hundreds or even thousands of internal devices every morning to run security checks, in comparison to the few hundred potential users of the SSLVPN, would be too much even for these devices (it would be too much for the VPN as well).
It is also non-standard and even in 2017 the 802.1X or Fat-AP (pronounced Cloud AP) designs of the network still cannot do this efficiently. It is not just because the AP, Firewall or Switch does not have the web-server power to do it either. It is because these devices do not manage new connections like a VPN does. You do not sign into the switch or access point they sign into RADIUS servers and that server has no way to stop and ask you for a virus scan during the authentication process in a standard way.
As a result, mixed-vendor environments with various NAC products, either agent or agentless, do not scale properly and customers come up with a number of hacks to try and force-fit the VPN use case into their NAC project. Which they eventually abandon in favor of their users. Let me save you the time; this does not work. Even if it did, security hygiene is one aspect of your MDR and may have nothing to do with whether or not a device is infected. But that is a different article for another time. Sure, you should check endpoint hygiene with your agent, but do not stop users from connecting while it happens; it does not work in the real world.
Probably my favorite words in the vendor community. The audacity to even put those two words together and claim that this would even be possible should be reviewed by the advertising standards council. Agents, at best of times, have the ability to check for the absence of signatures or running programs and then run an update, or scan or start/stop functions within them.
That is about as much endpoint automation as you are going to get. It will need an agent, and a very sophisticated one (like ours), to read the thousands of possible AV vendors on the machine and have an API for them. There is no time when your network is going to provide your users with a simple list of instructions or repair all of their problems while they wait to connect to the network.
There is no standard way between vendors to move users in and out of VLANs while still communicating different information about their endpoint through the browser. The closest available is generic instructions created by the administrator about which checks failed but that is more auto-reasoning than it is remediation.
If you have a threat, block the threat. If you need to automate security hygiene, then do so, but moving users in and out of VLANs during authentication and trying to get them to follow online instructions does not work. Less hygiene to remove access and more threat detection and removal.
3. Agentless NAC
Can it do it without an agent? A dissolvable agent? No credentials? No access to the switch? I would love and hate a world where the network had full visibility and control over the device depending on who I was. The truth is that agentless features are really a collection of network-based API integrations with your network, endpoint and systems to facilitate visibility when there is no agent or configuration possible for your network for 802.1x.
Resist the urge to believe someone who says they know anything meaningful about your endpoint without an agent in it or access to management consoles that do. Using WMI, SNMP or APIs to Windows systems will not give you any information about the security hygiene of a device. It would more beneficial to trust an in-line threat prevention and anti-malware product actively stopping threats with an agent and log collection to determine if something bad is happening (like IntelliGO does).
Try as we might to make the software defined world of Controller/Fat-AP Wireless systems like our wired, cloud or virtual networks, they are not the same. These products were all made to manage different access scenarios. Your NAC has no plan to authenticate AWS/Azure or VMware networks. The workflow of sign-on and identity for applications, operating systems and rights are outside of the scope of a NAC and border IAM. There is no 802.1X, SNMP or anything the IEEE or IETF came up with to manage these, or are likely to.
At IntelliGO, we use our agents on systems deployed in these environments to check hygiene and collect logs from them to determine who accessed what. At best, your RADIUS server or Agentless NAC vendor might be thinking of puting their VPN client on it but do not hold your breath that the scenarios will look the same when complete.
There are so many organizations that just want to know how many devices they have and what they are. There are also many devices which get an IP different ways: wired, wireless, DHCP, static. Some send traffic, some can be scanned, some are behind IOT gateways and are not even connected to your actual IP network.
In the IOT world, fingerprinting is everyone's favourite response to this problem. There are limitations to this so expect that Fingerprinting alone will NOT tell you all the devices on your network or even a subnet. Fingerprinting listens to traffic and identifies devices based on their DHCP messages (Option 52). Some vendors will mess around and try to captive portal them to grab the user agent but for the most part, this misses a lot.
Many devices are connected with a static address (servers) or do not send regular requests for a new address (VOIP phones) so you need to scan the network to get ARP data and VA scan to get OS data. However, even this will produce multiple NICs - hostnames which can augment the count of devices. Fingerprinting will tell you what is potentially behind a MAC address but it will not do much to give you a complete understanding of your assets.
To evaluate a NAC properly, try not to think of your VPN. Your network has little in common with the VPN use case and with the cloud and virtual environments this difference is only increasing.
Your NAC project is about finding and securing all devices. This is why we believe an MDR platform like IntelliGO is the right place to do it. We don't want to make outlandish claims about how a NAC provides a self-healing network bringing your whole environment to the gold standard; we believe an MDR service does and provides a realistic picture of your security posture.