Cisco FirePOWER and ISE Integration
Hi habr! Starting with FirePOWER 6.0.0.0, it is now possible to integrate with the Cisco ISE central authentication and authorization corporate server. In this note, we will briefly review what exactly gives Cisco FirePOWER communication with ISE and how this connection is configured.
What is FirePOWER?
Quite a lot have written on our website in the questions / answers section:
- What is SourceFire?
- What are the advantages of FirePOWER and features of its implementation / use?
- How to run FirePOWER services on the ASA 5500-X?
What is Cisco ISE?
Written in sufficient detail on habrahabr on the Cisco corporate blog.
There is also a serious article from a Cisco engineer describing Cisco ISE usage scenarios and TrustSec architecture.
There is also a serious article from a Cisco engineer describing Cisco ISE usage scenarios and TrustSec architecture.
The integration of FirePOWER with ISE provides in the first place a new way to obtain user credentials. Prior to FirePOWER version 6.0.0.0, user authentication occurred in passive mode. This means that somewhere on the network, an agent must be installed on the computer that is part of the domain, or directly on the Active Directory (AD) server. This agent should monitor AD logs for user login / logoff events and transfer the IP address and user account correspondence to FirePOWER. The last reincarnation of this agent from SourceFIRE is called the Cisco FirePOWER User Agent.
Passive Authentication Agents
As a legacy from SourceFIRE, Cisco has received the SourceFIRE User Agent, which can integrate with the Defense Center Management System (FireSIGHT). By the way, now the current name of the FirePOWER management system looks like this: FirePOWER Management Center (FMC for short). And the agent is called the Cisco FirePOWER User Agent.
Prior to this, Cisco had its own agent options: the Cisco Active Directory Agent (AD Agent), controlled from the command line, and a later GUI solution - Context Directory Agent (CDA). These solutions could be used to provide Identity FireWall functionality on a Cisco ASA appliance. Those. on Cisco ASA, it became possible to create access lists not by IP addresses, but by accounts from AD. CDA could also be used with the Cisco ASA CX solution (this solution is no longer sold in favor of ASA + FirePOWER), with the WEB-proxy server of Cisco WSA and with the authentication and authorization server of Cisco ISE.
Prior to this, Cisco had its own agent options: the Cisco Active Directory Agent (AD Agent), controlled from the command line, and a later GUI solution - Context Directory Agent (CDA). These solutions could be used to provide Identity FireWall functionality on a Cisco ASA appliance. Those. on Cisco ASA, it became possible to create access lists not by IP addresses, but by accounts from AD. CDA could also be used with the Cisco ASA CX solution (this solution is no longer sold in favor of ASA + FirePOWER), with the WEB-proxy server of Cisco WSA and with the authentication and authorization server of Cisco ISE.
The advantage of using an agent to authenticate users is the complete transparency of the authentication process. In other words, the User Experience for the end user does not change at all when implementing authentication on a network gateway. However, this method has several disadvantages. The obvious minus lies in the approach itself: you need to install additional software that should monitor AD logs around the clock. If for some reason AD logs are unavailable, the user will not be authorized on the network device. There may also be a problem with incorrect granting of access rights. For example, if at the time a user entered the system, the PC was disconnected from the network, in theory, a new user will be able to obtain the access rights of the previous PC user if after a while he connects the PC back to the network.
Another approach is active authentication, in which the installation of an agent is not required, but users must enter their own credentials upon request. The disadvantage of this method is obvious.
Active authentication on FirePOWER has also been introduced with the release of version 6.0.0.0.
Using Cisco ISE to authenticate users on FirePOWER solves the problems inherent in both passive authentication with an agent and active authentication. As the definition implies, Cisco ISE is a centralized authentication and authorization system for users connecting to the network. As soon as the user successfully passes the authentication and authorization procedures and gains access to the network, Cisco ISE will receive complete information about this user, including the IP address of the user and his account. Further, it is enough to transfer this information to FirePOWER, or rather to the FirePOWER Management Center management system. The system will be able to map the IP address of the network transaction to the user account and apply the configured access policies.
But the functionality of Cisco ISE is not limited to authentication and authorization of users on the network. Cisco ISE allows you to profile user devices, i.e. Determine which device is connected to a specific port on a specific switch. Information about the device includes: manufacturer, OS version, device type (mobile / stationary), etc. This information can also be transmitted to FirePOWER. This makes it possible to configure different access rules for different types of devices. For example, Android and iOS have more specific limitations than Microsoft Workstation. An example of setting up a rule based on the type of device is presented below:
In addition to device profiling, Cisco ISE allows you to implement the Cisco TrustSec architecture. Very briefly, Cisco TrustSec allows you to differentiate network access by tags called Security Group Tags (SGT). The label is an arbitrary number from 1 to 65535 transmitted within the Ethernet frame. Accordingly, devices through which SGT-tagged frames pass must support TrustSec architecture. Otherwise, the label information for the network transaction may be transmitted through the Security Group Tag Exchange Protocol (SXP). Upon successful authentication and authorization procedures, the user is assigned a label that determines his access to network resources. SGT Label Description, Labeling, and Label Access Rules (SGT ACLs) are configured using the Cisco ISE. Starting with FirePOWER 6.0.0. 0 Now you can use SGT tags in FirePOWER access policies. An example of setting a rule based on the SGT label is presented below:
The last ISE attribute that can be used in FirePOWER access policies version 6.0.0.0 is Location IP. This attribute indicates the IP address of the network device that authenticated the user through Cisco ISE. Therefore, you can create different access rules for the same user, depending on which network device he is connected to (a switch or WiFi access point, or, for example, a switch at the head office or a switch at a remote branch, or, for example, user connection remotely via AnyConnect).
Before moving on to configuring FirePOWER communications with Cisco ISE, let's summarize. The integration of FirePOWER and Cisco ISE provides the following benefits:
- There is no need to use the Cisco FirePOWER User Agent to authenticate users. There is also no need for active authentication. All tasks of authentication and authorization of users in the network are undertaken by Cisco ISE.
- More accurate user identification on FirePOWER compared to using the Cisco FirePOWER User Agent.
- Using Cisco ISE attributes, namely:
- You can now use the Cisco ISE profiling results in FirePOWER access rules.
- Now you can use TrustSec tags (SGT) in FirePOWER access rules.
- It becomes possible to use the IP address of the authorizing device in FirePOWER access rules.
Configuring FirePOWER Communication with Cisco ISE
Configuration is provided for FirePOWER Management Center version 6.0.1 and Cisco ISE version 2.0.0.306. As mentioned earlier, Cisco ISE stores detailed information about authorized users on the network. The main task is to transfer the necessary information to FirePOWER.
Traditionally, when one system needs to communicate with another system, custom or proprietary APIs (Application Programming Interface) are used. Cisco offers its own technology through which the interaction of various Cisco products, as well as the connection of Cisco solutions with systems of other vendors. The technology is called the Cisco Platform Exchange Grid (pxGrid). This technology offers a common interaction language for the exchange of information between different systems, for example, FirePOWER, ISE, WSA, Cyber Threat Defense (CTD), etc.
The central component of pxGrid is the Cisco ISE. Other external systems act as clients or agents within the pxGrid and subscribe to Cisco ISE to receive or transmit information. When external systems connect to pxGrid, registering for Cisco ISE, they get the opportunity to exchange information according to the scheme "each with each", using uniform methods for this. Registration of external systems on Cisco ISE in pxGrid is carried out through digital certificates. To use pxGrid on Cisco ISE, you must have a PLUS license.
Let's move on to the settings. First Cisco ISE.
1. Activate pxGrid Persona on Cisco ISE.
Administration tab -> System -> Deployment.
Select an ISE server. Click on its name. Set the checkbox opposite pxGrid:
Click Save.
2. Get a digital certificate for pxGrid. The pxGrid service requires advanced capabilities for using the digital key, namely, authentication of both the server and the client. Therefore, the certificate used for standard ISE tasks (EAP Authentication, Admin portals, User Portals) is not suitable for pxGrid. You need to generate and sign a certificate for pxGrid on the corporate certification authority (hereinafter corporate CA). To do this, go to the Administration -> System -> Certificates tab and select Certificate Signing Requests from the menu on the left:
Click Generate Certificate Signing Request (CSR) and fill in the required fields. An example in the image below:
Click Generate and export the resulting CSR. Now we go to corporate CA and sign a CSR certificate. I will not dwell on this point in detail, just insert the screenshots:
Signed certificate received. We return to ISE, bind the certificate to CSR:
Now ISE has the necessary certificate for pxGrid:
3. You can check clients connected via pxGrid on the Administration -> pxGrid Services tab. Here we set the “Enable Auto Registration” setting:
ISE is configured. Now let's move on to pxGrid settings on FirePOWER.
4. Go to the System -> Integration -> Identity Sources tab and select Identity Services Engine as the source of identification information:
5. Fill in the required fields. You must specify the IP address or ISE server name:
6. Specify the certificates "pxGrid Server CA" and "MNT Server CA". You can use the root CA certificate for these certificates:
7. Indicate the certificate and the key "FMC Server Certificate". This FirePOWER Management Center certificate will be presented by Cisco ISE when trying to connect to pxGrid. To get this certificate, you need to generate a CSR on FirePOWER, sign it on the corporate CA and upload the received signed certificate to FirePOWER. To do this, generate a key pair and CSR from the FMC command line using the openssl utility:
I used the following line of parameters to create the CSR and Private Key:
req -batch -new -newkey rsa:2048 -nodes -keyout fp.key -subj '/C=RU/ST=Moscow/L=Moscow/O=CBS/OU=Computers/emailAddress=uskov@cbs.ru/CN=fmc/CN=cbs/CN=com/CN=ru' -out fp.csr
Further on CSR it is necessary to sign the certificate on corporate CA. The procedure is exactly the same as the process of obtaining the pxGrid certificate for ISE. We import the signed certificate to the FirePOWER Management Center. Objects tab -> Object Management PKI menu -> Internal Certs:
Click Add Internal Cert, select the signed certificate and Private Key:
Certificate and key "FMC Server Certificate" is ready. Go back to the System -> Integration -> Identity Sources tab and select Identity Services Engine. Specify "FMC Server Certificate":
8. In the same menu, click Test. The Success window should appear:
9. Do not forget to click Save in the upper right corner:
10. Return to ISE, check the Administration -> pxGrid Services tab. We see new pxGrid clients have appeared: We’ll check the
operability of the configured solution. Cisco ISE is configured to authenticate a test segment of a wired network. Cisco ISE policy settings will not be considered in this article. Using a laptop, we’ll connect to a wired network and use the Cisco AnyConnect Network Access Manager (NAM) as a saplicant:
In the ISE logs, check the Radius Livelog (Operations -> RADIUS Livelog tab):
Authentication was successful. Now let's check User Activity on FirePOWER (Analysis -> Users -> User Activity tab):
If you scroll the User Activity output to the right, you can see that the FirePOWER Management Center received additional attributes from ISE: Security Group Tag, Endpoint Profile and Endpoint Location:
On In this section, I complete the description of the configuration of ISE and FirePOWER integration. I hope this material will be useful to readers.
If this topic is of interest, welcome to our demo stands on Cisco ISE , Cisco FirePOWER .