cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

Community Helping Community

WHITEPAPER - Firepower Threat Defense Cloud Management with Logging and Identity

515
Views
10
Helpful
0
Comments
 

Overview

 

In this paper we will document the configuration and operation of an integrated solution that includes identity management, firewall, cloud-based management, and cloud-based logging.

We will use the following Cisco products:

Function

Product

Version

Identity Management

Identity Services Engine (ISE)

2.6 Patch 3

Firewall

Firepower Threat Defense (FTD)

6.5.0.1

Management

Cisco Defense Orchestrator (CDO)

N/A

Logging

Cisco Security Analytics and Logging (SAL)

N/A

 

We will demonstrate the integration steps to configure these products to work together to deliver an end-to-end security solution that meets customer requirements for security and visibility of user identity for all network connections for a 90-day period.

 

Solution Elements

 

Identity Management - Identity Service Engine (ISE)

ISE is Cisco’s network access control solution. It provides context-based access control for wired, wireless and VPN users. It comes in both a full-featured product variant as well as a lightweight option known as ISE-PIC (Passive Identity Connector).

ISE datasheet

ISE-PIC datasheet

An ISE deployment can be one server or many servers, depending on the requirements for scale and high availability. ISE servers can be deployed as physical appliances (Cisco SNS-3xxx devices based on the Cisco UCS C-series servers) or virtual machines (VMs). Public cloud-based ISE servers are not currently offered.

For purposes of this paper we are using a single ISE server deployed as VM on a VMware ESXi server.

ISE has the concept of personas or roles. The ISE server personas include Administration, Policy Service, Monitoring, and pxGrid. While a distributed deployment can separate the personas onto different servers, a single node deployment such as we are using has all personas on one server.

There are also varying license types available for ISE. There are Base, Plus, Apex and Device Administration licenses. For the use case we examine here, Base licensing is all that is required.

Our requirement for ISE is simply to gather user identity and publish it to our Firepower device. It can gather identity in several ways. Providers include Microsoft Active Directory (AD, via WMI most often), IPAMs (IP Address Management systems), Secure Web Gateways, LDAP (these via syslog into ISE) and custom integrations (via Application Programming Interface or API). It publishes via pxGrid (Platform Exchange Grid) a Cisco-developed method that allows standardized exchange of information.

The following diagram illustrates the concept:

pic1.jpgISE Identity and pxGrid

(Source: ISE 2.6 Administration Guide)

 

Firewall - Firepower Threat Defense (FTD)

FTD is Cisco’s Next-Generation Firewall (NGFW). It is a unified image combining the classic Cisco ASA stateful firewall with the Firepower Next-Generation Intrusion Prevention System (NGIPS) technology based on the underlying Snort IPS engine that was part of Cisco’s acquisition of Sourcefire in 2014.

FTD datasheet

FTD appliances can be deployed on a broad variety of hardware platforms as well as VMs on either on-premise hypervisors (VMware ESXi and KVM) as well as in AWS and Azure public clouds. They can also be deployed in high availability pairs or in scalable clusters

For purposes of this paper we are using a single FTD virtual appliance (FTDv) deployed as a VM on a VMware ESXi server.

FTD also has varying license levels including the base Threat license, URL Filtering and Malware.  We will be using both Threat and URL Filtering license features as we can to have visibility into and control over URLs accessed by users.

As shown in the earlier diagram, FTD can integrate with ISE (or ISE-PIC) via pxGrid to ingest user identity information. Specifically, we are using it to associate user identity with observed IP addresses of traffic flows via the firewall. This integration feature is included in the base license.

Management - Cisco Defense Orchestrator (CDO)

FTD devices can be managed fundamentally via two different methods:

  1. A traditional method using Cisco’s Firepower Management Center (FMC) product or
  2. A newer modern architecture method using REST API (Wikipedia reference defining REST) and a combination of on-box Firepower Device Manager (FDM) and the cloud-based Cisco Defense Orchestrator (CDO) Software as a Service (SaaS) offering.

We will be using the second method with a combination of FDM and CDO. FDM is used for initial device configuration as well as a few settings that are not currently supported on CDO (primarily the configuration of the ISE server as an identity source). Once we have done the required bits using FDM, the remainder of day-to-day operations are done via CDO.

CDO datasheet

Besides the advantages of more scalable and multiple platform support (FTD, ASA, Meraki), another reason we are using CDO is for integration with Cisco’s cloud-based logging solution. CDO is required to use that service.

 

Logging - Cisco Security Analytics and Logging (SAL)

SAL is a recently introduced (October 2019) SaaS offering from Cisco. It fills an important role for CDO-managed FTD devices as the logging platform that ingests connection and security events from the managed devices securely and retains the events for 90 days in a Cisco-managed cloud-based service.

