Testing will show: how to prepare for the implementation of Cisco ISE and understand what features of the system you need

How often do you buy something spontaneously, succumbing to cool advertising, and then this originally desired thing gathers dust in a closet, pantry or garage until the next general cleaning or moving? As a result, disappointment due to unjustified expectations and wasted money. Much worse when this happens to business. Very often, marketing tricks are so good that companies acquire an expensive solution without seeing the full picture of its application. Meanwhile, trial testing of the system helps to understand how to prepare the infrastructure for integration, what functionality and to what extent should be implemented. So you can avoid a huge number of problems due to the choice of the product "blindly." In addition, the introduction after a competent “pilot” will bring engineers much less damaged nerve cells and gray hair. Let's figure it out why pilot testing is so important for a successful project, using the example of a popular tool for controlling access to the corporate network - Cisco ISE. Let's consider both standard and completely non-standard options for applying the solution that have been encountered in our practice.

Cisco ISE - Radius Server on Steroids

The Cisco Identity Services Engine (ISE) is a platform for creating an access control system for an organization's local area network. In the expert community, the product for its properties was nicknamed the "Radius server on steroids." Why is that? In essence, the solution is a Radius server, to which a huge number of additional services and "chips" were screwed, allowing you to receive a large amount of contextual information and apply the resulting set of data in access policies.

Like any other Radius server, Cisco ISE interacts with network equipment of the access level, collects information about all attempts to connect to the corporate network and, based on authentication and authorization policies, allows or denies users access to the LAN. However, the possibility of profiling, scheduling, integration with other information security solutions can significantly complicate the logic of the authorization policy and thereby solve rather difficult and interesting tasks.

Implement can not be piloted: why do we need testing?

The value of pilot testing is in demonstrating all the capabilities of the system in a particular infrastructure of a particular organization. I am convinced that piloting Cisco ISE before deployment is useful to all project participants, and that’s why.

For integrators, this gives a clear idea of ​​the customer’s expectations and helps to formulate the correct technical task containing much more details than the common phrase “make everything all right”. “Pilot” allows us to feel all the pain of the customer, to understand which tasks are priority for him and which are secondary. For us, this is a great opportunity to figure out in advance what equipment is used in the organization, how the implementation will take place, on which sites, where they are located and so on.

During the pilot testing, customers see the real system in action, get acquainted with its interface, can check whether it is compatible with their hardware, and get a holistic view of how the solution will work after a full implementation. A “pilot” is the very moment when you can see all the “pitfalls” that you will probably encounter during integration and decide how many licenses you need to purchase.

What can "emerge" during the "pilot"

So, how do you prepare for the implementation of Cisco ISE? From our experience, we have counted 4 main points that are important to consider in the process of pilot testing the system.

Form factor

First you need to decide in which form factor the system will be implemented: physical or virtual. Each option has advantages and disadvantages. For example, the strength of physical uplining is the predicted performance, but we must not forget that such devices become obsolete over time. Virtual uplifts are less predictable because They depend on the equipment on which the virtualization environment is deployed, but at the same time they have a serious plus: if there is support, they can always be updated to the latest version.

Is your network equipment compatible with Cisco ISE?

Of course, the ideal scenario would be to connect all the equipment to the system at once. However, this is not always possible, as many organizations still use unmanaged switches or switches that do not support some of the technologies that Cisco ISE runs on. By the way, this is not only about switches, it can also be wireless network controllers, VPN concentrators and any other equipment that users connect to. In my practice, there were cases when, after demonstrating the system for full implementation, the customer updated almost the entire fleet of access level switches to modern Cisco equipment. To avoid unpleasant surprises, it is worthwhile to find out the proportion of unsupported equipment in advance.

Are all your devices typical?

On any network, there are typical devices that should not be difficult to connect to: workstations, IP phones, Wi-Fi access points, camcorders, and so on. But it also happens that non-standard devices, for example, RS232 / Ethernet bus signal converters, uninterruptible power supply interfaces, various technological equipment, etc. must be connected to the LAN. It is important to determine the list of such devices in advance so that you already have an understanding at the implementation stage, how technically they will work with Cisco ISE.

Constructive dialogue with IT specialists

Often Cisco ISE customers are security departments, with IT departments typically responsible for configuring access level switches and Active Directory. Therefore, the productive interaction of security and IT professionals is one of the important conditions for a painless system implementation. If the latter perceive integration “with hostility”, it is worth explaining to them how the solution will be useful to the IT department.

