NAC Implementation: Boil the Pot, Not the Ocean
It used to be that a company relied on physical security to restrict access to their network. But today, due to the evolution of the social hacker, bypassing most companies’ physical security measures only requires some basic tailgating skills, looking like you belong and a pair of khakis.
Furthermore, intentional infiltration or not, how does a company police access for their expected visitors or vendors, giving them the access they need while on site and restricting access from what they don’t?
But let’s not stop there. Just because you are an employee of the company does that mean you should have full access to all resources? For example, should an IT Administrator, even with enhanced security privilege to perform his or her job function, have any need to access company financial information?
I know what you’re thinking, and I have heard it before. Yes, yes, yes, Network Access Control (NAC) is great and all. In a perfect world. But in reality, we just don’t have the time or the money to implement it.
More often than not, companies have decided to accept the potential risk of not implementing a NAC solution with physical security and acceptable use policies governed by their security teams. Unfortunately, this still leaves you open to social hacking and relying on visitors, vendors and employees to follow the honor system. Companies look at the effort of a NAC implementation the same as they would as attempting to boil the ocean.
However, the tools and protocols you need are most likely already at your fingertips today. With those tools, and a powerful and versatile Remote Authentication Dial-In User Service (RADIUS) server such as Aruba’s ClearPass Policy Manager (CPPM), you can start to boil the ocean one pot at a time.
Protocols and attributes covered in this article will be 802.1X, RADIUS Internet Engineering Task Force (IETF) standard attributes and Vendor Specific Attributes (VSA).
As a RADIUS server, CPPM is, of course, capable of responding with accept and reject messages. But along with those responses, it can append RADIUS attributes manipulating access rights of the original requester.
Not only can CPPM respond with the industry standard RADIUS IETF attributes, it is also preloaded with over a 100 different Vendor VSA dictionaries: Aruba, Cisco, Extreme, HP, etc. So the manipulation of access rights, depending upon the functionality of the authenticator or network device can be quite granular.
VLAN Assignment, where a specific VLAN value is returned to the switch and the access VLAN for that port is changed for that particular requester. An Access Control List (ACL) or policy rule on an upstream router or a firewall enforced on the assigned VLAN will restrict/allow access rights as configured. Or the Downloadable ACL, a Cisco VSA, can apply the ACL directly to the user regardless of VLAN. These and any of the many other VSAs in CPPM’s dictionaries are also available.
Let’s run through a few different scenarios.
An employee with a company managed asset, let’s say a Windows Laptop, plugs into a switch port in his or her cube. The switch and the corresponding interface are configured for 802.1X authentication. When the device is plugged into the switch port and powered up, it will first try to authenticate as a machine (if configured to do so). At this point, the first RADIUS authentication has been made and any number of actions can be taken.
Let’s say you don’t trust just a machine authentication onto your network. You configure CPPM to respond with an access accept but also with a Downloadable ACL allowing DHCP, DNS and communication with AD and CPPM. This allows the machine to pull an IP address, do hostname/IP lookups, run AD startup scripts and additional protocols with CPPM.
Once at the login screen, the user enters their company credentials. At this point a second RADIUS authentication is made, and according to the user and access rights derived from his AD credentials, a subsequent user authentication downloadable ACL can be applied.
You can even add the previous machine authentication as an additional authentication requirement. So an employee with machine and user authentication is placed into a specific profile and ACL, allowing access to what they need to perform their function rather than an inherent “allow all” access profile.
I know what you’re thinking, 802.1X is great and all, but what if I have devices that are incapable of performing an 802.1X authentication such as printers, phones, security cameras, badge readers, etc. What about Media Access Control (MAC) Address authentication? Well, MAC lists are way too extensive to have the time or manpower to keep track of.
But what if you could authenticate on only part of that MAC Address? MAC Addresses starting with 00-00-85 are owned by Canon, so you could approve access for all MAC Addresses starting in 00-00-85 as printers.
Can’t MAC address authentication be easily spoofed? We can do the same thing here as we did with 802.1x authentication. When a device performs a MAC authentication with a MAC Address starting with 00-00-85, we approve access but we respond with access restrictions for that device.
For example, if legitimate or spoofed, the most access the device/user will gain is the ability to pull an IP Address and perform printing protocols to a specific print server. The same could be said for phones, security cameras, badge readers, etc., allowing each device only the access it requires to perform its function, and to only the resources it needs to perform that function with.
Another concern worth mentioning: If all my ports are secure, how do I provide access to my visitors and vendors? What if all failed authentication attempts grant the device/user access to browse the internet, blocking all other access - especially any and all access to internal company networks and resources? This would allow any visitor or vendor to have internet access when they plug in.
These are just a few of the options and/or tools available in Aruba CPPM’s arsenal for access management. These and many others are available to explore, depending on the vendor hardware and/or software version of the network devices you are looking to manage.
Did we deploy a full NAC solution with the scenarios described here? No, but we boiled our first pot of the ocean. We are leaps and bounds ahead of where the security model was, especially if the decision was to accept the risk and do nothing at all. We haven’t tackled posture validation, guest provisioning/sponsorship or Bring Your Own Device (BYOD) Onboarding. These are, of course, other suites in the Aruba ClearPass arsenal: ClearPass OnGuard for posture validation, ClearPass Guest for guest provisioning/sponsorship and ClearPass OnBoard for BYOD Onboarding - which we will tackle in future articles, boiling one pot at a time.