You’re only as strong as your weakest link.
This old adage is especially true when it comes to network security and why role based access control is critical. You can purchase the most expensive, ridiculously feature-rich firewall on the market, install it at the WAN edge, and think that you are safe. But without internal network controls in place as well, you run the risk of someone on the inside stumbling into a restricted resource, and that has the same end result as some foreign agent breaching your perimeter. Someone got somewhere that they really shouldn’t have been allowed, and now data has been compromised.
Bring Your Own Devices (BYOD) Policies Blur Internal Network Boundaries
With the advent of BYOD and the growing appeal of wireless connectivity, the clear definition of permitted devices and internal network boundaries are becoming fuzzy. Studies from IDG, Gartner, and Forrester tell us that 85% of organizations currently allow employees to bring their own devices to work and that more than 70% of mobile professionals will conduct their work on their own smart devices by 2018. I’m personally already one of these statistics—I’m writing this at home using Office 365 on a personal computer and checking my email on my personal iPhone. Static port–based security and locked corporate endpoints are no longer valid ways to protect your company, and while wireless encryption standards have come a long way, you still need a good way to control and restrict internal network access.
Why You Shouldn’t Lock Down Your Network with these Tactics
There are several commonly used methods to lock down your network, but several of these options leave something to be desired. I personally can’t recommend the use of pre-shared keys in an enterprise environment. Several hops ago in my employment journey, I worked at a place where, technically, employees were not allowed on the wireless network—it was intended for guests only. However, as I set up my cubicle on my first day, I found a piece of paper on the bookcase with the guest wireless pass phrase printed on it. It was common knowledge! I mean, it made sense—most people were issued laptops, and meetings were hosted all over the building. If you wanted to pull anything up in those meetings, you needed connectivity. So people used the wireless network against the IT department’s wishes… and because they used a pre-shared key, it would be very painful for the IT staff to change the key and then have to reset every repeat visitor’s network settings. And all it would take would be one “leak” of the new password and they’d be right back where they started. Of course, most employees didn’t have malicious intent, but what if a competitor got their hands on that pre-shared key?
At the risk of going too far into bits and bytes, using a pre-shared key also weakens the encryption used to secure your employee’s wireless communications. A PSK provides seeding material for the master session key that is used to generate unique client keys, so even while the individual keys are generated dynamically there is common thread tying them together. Someone with sophisticated tools and knowledge of the PSK could potentially crack another client’s communication and start eavesdropping undetected.
Another less than ideal method to control network access is via SSID segmentation. This involves setting up multiple SSIDs and assigning a VLAN to each network. One SSID can be assigned for employees, one for guests, one for contractors…and so on, and so on. The VLANs combined with their respective ACLs ensure that everyone has the appropriate permissions. While this gives you some level of control over network traffic, there are some downsides. Significant overhead is required with each SSID in play, as each SSID has to transmit beacon information at a slow data rate to ensure that clients can discover and connect to the wireless network. Once you start reaching more than five SSIDs in a standard enterprise wireless deployment, that beacon overhead can really start to cut into available airtime for actual client traffic. Not to mention the you’re going to be continuously asked by frustrated employees which SSID they should be using!
Why Role Based Access Control is the Best Solution
Enter Role Based Access Control (or RBAC, to satisfy our need for entirely too many acronyms in IT). Role Based Access Control is the principle of assigning privileges based on a role inherent to the user and machine requesting authentication NOT based on what port they are plugged into or what SSID they are using. Using RBAC, a company director could access financial data regardless of what part of the building they are in—and a guest connecting to that same network would be shepherded straight to the internet, do not pass go, do not access any RFC 1918 space, definitely don’t collect $200. Conversely, thanks to device fingerprinting, that same director could be allowed access to an internal server when using their corporate-provided laptop, but be denied access if they request access from a personal (and potentially unsecure) device.
How to Get Started with Role Based Access Control
So how do you get started? First, you will need an 802.1X/EAP framework. There are three primary components in the 802.1X framework—supplicants, authenticators, and authentication servers. Laptops, desktops, iPhones, Androids—any device connecting to your network—is considered a supplicant. When they first connect to an 802.1x network, they are only given extremely limited L2 access…and by that, I mean that literally all they can do is submit their credentials for inspection. They can’t even get a DHCP address! The supplicants send their credentials up to the authenticator, which is commonly a switch, autonomous AP, or WLAN controller. The authenticator can be compared to a bouncer at a club. They don’t make the guest list, but they sure can enforce it! The authenticator relays the supplicant’s credentials to the authentication server in a secure RADIUS session. Depending on whether or not the authentication server approves the credentials, the server returns an ACCESS-REJECT or ACCESS-ACCEPT message back to the authenticator. If the supplicant is accepted the encryption keys are generated and the supplicant granted access.
Conveniently, most authentication servers are able to use LDAP to query an existing Active Directory database. This can greatly simplify the installation, because each employee should already be aware of their AD credentials.
Now, here’s where it can get fun. Multiple Vendor Specific Attributes (VSAs) can be included alongside the RADIUS ACCESS-ACCEPT message, determining network permissions for each supplicant! Using these attributes, the authenticator can take actions like enforcing bandwidth limitations, implementing user specific ACLs, making dynamic VLAN assignments, and more. In the case of the Aruba ecosystem, each supplicant can have its own full set of application-aware traffic shaping policies assigned and enforced.
So, ignoring all the acronyms and “tech speak,” what can this mean for your business? Let’s briefly walk through accessing a network using RBAC on a single SSID. When Bob the intern connects, he has to type in his unique username and password—in this case, he is using his AD credentials. These credentials will be referenced against the specified database, approved, and the controller will give Bob network permissions that are appropriate for an intern. He may be able to use work-approved applications, but he will be prevented from accessing specific servers and his streaming bandwidth will be throttled. Regardless of where Bob moves on the network—wired or wireless—these policies will follow him. But when Nancy the CEO connects to this same network, the system recognizes that she is the CEO and as such she can go where she pleases! She is given unrestricted and prioritized access. Beyond the submission of user name and password, this all happens transparently to the user…and thanks to interim accounting via RADIUS, you can keep a full log of the transactions and connection states!
To summarize, a well-integrated RBAC system is much more streamlined and secure than static pre-shared keys or port-based access control lists. Sure, there can be more work and planning involved during the initial setup, but it can bring great benefits to your organization. If you’d like to learn more about implementing RBAC or if you would like help designing a system for your unique organization, please contact us, or give us a call at 888-861-8884.