Top 5 Cisco ISE User Cases

In our experience, the necessary system functionality is also detected at the pilot testing stage. Below are some of the most popular and less common cases of using the solution.

Secure LAN Access with EAP-TLS

As the research results of our pentesters show, quite often attackers use ordinary sockets to penetrate the company’s network, to which printers, phones, IP-cameras, Wi-Fi-points and other non-personal network devices are connected. Therefore, even if access to the network is based on dot1x technology, but alternative protocols are used without the use of user authentication certificates, there is a high probability of a successful attack with session interception and password brute force. In the case of Cisco ISE, it will be much more difficult to get a certificate - for this, hackers will need much more computing power, so this case is very effective.

Dual-SSID Wireless Access

The essence of this scenario is to use 2 network identifiers (SSIDs). One of them can conditionally be called "guest". Through it, both guests and company employees can enter the wireless network. When trying to connect, the latter are redirected to a special portal where provisioning takes place. That is, a certificate is issued to the user and his personal device is configured to automatically reconnect to the second SSID, which already uses EAP-TLS with all the advantages of the first case.

MAC Authentication Bypass and Profiling

Another popular case is to automatically determine the type of device to be connected and apply the correct restrictions to it. How is he interesting? The fact is that there are still quite a few devices that do not support authentication under the 802.1X protocol. Therefore, such devices must be launched into the network by the MAC address, which is quite easy to fake. Here Cisco ISE comes to the rescue: with the help of the system you can see how the device behaves in the network, compile its profile and match it with a group of other devices, for example, an IP phone and a workstation. When an attacker tries to spoof a MAC address and connect to the network, the system will see that the device profile has changed, it will signal suspicious behavior and will not allow a suspicious user to enter the network.

Eap-chaining

EAP-Chaining technology implies sequential authentication of the working PC and user account. This case is widespread because Many companies still do not welcome the connection of employees' personal gadgets to the corporate LAN. Using this approach to authentication, you can check whether a particular workstation is a member of a domain, and if the result is negative, the user will either not get on the network or log in, but with certain restrictions.

Posturing

This case is about assessing the compliance of the workstation software with the requirements of information security. Using this technology, you can check whether the software on the workstation is updated, whether security features are installed on it, whether the host firewall is configured, etc. Interestingly, this technology also allows you to solve other tasks that are not related to security, for example, check for the presence of the necessary files or install system-wide software.

Cisco ISE usage scenarios such as pass-through domain authentication (Passive ID), SGT-based microsegmentation and filtering, as well as integration with mobile device management systems (MDM) and vulnerability scanners (Vulnerability Scanners) are also less common.

Non-standard projects: why else may Cisco ISE be needed, or 3 rare cases from our practice

Linux Server Access Control

Once we solved a rather non-trivial case for one of the customers who already had the Cisco ISE system implemented: we needed to find a way to control user actions (mainly admins) on servers running Linux. In search of an answer, we got the idea to use the free PAM Radius Module software, which allows us to log in to Linux-based servers with authentication on an external radius server. Everything in this regard would be good if it were not for one “but”: the radius server, sending a response to the authentication request, returns only the account name and the result is assess accepted or assess rejected. Meanwhile, for authorization in Linux, you need to assign at least one more parameter - the home directory, so that the user gets at least somewhere. We did not find a way to render this as a radius attribute, therefore, they wrote a special script for remote creation of accounts on hosts in semi-automatic mode. This task was quite feasible, since we were dealing with administrator accounts, the number of which was not so great. Then users went to the necessary device, after which they were assigned the necessary access. A reasonable question arises: is it mandatory to use Cisco ISE in such cases? Actually, no - any radius server will do, but since the customer already had this system, we just added a new feature to it. after which they were assigned the necessary access. A reasonable question arises: is it mandatory to use Cisco ISE in such cases? Actually, no - any radius server will do, but since the customer already had this system, we just added a new feature to it. after which they were assigned the necessary access. A reasonable question arises: is it mandatory to use Cisco ISE in such cases? Actually, no - any radius server will do, but since the customer already had this system, we just added a new feature to it.

An inventory of hardware and software in a LAN