Prior to SAL, customers using FDM or CDO management could only see a limited set of real time events via FDM. Otherwise they had to send the events to a third-party log management tool or a SIEM for longer term retention and analysis. Customers using FMC could send events to the FMC event viewer. While it includes very rich analysis capabilities, data retention on FMC could be a challenge as even a moderate scale deployment of multiple firewalls can generate many gigabytes per day of connection records. SAL addresses those challenges with a subscription-based service offering whereby Cisco retains all ingested log data for 90 days. It can also correlate firewall logs with Netflow data for customers availing themselves of the Cisco StealthWatch Cloud (SWC) service. Both SAL and SWC use technology based on the Cisco acquisition of Observable Networks in 2017. StealthWatch is further derived from Cisco’s acquisition of Lancope in 2015.

SAL datasheet

When setting up CDO and SAL, one has the option of using on-premise virtual machines known as the Secure Device Connector (SDC) and Secure Event Connector (SEC) or connecting and sending events directly to the cloud. We will use the latter option as it is generally simpler. The direct connection is a feature that requires FTD version 6.5 or greater.

Configuration Elements

 

For purposes of this discussion, we will cover only the parts specific to the features being leveraged for this integration. We will not cover basic product setup as there are numerous other references: Cisco-published product documentation, Cisco Security Community documents and third party training and web-based resources.

ISE-FTD Integration via pxGrid

Note – first we follow this guide for basic setup for pxGrid:

https://www.ciscolive.com/c/dam/r/ciscolive/us/docs/2017/pdf/LTRSEC-2002-LG.pdf

We depart from that document since we are using FDM and not FMC management.

We will need a pxGrid certificate (i.e., one with both client and server usage indicated). For that I create a CSR externally and submit to my CA and specify the pxGrid template. We need to be sure to add the issuing CA as a Trusted CA as it is signing both our own pxGrid certificate as well as those from the ISE server certificates (both MnT and pxGrid). Deploy those certificates prior to adding the ISE identity source or else the test will fail.

pic2.pngAdding ISE Identity Source to FTD

 

On the ISE side we should see the following:

 pic3.pngpxGrid Subscriber Verification in ISE

FTD Identity Policy and Cloud management settings

Once we have a verified pxGrid connection between ISE and the FTD device, we can now add an Identity Policy to use the information published by ISE to inform the FTD logging (and, optionally, user-based policies when combined with realm integration – outside the scope of this document).

The Identity Policy needs to be done via FDM as the ISE Identity Source is not a supported feature in CDO at this time. We need to add the AD realm in order to use the ISE Identity Source.

 

pic4.pngFTD Identity Policy

 

 

Once added via FDM, we can sync with CDO and see the policy in place:

pic5.pngCDO-FTD Sync Verification

We need to ensure that we have enabled FTD to send events to the Cloud and that the Access Control Policy (ACP) is set to Log Connection Events:

 

pic6.jpgFTD Enablement of Cloud Eventing

pic7.jpgFTD ACP Logging Setting

 

Verification

 

Let’s first verify that we have identity information in ISE. In our environment we are gleaning user-IP mapping by virtue of the user having logged in to our secure WLAN and been authenticated via Active Directory (AD). We could have alternatively used any of the other ISE identity providers as mentioned earlier (e.g., syslog- or API-based providers).

WLAN client detail:

pic8.pngWLAN Client Detail

ISE RADIUS Live Log:

pic9.pngISE RADIUS Live Log

 

 

ISE Authentication Detail:

 

pic10.pngISE Authentication Detail

 

Next, confirm that FTD to ISE pxGrid operations are working:

 

pic11.pngISE-FTD pxGrid Test Verification

 

Then ensure that we are using ISE as the source in our FTD Identity Policy:

pic12.pngFTD Identity Policy

 

Finally, we confirm that user identity is appearing in the CDO-based view of SAL-ingested data.

 

pic13.pngCDO/SAL Monitoring with User Identity

 

 

Conclusion

 

From the verification section, we can see:

  1. The WLAN authenticated and authorized the user via Central Web Authentication (CWA + ISE)
  2. The WLAN record in ISE, with authorization via Active Directory
  3. pxGrid is active and working between ISE and FTD, allowing FTD to subscribe to ISE’s published “SessionDirectory” topic.
  4. The FTDv-2 firewall is the host reporting the connection to SAL/CDO with the source IP and username matching what was reported in ISE.
  5. Reporting via SAL and display in the CDO interface.

All the component parts are working together to provide an end-to-end security and visibility solution.

As noted, we could have gleaned the user information via other sources supported in ISE (LDAP, syslog, API integrations). Users could have also accessed the network via other methods such as wired connections or remote access VPN. In any of those cases, we would retrieve the user information from ISE (or ISE-PIC) similarly.

There are additional components that can be integrated but are out of scope for this paper. Examples include Cisco Umbrella (for DNS Security), Cisco Stealthwatch (for visibility and security based on Netflow data), Cisco AMP (Advanced Malware Protection) for Endpoints and Cisco Email Security Appliance (ESA).

Most of these can further be consolidated via the Cisco Threat Response (CTR) service.

 

CreatePlease to create content
Content for Community-Ad
FusionCharts will render here