Cisco Secure Firewall 7.0 Release - Device Level Mapping

hello everyone welcome to this video highlighting one of the features or enhancements to the cisco secure firewall my name is christopher grabowski i am a technical marketing engineer with cisco systems this is one in the series of videos created to discuss and demonstrate the latest updates within 7.0 release of software in this video i want to talk about and show you device level mapping filters we've introduced if we look back over the last decade the firewalls have come a long way from static ip based policies to attribute-based policy today we want to construct our policies based on user role or group membership rather than static ip or subnet information for that to work we need to provide user identity mappings to firewalls in a real time the device level mapping filters allow you to control what identity mappings are distributed to individual firewalls in your deployment since 7.0 release you can configure your fmc to filter out identity mappings on the device level the filters are applicable to isc source bindings and dynamic objects the new type of attributes introduced in 7.0 if you would like to learn more about dynamic objects please check out the corresponding video in our firepower fred defense 7.0 update series in the previous releases of software fmc shared all learned identity mappings with all managed devices consequently in many cases the overall capacity of the firewall deployment was limited by the common denominator the lowest memory device managed by the fmc now having control per individual device we can distribute the bindings to firewalls in the network as needed and support more use cases than before for example we can set up fmc to share all enterprise identity mappings with the high capacity firewalls in the haddad or the campus at the same time in the remote branches we only install a small portion of the mappings relevant just for each individual site this feature can be especially useful in multi-site sda deployments or public private cloud installations device level mapping filters are configured on fmc with identity policy the mapping filters are defined by ip addresses and subnets in a network object you can set up network object overrides to customize filters on the device level let's start with a quick recap of identity mapping propagation and then we'll see how the mapping filters fit in the picture cisco fmc obtains user mappings from cisco identity services engine for that purpose we use pxgrid context sharing protocol cisco ise keeps track of end points connecting and leaving the network and maintains a table of current identity mappings or as we call them bindings depending on how isc learns about a particular endpoint we may have an sgt to ip binding user to ip binding or we could have both user and sgt to ip binding the second source of mappings are dynamic objects introduced in 7.0 dynamic objects allow you to assign single or multiple ip addresses to an object used in your security policies the dynamic objects can be created and manipulated of a rest api by a custom script or an application that keeps track of ip address changes in the network in our example we have two dynamic attributes workload a and workload b programmed on fmc by a custom script similarly to ise sourced mappings dynamic attributes are updated on the firewalls in the real time without policy deployment you can also update dynamic objects in real time with cisco provided application the cisco secure dynamic attributes connector in the first release the connector will support dynamic addresses originating from azure aws and vcenter workloads if you would like to learn more about cisco secure dynamic attributes connector please check out the corresponding video in our firepower fred defense 7.0 update series in our example we use cisco ise to share 200 000 mappings with the fmc each device managed by the fmc has a memory pool reserved for identity mappings the size of the pool depends on the model of the firewall and ranges from 64 000 on the virtual addition to 300 000 on the higher end appliances as by default the fmc shares all bindings it knows about with all managed devices we may run into capacity issues some of the firewalls may not have enough memory to accommodate all the bindings sent from the fmc in such case the firewall installs bindings up to its limits and ignores the rest this is where identity mapping filters come into play starting from 7.0 you can filter out unnecessary bindings as they are delivered to the firewalls with lower capacity the mapping filters are set with host or subnet objects and are configurable per individual firewalls or groups of devices before we switch gears to the demonstration let's briefly review the lab topology in the laboratory we have a basic firepower deployment with fmc managing a virtual firewall the pxgrid connection is established from cisco isc to fmc to provide ip to sdt mappings in turn fmc installs the binding on the firewall in the real time as we start the laboratory we will observe fmc sharing ip2sgt bindings from four different subnets 172 16.10 172 16.11 dot 12 and 13. the purpose of this demonstration is to filter out all mappings except the ones that originate from 16.12 subnet let's start with the fmc and review pxgrid configuration i'll navigate to system integrations and select identity sources we can see an ip address of primary isc server and a set of certificates already configured for the purpose of this demonstration our fmc subscribed to sxp topic only let's run a test and confirm the pxgrid connection is up and running now let's have a look at the isc to review configured ip2 sgt bindings i'll navigate to workcenters trusssec components and i'll select ip2sgt static mappings as we can see ise is configured with over 1000 ip2sgt mappings for 4 network subnets we can see entries 4.10.13.12 and 11. let's switch back to the fmc and have a look at the count of identity mappings on the managed firewall let's navigate to system health monitor and here we'll expand the ftd tab to see the snort identity memory usage details we can see that at the moment snort uses 3 percent of 15 mag memory pool reserved for identity mappings below the memory usage is broken down further to host subnet and user group mapping utilization in the binding details section we can see the firewall has 1016 bindings installed at the moment and the maximum number for this model is 64 000. next we'll have a look at the detailed list of installed bindings with cli comments on the ftd firewall itself i am now connected to the ftd console in order to review the identity mapping stored in the memory we need to instruct snort to dump the snapshot of the current list to the file system you can do it with system support firewall engine dump user identity data command the snapshot of the binding table is now saved to the disk and we need to enter root shell to review its contents a copy of the dump file can be found in detection engine directories associated with each snort 2 instance the directory name of the detection engine is dynamic so when you run this comment on your firewall please remember to substitute the name accordingly depending how many cores are available you might see one or more instances of snort 2 running on your appliance each instance will have the same set of identity mappings in the database in this example i'll review mapping file dumped by the first instance of store 2 running on my ftd the name of the file is user underscore identity dot dump this is a text file and we can easily display its content and grab through the output we can see the list containing bindings from four different subnets we've seen on isc our goal is to remove all bindings except the ones originating from 172 16.12 subnet let's switch back to fmc and configure identity mapping filters to achieve that in the policies tab we can see the access control policies targeting a single firewall and the firewall is up to date the identity mapping filters are configured in identity policy associated with the access control policy in our example we already have an identity policy applied so we'll need to modify the existing policy to enable the mapping filters notice in the identity policy configuration pane there is a new identity source type available at the moment there are no identity mapping filters set up this means that all bindings from fmc are pushed to the managed firewalls let's configure a network object to filter out unnecessary ip2sgt mappings from our firewall i'll name it my mapping filter and select 172 16.12 subnet now we need to save and deploy the policy the policy is now deployed so let's have a look at the firewall to observe mapping filters effects first let's check if the mapping filters were properly applied in the ftd cli you can check what filters were applied with show identity subnet filter command we can see that the mapping filter is set up to allow only ip mappings from 172 16.12 subnet next let's have a look at the snapshot of identity mappings i'll use the system support firewall engine dump user identity data command again now we can only see ip2sgt bindings from 172 16.12 subnet as we specified in our identity mapping filter that concludes this demonstration thanks for taking the time to watch this video update with me stay tuned for more content covering new cisco secure firewall features see you soon you

Channel: Cisco Secure Firewall

Views: 944

Keywords: Cisco, Secure, Firewall, NGFW, FTD, Identity, Device Level Mapping, 7.0, 7.0 Release, Cisco Secure, Netsec, Identity Mapping, Cisco Secure 7.0 Release

Id: 3fLqJEduvN0

Length: 13min 10sec (790 seconds)

Published: Mon May 24 2021