Once we were working on a project to deliver Cisco ISE to one customer without a preliminary “pilot”. There were no clear requirements for the solution, plus everything we were dealing with a flat, non-segmented network, which complicated our task. During the project, we configured all the possible profiling methods that the network supported: NetFlow, DHCP, SNMP, AD integration, etc. As a result, MAR access was configured with the ability to enter the network if authentication failed. That is, even if the authentication was not successful, the system would still let the user into the network, collect information about him and write it to the ISE database. Such monitoring of the network over the course of several weeks helped us to identify plug-in systems and non-personal devices and develop an approach to their segmentation. After that, we additionally configured scheduling for installing the agent on workstations in order to collect information about the software installed on them. What is the result? We managed to segment the network and determine the list of software that needed to be removed from workstations. I will not hide, the further tasks of distributing users by domain groups and delimiting access rights took quite a lot of time, but in this way we got a complete picture of what “hardware” the customer had on the network. By the way, this was not difficult due to the good out-of-box profiling work. Well, and where profiling did not help, we looked at it ourselves, highlighting the switch port to which the equipment was connected. which had to be removed from workstations. I will not hide, the further tasks of distributing users by domain groups and delimiting access rights took quite a lot of time, but in this way we got a complete picture of what “hardware” the customer had on the network. By the way, this was not difficult due to the good out-of-box profiling work. Well, and where profiling did not help, we looked at it ourselves, highlighting the switch port to which the equipment was connected. which had to be removed from workstations. I will not hide, the further tasks of distributing users by domain groups and delimiting access rights took quite a lot of time, but in this way we got a complete picture of what “hardware” the customer had on the network. By the way, this was not difficult due to the good out-of-box profiling work. Well, and where profiling did not help, we looked at it ourselves, highlighting the switch port to which the equipment was connected.

Remote software installation on workstations

This case is one of the strangest in my practice. Once a customer came to us shouting for help - something went wrong during the implementation of Cisco ISE, everything broke down, and no one else could access the network. We began to understand and found out the following. The company had 2,000 computers, which were managed from a domain administrator for lack of a domain controller. For scheduling purposes, Cisco ISE was introduced in the organization. It was necessary to somehow understand whether the antivirus was installed on existing PCs, whether the software environment was updated, etc. And since the network equipment was brought into the system by IT administrators, it is logical that they had access to it. After seeing how it works, and after scheduling their PCs, admins came up with the idea of ​​installing software on employees' workstations remotely without personal visits. Just imagine, how many steps can be saved in one day! Admins conducted several checks of the workstation for the presence of a specific file in the C: \ Program Files directory, and in its absence, automatic remediation was launched with a link leading to the file storage for the .exe installation file. This allowed ordinary users to go into the file share and download the necessary software from there. Unfortunately, the administrator did not know the ISE system well and damaged post-sharing mechanisms - he wrote the policy incorrectly, which led to the problem that we were connected to the solution to. Personally, I am sincerely surprised by such a creative approach, because it would be much cheaper and less laborious to create a domain controller. But how the Proof of concept did it work. and in its absence, automatic remediation was launched with a link to the installation file .exe to the file storage. This allowed ordinary users to go into the file share and download the necessary software from there. Unfortunately, the administrator did not know the ISE system well and damaged post-sharing mechanisms - he wrote the policy incorrectly, which led to the problem that we were connected to the solution to. Personally, I am sincerely surprised by such a creative approach, because it would be much cheaper and less laborious to create a domain controller. But how the Proof of concept did it work. and in its absence, automatic remediation was launched with a link to the installation file .exe to the file storage. This allowed ordinary users to go into the file share and download the necessary software from there. Unfortunately, the administrator did not know the ISE system well and damaged post-sharing mechanisms - he wrote the policy incorrectly, which led to the problem that we were connected to the solution to. Personally, I am sincerely surprised by such a creative approach, because it would be much cheaper and less laborious to create a domain controller. But how the Proof of concept did it work. which led to the problem, to the solution of which they connected us. Personally, I am sincerely surprised by such a creative approach, because it would be much cheaper and less laborious to create a domain controller. But how the Proof of concept did it work. which led to the problem, to the solution of which they connected us. Personally, I am sincerely surprised by such a creative approach, because it would be much cheaper and less laborious to create a domain controller. But how the Proof of concept did it work.

Read more about the technical nuances that arise when implementing Cisco ISE, see my colleague 's article “Implementing Cisco ISE. The look of an engineer . "

Artyom Bobrikov, Design Engineer, Information Security Center, Jet Infosystems

Afterword :
Despite the fact that this post is about Cisco ISE, the described problems are relevant for the entire class of NAC solutions. It is not so important which vendor’s solution is planned for implementation - most of the above will remain applicable.