First, I would be remiss not to acknowledge the time that has passed since my last blog update. I have experienced quite a few life changes which has left me with less free time to work on my blog. However, in this new year, I am going to try to set a goal to set time aside to continue to generate content that I hope is useful to you.
The Question
A common question I hear from customers is “How can I make sure devices that connect to my network have the correct access?” It is a straight forward question without a straight-forward answer.
A common use case is making sure some non-company device plugging into a conference room does not have access to internal resources and is limited to restricted access to the Internet. Another use case is making sure that a company owned asset from the IT team plugged in a random cubicle gets access to the admin network and its resources for troubleshooting a machine without manually reconfiguring the port on the switch it is connected to. Most administrators want to allow the proper level of access to their resources depending on the device (and subsequently the user) connected to it.
Let’s explore some of the reasons why this answer is not straight-forward.
Legacy Options for Enforcing Access
Devices primarily connect to a network through wireless or wired connectivity either through a wireless access point or a switch (respectively). Since these devices provide physical and data-link services to the endpoint, the access device typically relies on characteristics associated with those levels of the OSI model.
Please Note: This series of articles will primarily focus on wired connectivity.
MAC Based Enforcement
Historically, switches could restrict access to a particular port or VLAN based on limited criteria. This criteria usually relied on the MAC address and being able to limit connectivity via the following methods:
- The maximum number of MAC addresses learned on a single port
- An Access Control List that would allow access based on a allow/deny list of MAC addresses
These two methods are not scalable due to their static nature. Limiting a switch port to a single MAC address is fine until a user moves from that port and a new user has to connect to it. Also, in a conference room setting, it would become quickly useless as soon as the meeting is over and another device connects to that port.
An access control list would be an administrative nightmare to keep up with and can easily be defeated by MAC spoofing (which most network interface card drivers support without any special software).
802.1X
The next evolution beyond just relying on MAC addresses was the advent of 802.1X. This is an IEEE standard that allows for port based network access control requiring a supplicant which can supply some identifying criteria (usually a certificate or username/password combination) to the switch (authenticator) which in turn submits to a third party authentication server to validate whether that user is authenticated to access that port.
This method is regularly used today however it is not without its shortcomings:
- Requires an 802.1X “supplicant” which is software that knows how to speak 802.1X to authenticate against the switch. IoT and other headless devices may not have this supplicant that can be used for this purpose.
- 802.1X supports MAC Address Bypass (MAB) which instructs the switch to take the MAC address of the device and submit it to the authentication server, however this has the same shortcomings of using the access control list method referenced in the section above.
In both of the methods above, there is no visibility above the MAC address being used and the user who is being authenticated. In either of these cases, the posture of the device connecting to the network is unknown. To overcome these shortcomings, purpose built Network Access Control software was designed and built.
Current Options for Enforcing Access
Network Access Control
The best solution today for determining when an endpoint should have access to a network is facilitated through Network Access Control (NAC) software. In addition to providing access to the network, NAC software typically provides visibility to the endpoint that is connecting into the environment by polling information from the infrastructure. This additional visibility can be acquired from the endpoint characteristics such as:
- DHCP Fingerprint
- MAC Organizationally Unique Identifier (OUI)
- User Agent
This information can give the network administrator higher confidence into the device connecting into their network. Taking it one step further, with an agent installed on the endpoint, even more information can be learned. Some of these characteristics are:
- Certificate present on the machine
- Vulnerability status of the machine
- Status of security software
- Processes running on the machine
With this amount of capability, it is easy to understand why there could be an additional cost associated with these point products that provide this type of solution. However, the Fortinet Security Fabric solution does not fall inline with this idea.
Fortinet Security Fabric Network Access Control
Fortunately, customers who have adopted certain components of the Fortinet Security Fabric can have this functionality with no additional cost or licensing. These components are:
- FortiGate
- FortiSwitch
- FortiClientEMS
- FortiClient
An example of this environment looks like the following:
Figure 1. – Screenshot of the network access control environment
These components can be configured to work in tandem together to provide similar functionality to a product specifically created for Network Access Control. Leveraging this solution allows for access control to be deployed based on device, user (captive portal) or a FortClient ZTNA EMS Tag.
Figure 2. – Screenshot of NAC policy based on Device
Figure 3. – Screenshot of NAC policy based on user (captive portal)
Figure 4. – Screenshot of NAC policy based on ZTNA EMS Tag
This functionality may not completely equate to the capabilities in a purpose built NAC solution, however, depending on the use case, it is an iterative improvement for securing access to the network with non-integrated network and security infrastructure.
In the next blog article, I will explore the capabilities around applying the NAC policy based on the device characteristics and explore the use cases associated with this method. Stay tuned!