How often do you buy something spontaneously, succumbing to cool advertising, and then this initially desired thing gathers dust in a closet, pantry or garage before the next general cleaning or moving? As a result, disappointment due to unrealistic expectations and wasted money. It is much worse when this happens with a business. Too often marketing tricks are so good that companies buy 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, implementation after a competent βpilotβ will bring engineers much less destroyed nerve cells and gray hair. Let's see why pilot testing is so important for a successful project, using the example of a popular tool for controlling access to a corporate network - Cisco ISE. Consider both typical and completely non-standard options for applying the solution that we encountered in our practice.
Cisco ISE - Radius Server on Stereos
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 was nicknamed the "Radius server on steroids" for its properties. Why is that? In essence, the solution is a Radius server, to which a huge number of additional services and βchipsβ are attached, 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 access-level network equipment, collects information about all attempts to connect to the corporate network, and, based on authentication and authorization policies, allows or does not allow users to access 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.
Implementation cannot be piloted: why do we need testing?
The value of pilot testing is to demonstrate all the capabilities of the system in a specific infrastructure of a specific organization. I am convinced that piloting Cisco ISE before implementation is beneficial for all project participants, and here's why.
For integrators, this gives a clear idea of ββthe customer's expectations and helps to form the correct terms of reference, containing much more details than the common phrase "make everything go well." "Pilot" allows us to feel all the pain of the customer, to understand which tasks are priorities 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, at what sites, where they are located, and so on.
Customers, during pilot testing, see the real system in action, get acquainted with its interface, can check whether it is compatible with their existing hardware, and get a holistic view of how the solution will work after full implementation. The "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 "surface" during the "pilot"
So how do you properly prepare for a Cisco ISE implementation? 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 upline. Each option has advantages and disadvantages. For example, the strength of a physical upline is predictable performance, but we must not forget that such devices become obsolete over time. Virtual uplines are less predictable because depend on the hardware 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 upgraded almost the entire fleet of access level switches to modern Cisco equipment. To avoid unpleasant surprises, it is worthwhile to find out in advance the proportion of unsupported equipment.
Are all your devices generic?
In any network, there are typical devices that should not be difficult to connect: workstations, IP phones, Wi-Fi access points, video cameras, and so on. But it also happens that non-standard devices need to be connected to the LAN, for example, RS232 / Ethernet bus signal converters, uninterruptible power supply interfaces, various technological equipment, etc. It is important to determine the list of such devices in advance so that at the implementation stage you already have an understanding how technically they will work with Cisco ISE.
Constructive dialogue with IT specialists
Security departments often serve as Cisco ISE customers, while IT departments are usually responsible for configuring access layer switches and Active Directory. Therefore, the productive interaction of security and IT specialists is one of the important conditions for the painless implementation of the system. If the latter perceive the integration "with hostility", it is worth explaining to them how the solution will be useful to the IT department.
Top 5 Cisco ISE Use Cases
In our experience, the necessary functionality of the system is also revealed at the stage of pilot testing. Below are some of the most popular and less common use cases for the solution.
Secure LAN access over the wire with EAP-TLS
According to the research results of our pentesters, attackers quite often use ordinary sockets to which printers, phones, IP cameras, Wi-Fi points and other non-personal network devices are connected to penetrate a company's network. Therefore, even if network access 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 brute a certificate - for this, hackers will need much more computing power, so this case is very effective.
Wireless Dual-SSID
The essence of this scenario is to use 2 network identifiers (SSID). One of them can be conditionally called "guest". Through it, both guests and employees of the company can enter the wireless network. The latter, when trying to connect, 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 detect the type of connected device and apply the correct restrictions to it. Why is he interesting? The fact is that there are still quite a few devices that do not support 802.1X authentication. Therefore, you have to let such devices into the network by MAC address, which is quite easy to fake. This is where Cisco ISE comes to the rescue: with the help of the system, you can see how a device behaves on the network, create a profile for it, and associate a group of other devices with it, for example, an IP phone and a workstation. If an attacker tries to spoof the MAC address and connect to the network, the system will see that the device profile has changed, signal suspicious behavior, and prevent the suspicious user from accessing the network.
EAP Chaining
EAP-Chaining technology involves sequential authentication of the work PC and user account. This case has become 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 into the network, or will come in, but with certain restrictions.
posturing
In this case, we are talking about assessing the compliance of the composition of the workstation software with the requirements of information security. Using this technology, you can check if the software is up to date on the workstation, if protection tools are installed on it, if the host firewall is configured, etc. Interestingly, this technology also allows you to perform other non-security tasks, such as checking for the presence of necessary files or installing system-wide software.
Less common are also Cisco ISE use cases such as access control with end-to-end domain authentication (Passive ID), SGT-based micro-segmentation and filtering, as well as integration with mobile device management (MDM) systems and vulnerability scanners (Vulnerability Scanner).
Non-standard projects: why else might you need Cisco ISE, or 3 rare cases from our practice
Control access to Linux-based servers
Once we solved a rather non-trivial case for one of the customers who had already implemented the Cisco ISE system: we needed to find a way to control user actions (mostly admins) on servers with Linux installed. In search of an answer, we came up with the idea to use the free software PAM Radius Module, which allows you to log into servers running Linux with authentication on an external radius server. Everything in this regard would be fine if not for one βbutβ: when sending a response to an authentication request, the radius server returns only the account name and the result - assess accepted or assess rejected. Meanwhile, for authorization in Linux, you need to assign at least one more parameter - home directory, so that the user at least gets somewhere. We didn't find a way to pass this as a radius attribute, so we wrote a special script to create remote 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 large. Next, users went to the required device, after which they were assigned the necessary access. A reasonable question arises: is it necessary to use Cisco ISE in such cases? In fact, no - any radius server will do, but since the customer already had this system, we simply added a new feature to it.
Hardware and software inventory on the LAN
Once we worked 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 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 still let the user into the network, collected information about him and recorded it in the ISE database. This monitoring of the network over the course of several weeks helped us to isolate connected systems and non-personal devices and develop an approach to segment them. After that, we additionally set up post-schering to install 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 the workstations. I will not hide the further tasks of distributing users by domain groups and delimiting access rights took us 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, it was not difficult due to the good work of profiling out of the box. Well, and where profiling did not help, we looked ourselves, highlighting the switch port to which the equipment was connected.
Remote installation of software on workstations
This case is one of the strangest in my experience. Once a customer contacted us with a cry 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 2000 computers, which, in the absence of a domain controller, were managed from an administrator account. For the purpose of scheduling, the organization implemented Cisco ISE. It was necessary to somehow understand whether an antivirus was installed on the existing PCs, whether the software environment was updated, etc. And since IT administrators brought network equipment into the system, it is logical that they had access to it. After seeing how it works and post-scheduling their PCs, the administrators came up with the idea of ββinstalling software on employee workstations remotely without personal visits. Just imagine how many steps you can save in a day! The admins performed several checks of the workstation for the presence of a certain file in the C: Program Files directory, and if it was absent, automatic remediation was launched with a link leading to the file storage to the .exe installation file. This allowed ordinary users to go to the file ball and download the necessary software from there. Unfortunately, the administrator did not know the ISE system well and damaged the post-schering mechanisms - he wrote the policy incorrectly, which led to the problem that we were involved in solving. Personally, I am sincerely surprised by such a creative approach, because it would be much cheaper and less labor-intensive to create a domain controller. But as Proof of concept it worked.
Read more about the technical nuances that arise when implementing Cisco ISE in the article of my colleague .
Artem Bobrikov, Design Engineer, Information Security Center, Jet Infosystems
Afterword:
Despite the fact that this post talks about the Cisco ISE system, 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.
Source: habr.com