July 31, 2019

How to Choose a Network Access Control System

Though they might not be the first security solution they come to your mind when you need to secure your systems, Network Access Control (NAC) systems are in fact useful and at least by some really needed.

NAC’s main purpose is to manage who has access to each of your network segments and what they can do once they get access. Generally, they do this by allowing you to write policies that explicitly tell how should it decide whether an user is allowed or not to get into the network and by integrating with other security tools such as with the firewall or antivirus and taking decisions based on the information they get from those tools.

Configuration

Though NAC systems are often seen as difficult to configure, modern solutions are able to ease this aspect and the needed effort can be generally seen as similar to configure a firewall or an IDS system, but often with more options to allow fine tuning. They can be either hardware either software appliances. They might have some specific requirements for the setup, so you should check them before you decide which one is suitable for you.

They are usually placed at the same level/ layer as the firewall that restricts the access to a network and directly connected to the firewall, meaning it is important that the chosen NAC system supports the vendor and firewall type that is currently used.

Most of the Nac systems provide RESTful API or at least OpenAPI to ease the integration between their product and other security tools you use. Each of them has more or less tools that it can natively integrate with, without requiring to call their API for integration. But considering the amount of tools available out there, there is a big chance it won’t be able to integrate with all the tools you’d like, so you should keep in mind that you might need some coding.

Agent vs Agentless

NAC systems use at least one of the following approaches to collect data from the device based on which it will decide whether the device is compliant with the policies and can connect to the network or not:

  • agent. Agents are small pieces of software that are installed usually on company owned devices. Most often they require the 802.1X protocol and a RADIUS server
  • agentless. These ones do not require software installation on the endpoints at all. They are used for less smart or userless devices or for devices that the company does not own and therefore cannot install even a dissolvable agent on that device. In this case, the common solutions are either to take decisions based on an usual network scan, either by registering that device’s MAC address, although it can be spoofed.
  • dissolvable agent. These are often called agentless as well though they refer to a piece of code that gets installed temporarily on the user device every time they try to connect to the network. Then it does the checks, reports to the NAC server the results and then immediately auto-removes itself.

Known vs Unknown Devices

When a device is known, it will generally have different rules to apply to compared with the unknown devices and different ways to work with the NAC. Known Devices include any company owned device, no matter the type of connection they use. Usually NAC systems can connect with CA servers as well, which can be useful to take a faster decision regarding how safe really is to allow that connection, based on whether the client certificate can be recognized by the CA server.

Unknown devices include basically personal devices, contractors’ devices and guests devices. A common way to use NAC systems for these devices is through captive portals, to be able to authenticate the person connecting to the network as this type of data couldn’t be obtained in an agentless manner. If the device cannot be associated with a certain user, then it could be treated as a “guest” user and give it browsing access only or as limited internal access as possible, preferably none. A combination between captive portals and registering the device seems to be the preferred manner of allowing access to contractors and temporary employees.

NAC capabilities

When you choose a NAC tool, there are many features you can look for. Depending on their cost, some of them have more or less of these features. I have found important for a NAC system to have the following capabilities:

  • to be able to manage requests for any segment of the network as different subnetworks have different requirements. It should be able to control access at the subnetwork level rather than as the entry point for example in the corp network, where someone might benefit the most by using a NAC system
  • to be able to take decisions for both company owned devices and BYOD (personal devices) if these are allowed to connect to some parts of the network. Otherwise, you will always miss visibility on the traffic coming from personal devices.
  • to support the creation of policies based on the connection type (BYOD, VPN, guests/ contractor, wired), device type (server, PC, mobile,…), on the running operating system and most important based on the software running on it and user identity/ role/ ACLs (Access Control Lists). Having policies may be seen as having a set of rules that would allow someone to understand if what happens is considered good or bad and would allow them to take a decision how to action. Being able to control access based on the present software means being able to decide whether a device is allowed to connect if it contains some software or more important if it misses some software such as the antivirus you require. Having policies based on ACLs means being able to decide if someone is allowed to connect considering who they are, the job role they have or the team they are part of. I find this feature really useful as it allows a granular control over the networks, no matter the IP the users come from.
  • to be able to take an autonomous decision given the above list of specifications whether to allow the device, disallow it or quarantine it. Generally NAC systems have this capability of taking a decision based on the above rules whether it should allow its access, deny it or quarantine it which mean sending the device to an isolated network where it can find the tools it needs to become compliant.
  • to be able to automatically “repair” compliant devices, but to have the option to postpone or allow manual repair as well. If a device goes to the quarantine network, it will generally be provided with a list of tools that need to be installed or upgraded/ updated on their device to become compliant. It is important to be able to do this manually, but a lot of the employees might not have the knowledge to take care of these, even if they seem trivial. For this reason, having a tool that does it automatically helps a lot. Though you have to make sure it can postpone them for a bit, to avoid interrupting people during their business hours or during important business meetings.
  • to support both agent and agent-less mode. You can install agents on all devices that you own. But if you allow devices that you don’t own, such as BYOD, contractor devices then you need to be able to interrogate them and take a decision if you would allow them without intruding.
  • to be able to notify/ alert or support any kind of integration for alerting in case manual take over is needed or there are some anomalies. The more tools you add to your system, the more difficult is to maintain them and to have a broad picture given the data you take from each of them. For this reason, the tool has to be able to integrate with a tool that correlates data from all the different tools you have and to raise alerts if immediate action is needed.

Policies

Allowing or disallowing user access to any of the networks and what he is allowed to do once connected is defined using two concepts: ACLs and Policies. LDAP and Active Directory can be directly connected to the NAC system and actually the NAC system can be used to enforce ACLs. Policies can be defined and correlated with ACLs to treat each possible use case. Some common use cases for policies are defined based on:

  • if the device can be authenticated or if the client certificate is valid
  • if the device contains disallowed apps or misses necessary agents or apps or contains apps that are not reviewed
  • the time the device was inactive
  • password compliance
  • operating system, ACLs based on user/ job role/ team/ group, device type and connection type

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *