Network security is often delegated to singular devices within the network. For instance, you might allow unfettered access for all endpoints within the core of your corporate network and enforce the access policy at the edge firewall. For your wireless users, you might choose to enforce a singular policy for all users allowing every wireless user access to HTTP, HTTPS, SSH, and Telnet and implementing this policy at the access point (autonomous mode) or at the Wireless LAN Controller (lightweight mode). This “one-size-fits-all” approach is not the ideal way to implement network security.
The growing "Bring Your Own Device" culture also presents a new set of problems. By allowing the employees to bring their own devices, you are basically trusting them to make sure that their machine is not compromised, has an Antivirus/Anti-Malware solution installed, has the latest security updates, etc. It is important to be able to control what devices are able to connect to your corporate network and what level of access is granted to them. This again calls into question our traditional approach to network security and requires a more granular control of our security policies. While BYOD culture has given headaches to a lot of IT departments, it has highlighted an often overlooked aspect of security, i.e. securing our networks not just from external security threats, but also internal ones.
Cisco ISE helps facilitate this paradigm shift of making the network and not just a single device the enforcement point for network security. This is made possible via the Authentication, Authorization and Accounting (AAA) services provided by RADIUS. Cisco ISE acts as a centralized network security policy platform and RADIUS server, extending the AAA functionality to all devices. When a user or an endpoint tries to connect to the network, the Network Access Device (Switch, Wireless LAN Controller) forwards the request to Cisco ISE. Cisco ISE responds to the NAD with the resulting security policy to be applied to the user or the endpoint by using RADIUS attributes. By tightly coupling the authorization of the user with authentication, ISE can provide differentiated network access to all users based on their roles in the organization.
Besides the basic functionality as a RADIUS server, Cisco ISE also provides several advanced features such as profiling and posturing. Profiling can dynamically identify endpoints and can determine the manufacturer of the endpoint, the function of the endpoint (phone, printer, camera), as well as other network level assessments of the endpoint. The result of this profiling operation can be used to create authorization policies. Where profiling uses network-level communications to determine information about the endpoint, posturing leverages the information that resides on the endpoint. Posturing utilizes a Network Access Control (NAC) agent that resides on the endpoints directly to make sure that the endpoint is adhering to the security policies such as antivirus software, OS security updates and other required software and services. If the endpoint does not adhere to the security policy, a reduced level of access can be granted to the endpoint to allow it to remediate its noncompliance before gaining access to the network.
Cisco ISE is a one-stop shop for network security policy and the features provided by ISE go beyond RADIUS, posturing and profiling. Now that we have discussed that Cisco ISE does solve a problem (or many problems), I’ll discuss one of the most common use case scenarios of Cisco ISE, some of the challenges that I have encountered in the field and how to resolve them.
802.1x Certificate Based Endpoint Authentication
One of the most exciting things about being a consultant is that I get to work with and visit different clients. How many times have I gone to a client’s office, plugged in my laptop to one of the wall jacks and have received full unfiltered access to the corporate network? If you answered “almost every time”, you are correct. At least to connect to the wireless network, I am usually required to authenticate (if not there are bigger problems) but most wired networks are completely open where anyone can plug in a rogue device and the rest I’ll leave to your imagination.
802.1x certificate based authentication solves this problem by granting wired access only to devices that are able to successfully authenticate using a valid machine certificate. For this type of deployment, all the authorized endpoints need to have certificates issued by a trusted certificate authority. This can be combined with certificate or credentials based user authentication for further security but in this blog we’ll only discuss authentication using machine certificates. Any machines that do not present a valid certificate can have a variety of actions applied to them:
- Deny access.
- Grant limited access (using anAccess Control List).
- Move the machine to a “Guest” VLAN.
The first option is simple enough and is very straightforward to configure and deploy. However, the second and the third options require a lot of planning and consideration. In case of the second option, it is important to identify what resources the user should be able to access should they fail authentication.
The third option is the trickiest, and that is not because of how ISE or any other NAC solution works. The issue happens if the client connects to the network and is able to get an IP address in the access VLAN that the port is configured in. If the client then fails authentication, even though ISE will change the VLAN on the port, the supplicant (802.1x lingo for end hosts) will not restart the DHCP discovery process and will thus retain the IP address it received in the original VLAN. Any attempt to renew the IP address will force the device to authenticate again and the user will face the same problem.
The solution to this problem is to block DHCP traffic in Low Impact Mode so that the device does not obtain an IP address before authentication is complete or move to High Security Mode that only allows EAP-TLS traffic pre-authentication. With either of these options, the client will only get an IP address once authentication is complete and any VLAN changes have been made based on the authentication results.
Before I conclude this blog, here are some other “gotchas” from the field:
- Make sure to revoke all the expired certificates on the supplicants. A windows machine with both a valid and an expired certificate may fail to authenticate. There have been several attempts to resolve this bug but the best solution is to revoke or delete the expired certificates.
- If Dynamic ACLs are not working correctly, debug the EPM module to see if the switch is removing the Dynamic ACLs.
- If Cisco phones are stuck in “Registering” in closed mode, please adjust the timers for dot1x authentication.
The above issues are good examples of how the deployment of 802.1x authentication takes a lot of careful consideration and planning as there is no one size fits all deployment guide. Each environment is different and presents its own set of challenges. From adjusting the authentication timer values to whitelisting devices not capable of doing 802.1x authentication, the knowledge and experience of the technologies, the challenges they present and lessons learned from the field prove to be invaluable for a smooth deployment.
Cisco ISE definitely solves and addresses a lot of security problems that were previously either overlooked or ignored for a lack of a better solution. At LookingPoint, we pride ourselves at having deployed Cisco ISE successfully for many of our clients. If you can relate to some of the problems that Cisco ISE can solve or are curious about how ISE can help secure your environment and even help you meet various compliance requirements, please reach out to us and we’ll be happy to discuss your individual needs and tailor a solution for your individual needs.
Written By: Waqas Bashir, Senior Network Engineer
If you are interested in LookingPoint installing ISE into your network, feel free to contact us here!
