Access Control General Best Practices

Some of the best practices when it comes to securing your access to the network– when we talk about the most secure method to access the network, we are generally talking about 802.1X, which is a framework standard that’s been out there for many, many years. Many client devices support this today. This is what we would consider the best and optimal way to do secure access to your network.

But there are many flavors of 802.1X and how devices would authenticate themselves to the network. But broadly speaking, we can separate them into categories. One is the credential-based authentication. So you would connect to a network, whether it’s a switchboard, or you connect to your AP that supports .1X. You would put in your username and password, and, at that point, you’re authenticated, and you’re on the network.

In this scenario, when we are using credentials to authenticate, you are required to have an identity provider that will actually verify that the credentials, and the user account is valid. And nowadays, or actually, previously, the primary IdP for everybody was Active Directory. That was typically running on prem. Nowadays, the trend is to move to cloud-based identity providers such as Azure AD or Okta or Ping Identity or Google Workspace or whatever else that is out there. So IdPs are moving to the cloud.

Now, the challenge with credential-based authentication is that there is really no good way to handle multifactor authentication here. So you are literally only relying on your username and a static password that you may or may not rotate periodically. And that brings in certain issues when it comes to man-in-the-middle attacks.

Historically, customers were not configuring their client devices correctly. So that was exposing man-in-the-middle attacks vectors to happen. And the typical scenario is that clients would bypass server certificate validation. So there is no mutual authentication happening. And at that point, anybody could have spoofed your credentials, and you would have become a victim of an attack.

The other aspect of this is, starting from Windows 11, the latest update from Microsoft, Microsoft decided to enable a feature called Credential Guard by default, which, as a result, disables and blocks all password-based authentication methods for both Wi-Fi and VPN. That means you can no longer use your standard PEAP-MSCHAPv2 or TTLS/PAP methods to connect using .1X. Microsoft is saying everybody should move to certificates, which brings me to the next section.

The next option to validate or to authenticate devices against network is to use certificates as user or device identity. So digital certificates are installed on client devices, whether it’s laptops, mobile devices, et cetera, et cetera. They can be either device based, so they’re issued for a specific machine name, like a laptop name or a specific device or mobile device, or they’re issued for a specific user that’s logged in to that device or both.

So in this case, you have an option to choose whether to use user-based authentication or device-based authentication. In this case, identity provider is optional. So you can solely rely on validating the certificate. And if the user or device certificate is valid and trusted, then you would allow the client to connect.

You can additionally rely on the IdP to get more information, more context about the user that’s trying to connect you. For example, you could check account state of that user if that account is still enabled. Maybe the account got disabled, but certificate is still valid. There’s certain cases like this.

And, most importantly, you want to get group membership information about the user. So you need to know, OK, this is a valid certificate, but what level of authorization I want to provide for this user, whether it’s an employee contract or part of finance, marketing, et cetera, et cetera. This is where IdP becomes useful.

Today, this is the most secure authentication method. Certificates are stored in secure storage. They’re generally not user accessible. It’s virtually impossible to forge them, to hack them, or do anything of that nature. So this is the recommended authentication method if you want the most secure way of accessing the network.

With certificates, the challenge is client device provisioning. You need to have a certificate infrastructure, which is called PKI, or Public Key Infrastructure. And you will need to have a tool that will provision your devices at scale, so users don’t have to do this manually. In enterprises, in production environments, it is typically done using MDMs, or Mobile Device Management platforms, right?

So an example of an MDM is Microsoft Intune. So at the moment, you will get the company-managed device. It will register itself with an MDM. MDM will push all the required information, including a certificate.

OK, what about cases where we are not dealing with a device that supports 802.1X, or you’re dealing with cases where you don’t want to manage the device and deal with certificate provisioning, et cetera, et cetera? So with non .1X cases, we need to look at two categories.

First is Wi-Fi. What can you do with Wi-Fi-connected devices that are not leveraging .1X? And when we’re talking about Wi-Fi, you really have two types of devices there. One is IoT devices, or your headless devices that don’t have any interface on them. They generally don’t support .1X, or their .1X is very, very limited and cumbersome to configure. And we can call them unattended devices, right?

And we can also talk about the BYOD devices, or Bring Your Own Device, where we are talking about personal devices, but, say, in the enterprise of personal devices of employees, that you are not managing as IT, but you want them to be able to connect to the network using some form of an identity that they have.

In this case, our recommendation is to use multi-preshared key solution that we have today, where each and every user, if we are talking about BYOD, will have their own personalized PSK, which becomes the identity of that user. And that personalized PSK is self-provisioned using single sign-on through a PSK portal that we host. From an IoT device perspective, you would have a unique PSK for each device type, for example, a PSK for Wi-Fi cameras, a PSK for Wi-Fi door locks, HVAC systems, et cetera, et cetera.

For each keys, you could set up your policy segmentation logic, assign a VLAN, assign role, et cetera, et cetera. And you get the same level of visibility and auditing as with traditional .1X systems, right? But from an end-user perspective or end-client device perspective, it’s as simple as connecting to a Wi-Fi using a passphrase, so the same as you would do at home, right?

This second aspect is wired IoT devices, right? This is where we are talking about, say, wired cameras, wired printers, wired anything that does not support .1X or is not provisioned to do .1X. In this case, the identity of the device is really just the MAC address. And, in this case, you could use Mist access assurance client list labels to apply policies on a switch side. You could look at the MAC or UIO MAC vendor of the device and apply different VLANs for printers, for cameras, et cetera, et cetera.