BRKSEC-3121 Read It

#CLMEL
Firepower Threat Defence:

Advanced Capabilities,
Deployment and
Troubleshooting Options
Charlie Stokes, Technical Marketing Engineer

BRKSEC 3121
#CLMEL
Cisco Webex Teams
Questions?
Use Cisco Webex Teams (formerly Cisco Spark)
to chat with the speaker after the session
How
1 Open the Cisco Events Mobile App
2 Find your desired session in the “Session Scheduler”
3 Click “Join the Discussion”
4 Install Webex Teams or go directly to the team space
5 Enter messages/questions in the team space
cs.co/ciscolivebot#BRKSEC-3121
© 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 3
Agenda • FTD Architecture Overview and Update
• Jumbo flow handling
• Policy Apply and Snort Restarts
• Management Architecture
• Flex Configs and Use Cases
• TLS Decryption
• Deployments
#CLMEL BRKSEC-3121 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 4
Firepower Threat Defence:
Architecture Overview and
Update
FTD Overview
Advanced Inspections Plane

Snort Snort Snort Snort Snort Snort Snort Snort …… Snort
PDTS Rings PDTS Rings PDTS Rings PDTS Rings PDTS Rings PDTS Rings PDTS Rings PDTS Rings PDTS Rings
R
X
T
X
R
X
T
X
R
X
T
X
R
X
T
X
R
X
T
X
R
X
T
X
R
X
T
X
R
X
T
X …… R
X
T
X
System Processes FTD Data-Plane

Other processes
Config
Data Plane
(ASA)
Data Plane
(ASA)
Data Plane
(ASA)
Data Plane
(ASA) …… Data Plane
(ASA)
User Identity Dispatcher
RAM
Eventing
Deployment ……
and
Manager
Reporting
Management Interface 1 Interface 2 Interface 3 Interface 4
FTD CPU Core Allocation
• Firepower uses Hyper Threading to double logical cores on x86
• Firepower 2100 runs Data Plane on dedicated NPU, Snort on x86
• Firepower 4100/9300 split cores between System, Data Plane, and Snort
Total x86 Application System Lina Snort

Platform
Cores Cores Cores Cores Cores
Firepower 4110 24 22 2 8 12
Firepower 4120 or 48 46 2 20 24
9300 SM-24
Firepower 4140 or 72 70 2 32 36
9300 SM-36
Firepower 4150 or 88 86 2 36 48
9300 SM-44
SFDataCorrelator dynamically borrows cores from Snort for file processing

Monitoring System Utilisation
• Lina ftd# show cpu detailed

Break down of per-core data path versus control point cpu usage:
Core 5 sec 1 min 5 min Control Plane
Data Plane (most Core 0 2.0 (2.0 + 0.0) 1.1 (1.1 + 0.0) 0.9 (0.9 + 0.0) (network control and
transit traffic) Core 1 3.2 (3.2 + 0.0) 1.8 (1.8 + 0.0) 1.5 (1.5 + 0.0) application inspection)
[…]
Core 35 0.0 (0.0 + 0.0) 0.0 (0.0 + 0.0) 0.0 (0.0 + 0.0)
• Snort ftd# show asp inspect-dp snort

SNORT Inspect Instance Status Info
Id Pid Cpu-Usage Conns Segs/Pkts Status

tot (usr | sys)
-- ----- ---------------- ---------- ---------- ----------
Inspection Load 0 47430 1% ( 1%| 0%) 621 0 READY
1 47434 0% ( 0%| 0%) 610 0 READY Processing State
[…]
Load Distribution 45 47474 2% ( 2%| 0%) 572 0 READY
FTD Management Interface
‘show int ip brief’
SFtunnel between
FMC/FTD is
terminated on br1 ‘show network’
• FTD physical Management interface is divided into 2 logical sub-interfaces:

• diagnostic
• br1*
• As of 6.3, syslog can now be sent using any interface (mgmt. or data) even
messages from Lina that used to require the diagnostic interface
REFERENCE
ONLY
FTD Management Interface
• FTD br1 vs diagnostic sub-interface comparison
br1 diagnostic
Purpose • Used in order to assign the FTD IP that will be • Provides remote access to ASA engine CLI
used for FTD/FMC communication (SFtunnel) • Used as a source for ASA syslog, AAA messages etc.
• Provides SSH access to the FTD box
Mandatory Yes, since it is used for FTD/FMC communication No and it is actually not recommended to configure it.
(SFtunnel terminates on it) The recommendation is to use a data interface instead*
Verification From CLISH CLI: From ASA CLI:

> show network firepower# show interface ip brief
=======[ br1 ]======= Interface IP-Address OK? Method Status Protocol
State : Enabled ...
Channels : Management & Events Management1/1 192.168.1.1 YES unset up up
MAC Address : 18:8B:9D:1E:CA:7B
----------------------[ IPv4 ]-----------------
-----
Configuration : Manual
Address : 10.62.148.29
Netmask : 255.255.255.128
Broadcast : 10.62.148.127
FTD Configuration
R
X
T
X
R
X
T
X
R
X
T
X
R
X
T
X
R
X
T
X
R
X
T
X
R
X
T
X
R
X
T
X …… R
X
T
X
System Processes FTD Data-Plane

Other processes
Config
Data Plane
(ASA)
Data Plane
(ASA)
Data Plane
(ASA)
Data Plane
(ASA)
User Identity
Dispatcher RAM
Eventing and Deployment ……

Reporting Manager
FMC
SF Tunnel
FTD Packet Flow Overview
R
X
T
X
R
X
T
X
R
X
T
X
R
X
T
X
R
X
T
X
R
X
T
X
R
X
T
X
R
X
T
X …… R
X
T
X
5
System Processes 4
RAM FTD Data-Plane
Other processes 3
Config
…… Data Plane
(ASA)
Data Plane
(ASA)
Data Plane
(ASA)
Data Plane
(ASA)
User Identity
Dispatcher
Eventing and Deployment

Reporting Manager 6
2
7
1
REFERENCE
ONLY
Modifications to ASA Based Data-Plane
• DP threads poll on local RX

queues first, exhausting local
work before polling remote RX
queues
• PDTS only load balances to local
Snort instances
FTD Packet Processing – The Big Picture
1. A packet enters the ingress interface and it is handled by the ASA engine
2. If the policy dictates so the packet is inspected by the Snort engine
3. Snort engine returns a verdict for the packet
4. The ASA engine drops or forwards the packet based on Snort’s verdict
• Snort engine runs 6.x code
• ASA engine runs 9.X.x code
Prefilter Policy
• First access control phase in Data Plane (Lina) for each new flow
• Block: Deny the flow without any further processing
• Fastpath: Allow and process entirely in Data Plane, attempt Flow Offload
• Analyse: Pass for evaluation in Main AP, optionally assign tunnel zone
• Non-NGFW traffic match criteria
• Cannot copy/migrate directly to Main AP
• Use correctly -- not a “high performance” substitute to NGFW policies

• Limited early IP blacklisting
• Tunneled traffic inspection
• Allowing high-bandwidth and low latency trusted flows (Flow Offload)
Flow Offload
• Programmable Smart NIC on Firepower 4100 and 9300 only
• Every Fastpath-ed TCP/UDP/GRE flow in Prefilter is offloaded

• Flows with application inspection and certain TCP options are
exempt
• Up to 40Gbps of UDP and 21Gbps of TCP; down to 3.5us UDP
latency
• Only intended for long-lived high-bandwidth and low-latency
flows
• Finite capacity at 2M entries; overflow affects performance
• Huge performance impact with high CPS and short-lived flows
Flow Offload Operation
Full Inspection
• Dynamically program Offload engine after flow establishment
• Ability to switch between Offload and full inspection on the fly
Security Module
x86 CPU Complex
FTD Lina (Prefilter Policy) Snort
New and fully Offload Flow

inspected flows instructions updates
Incoming Established
Flow Classifier Rewrite Engine
traffic trusted flows
Smart NIC
Flow Offload
• Limited state tracking, NAT/PAT, TCP Seq Randomisation
• 30-40Gbps per single TCP/UDP flow, 2.9us UDP latency, 2M tracked flows
Main Access Policy
• Second (last) access control phase in Snort
• Block [with reset]: Deny connection [and TCP RST]
• Interactive Block [with reset]: Show HTTP(S) block page [and TCP RST]
• Monitor: Log event and continue policy evaluation
• Trust: Push all subsequent flow processing into Data Plane only
• Allow: Permit connection to go through NGIPS/File inspection
• Appropriate place for implementing NGFW policy rules
• Full NGFW traffic selection criteria
• Decisions may need multiple packets
Unified Access Control Policy
Policy L3/L4 L3/L4 L7 fields Action File, IPS policies
ID Source Destination
R1 S1 D1 Trust
R2 S2 D2 Deny Log
R3 S3 D3 App=Google+ Permit IPS-1, File-1

R4 S4 D4 URL=Games Warn File-2
R5 S5 D5 Permit IPS-2
ASA global access-group NGFW Access Policy

Policy L3/L4 L3/L4 Action
Policy L3/4 L7 fields Action Profiles
ID Source Dest
ID fields
R1 S1 D1 Trust
R3 … App=Google+ Permit IPS-1, File-1
R2 S2 D2 Deny, Log
R4 … URL=Games Warn File-2
R3 S3 D3 Permit
R5 … Permit IPS-2
R4 S4 D4 Permit
R5 S5 D5 Permit
REFERENCE
ONLY
FTD Packet Processing: Detailed
REFERENCE
ONLY
FTD Packet Path in Routed Mode
FTD Deployment and Interface Modes
 2 Deployment Modes:
• Routed
• Transparent } Device Modes inherited from ASA
 6 Interface Modes
• Routed
• Switched (BVI)
} Interface Modes inherited from ASA
}
• Passive
• Passive (ERSPAN)
• Inline pair Interface Modes inherited from FirePOWER
• Inline pair with tap
• Note - interface modes can be mixed on a single FTD device (routed or switched are available based on device mode)
Interface Modes - Summary
FTD interface mode FTD Deployment Description Real traffic can be
mode dropped
Full ASA and Snort
Routed Routed Yes
checks
Full ASA and Snort
Switched Transparent Yes
checks
Partial ASA and full
Inline Pair Routed or Transparent Yes
Snort checks
Routed or Transparent Partial ASA and full
Inline Pair with Tap No
Snort checks
Routed or Transparent Partial ASA and full
Passive No
Snort checks
Partial ASA and full
Passive (ERSPAN) Routed No
Snort checks
Management options for Cisco NGFW
Cisco Firepower Cisco Cisco Firepower
Device Manager Defence Orchestrator Management Centre
(FDM) (CDO) (FMC)
On-box manager Cloud Based Centralised Manager
Available on 5500-X, 2100, and
FTDv
Helps administrators enforce

For easy on-box management For centralised cloud-based consistent access policies,
of single FTD or pair of FTDs policy management of multiple rapidly troubleshoot security
running in HA deployments events, and view summarised
*For FTD release 6.4 or higher reports across the deployment
APIs Files and database

Firepower Management Centre (FMC)
Centralised management for multi-site deployments

Firepower Management Centre
Multi-domain management Firewall & AVC
Role-based access control NGIPS
High availability AMP
APIs and pxGrid integration Security Intelligence
…Available in physical and virtual options
Manage across many sites Control access and set policies Investigate incidents Prioritise response
REFERENCE
FMC Management Architecture ONLY
• Evolution of Defence Centre (pre

FMC) with CSM components
• Deploys SF config files and ASA
delta CLI
• Communicates with device over SF
Tunnel
• Receives status events (health, HA
/ Clustering, interface updates,
etc..)
Firepower Device Manager (FDM)
Integrated on-box option for single instance deployment

Firepower Device Manager
Easy set-up NAT and Routing
Intrusion and Malware

Role-based access control
prevention
High availability Device monitoring
Physical and virtual options VPN support
Set up easily Control access and set policies Investigate incidents Prioritise response
New for 6.3
FTD Multi-Instance
Demo (Start)
Firepower 6.3
Platform Capabilities Operations Visibility & Security
Multi-Instance for 4100/9300 Airgap/Export Licensing Events direct-from-device

• Flexible approach for multiple • Controlled subscription licensing for • Integrate better with other Cisco and
contexts closed networks 3rd party SIEMs
• Supports high availability, up to 14 • Export licensing for government and • Connection and IPS
instances military customers outside the United
States FQDN based access control
Higher 100GbE port density • Enables control for dynamic cloud
• Network modularisation Local Management for Midmarket based apps
• Configuration flexibility • On box manager for most mid-market
use-cases 2FA & RADIUS CoA for RA VPN in FMC
TLS HW Accelerated Decryption • Supports HA, Passive Auth with Audit • RA VPN Migration
• Higher TLS inspection throughput Logging and Connection and IPS
• Supported on all Firepower platforms syslogs from the device Cisco Security Packet Analyser
Integration
Fail-to-wire netmods for FP2100 Direct-to-Device APIs (2100 and below) • Deeper forensics analysis
• Transition NGIPS to Firepower 2100s • Automation and Orchestration for • Pivot from security events to full
MSPs packet captures
Improved Migrations • Enable Integrations
• New migration tools
Multi-Instance in FTD 6.3:
A new and better way
New in 6.3
FTD Multi-Instance Solution

• Create multiple logical FTD devices on a single module or appliance
• Complete traffic processing and management separation
• CPU/memory/disk resources are dedicated to an instance at provisioning
• Physical and logical interface and VLAN separation at Supervisor
• Supported on Firepower 4100 and 9300
FTD
FTD Instance A FTD Instance C FTD Instance D ASA Instance A (Future)
Instance B
10 CPU 6 CPU 18 CPU 12 CPU 12 CPU
Firepower 4100 or Firepower 9300 module
FTD Multi-Instance DC Use case
• Complete separation of security services protecting DC apps
• Dev and QA firewalls can overload/go offline/upgrade with out any effect on
Production or Finance/HR instances
Production
Finance/HR
FTD Instance
Development
18 CPU FTD Instance
FTD Instance Testing/QA 12 CPU
10 CPU FTD Instance
6 CPU Free cores to (re)allocate
Firepower 4100 or Firepower 9300 module
Cisco NGFW Per-Instance Policy in FMC 6.3
One access
control policy per
instance
Native Multi-context vs Multi-instance
Why did we choose multi-instance?
Benefits FTD Multi- ASA Multi-
Instance context • Simplify Engineering development
Allows tenant • Improved feature velocity
management ✓ ✕
separation • Separation of “FTD” instances
• Full tenant separation (Mgmt & Traffic)
Supports new
• Fault level isolation
features as they ✓ ✕
come out • Pre-defined and dedicated resources
• Each instance can run different
Allows individual
✓ ✕ versions of software
tenant failure
Independent • Simplified deployment and
✓ ✕
software versions operational management
Multi-Instance Scalability by Platform
• Complete separation of resources that
Maximum FTD
are assigned at boot up currently Platform
Instances
• Instances are designed such that an Firepower 4110 3

FTD instance crash, upgrade, restart, Firepower 4120 3
resize, etc. does not impact other Firepower 4140 7
instances Firepower 4150 7
Firepower 9300 (single SM-24) 7
• Active Standby HA can be configured
between identical instances on security Firepower 9300 (single SM-36) 11
modules from different chassis
Firepower 9300 (single SM-44) 14
Up to 42 HA instance pairs on 2 9300’s!
FTD Multi-Instance
Demo
Firepower 6.4
and FXOS 2.6.1
(in Beta)
New Features in 6.4 release (FXOS 2.6)
• FXOS 2.6.1 Mixed Blade Deployment
• Talos URL Database
• Unified Eventing Enhancements
• FDM and RAVPN Enhancements
• Access Control Policy Rule Hit Count
• Enhancements to Virtual Deployments
ASA and FTD on same 9300 Chassis
• Run native mode ASA on one blade and FTD in
either native or container instances on other
Firepower 9300 Chassis
blades!
Security Module 1: ASA Native
• Available with
• FXOS 2.6.1
• FTD 6.4 Security Module 2: FTD Native
• ASA 9.12.1
• Not supported with clustering in this release
Security Module 3: FTD Instances
Instance 1 Instance 2 Instance 3
Does not include ASA container support (yet)

Jumbo Flows
The Security-Performance Problem
Security
Performance
Jumbo or Elephant Flow Problem

R
X
T
X
R
X
T
X
R
X
T
X
R
X
T
X
R
X
T
X
R
X
T
X
R
X
T
X
R
X
T
X …… R
X
T
X
5
System Processes 4
RAM FTD Data-Plane
Other processes 3
Config
…… Data Plane
(ASA)
Data Plane
(ASA)
Data Plane
(ASA)
Data Plane
(ASA)
User Identity
Dispatcher
Eventing and Deployment

Reporting Manager 6
2
7
1
Managing Single-Flow Throughput
• Roughly calculated as overall throughput divided by Snort cores
• 53Gbps of 1024-byte AVC+IPS on SM44 / 48 Snort cores = ~1.1Gbps
• Similar on most high-end ASA, FirePOWER, and Firepower platforms
• Reducing impact on all flows from few superflows is more important
• “What does your security policy tell you to do?” Ideally, NGFW performance capacity must
not dictate your security policy
• Flow Offload is the right tool, Intelligent Application Bypass (IAB) isn’t
• Testing if a solution implicitly offloads is easy
• Transfer multiple benign and malicious files over a single SMB session
• Use HTTP pipelining to service multiple requests over one TCP connection
Solutions
• Bypass snort inspection for trusted flows using pre-filter policies (Flow offload)
• Tune configuration to remove avoidable inspections and optimise the configuration
• Appliances with higher RAM and faster CPUs
• Adopt an architectural approach to avoid making security compromises
• As a solution of last resort, Intelligent Application Bypass (which allows flows to be

bypassed when the device gets too busy to process them)
REFERENCE
ONLY
Intelligent Application Bypass
• Provides a semi-automated mechanism to Bypass selected traffic
• Goal is to offload trusted traffic from Snort when specific Snort instances are under
performance duress
• Target flows are identified via the 'App Id' flow labeling aspect of the Network Discovery
Policy
• Application Identification MUST be enabled in the Network Discovery Policy for IAB to act on
flows
REFERENCE
ONLY
Performance Parameters Monitored
• Drops, Processor, Latency & Rate
• Processor Utilisation as a percentage - On

average, what portion of the processor
bandwidth is being utilised.
• Packet Drops as a percentage - Expressed
as a percentage, the number of packets lost
in the input queue due to Snort processing
load
• Packet Processing Latency - The average
time that Snort takes to process a packet at
the outer-most level of processing.
• Number of Flows inspected per time period
- The rate of flows being passed through
Snort.
REFERENCE
ONLY
What Flows are Bypassed?
When Snort instance is experiencing
performance duress
• Access control policy “allows” the flow
• Flows that are labeled with at least one of
the target Applications
• Flows that exceed at least one of the Flow
Thresholds (Bytes, Packets, Duration,
Velocity)
• Flow size in kbytes
• Flow size in packets
• Flow duration in seconds
• Flow velocity in kbytes per second
When is a Flow Offloaded?
REFERENCE
ONLY
• At least one of the performance thresholds is

exceeded
• The Flow is labeled with one of the IAB target
applications
• The Flow exceeds one or more of the 'flow size'
thresholds
• A target flow will generally begin as a normal,
inspected flow and only be bypassed at some
point into the flow due to a size constraint
• A flow may generate intrusion alerts but still be
ultimately bypassed
REFERENCE
ONLY
IAB States
• OFF - Disable IAB
• TEST - IAB performs Snort Performance, locates candidate flows to be
bypassed. But only labels these candidate flows and does not actually enact
the fast-path operation
• ON - Perform and analysis and potential fast-path operations.
Other (Better!) Solution Options
• Pre-filter policies and Flow Offload
• If trusted elephant flows (like backup connections) are present, offload them to the hardware
on 4100/9300 or bypass advanced inspections by configuring pre-filter policies or trust rules
• Tune configuration to remove avoidable inspections and optimise the configuration

• Reduce the regex depth
• Enable file detection, but not malware analysis on Multimedia files
• Appliances with higher RAM and faster CPUs

• This will certainly help obtain better single flow throughputs but not by a very huge margin
• Adopt an architectural approach to avoid making security compromises

• Introduce other security products for a more comprehensive security
Policy Apply and Snort
Restart
Customer Use Case
• The Problem
• Snort may restart when policy changes are applied
• Snort restart may lead to packet drop
• The solution
• Reduce cases where Snort restarts on policy apply
• Reduce impact of Snort restarts
• Provide warnings if policy modifications will result in Snort restart
Origin of Policy Apply Challenge
• Firepower evolved as an IDS/IPS solution
• Like other IDS/IPS solutions, Firepower could “fail open” if Snort
was temporarily down
• Note that for
NGIPS (inline pairs),
packet drop can
be avoided by
using the Snort
Fail Open feature
Policy Apply Improvements
• Enhancements in 6.2.2
• Accelerate Policy Apply
• Eliminate most cases of snort restart due to Snort reconfiguration
• Eliminate most cases of snort restart due to Snort memory re-allocation
• Enhancements in 6.2.3
• Warning on policy apply will cause Snort restart
• Snort preserve connection feature added
• Enhancements in 6.3
• Eliminate restart with binary RSUs
• Eliminate most restarts do to VDB updates
Restart vs. Reload
• Snort restarts can disrupt traffic.
• Over several releases most Snort restart
scenarios have been eliminated
• To achieve this, Snort restarts are often
replaced by Snort reloads.
• Reloads use a separate reload thread to
rebuild the snort configuration
• In 6.3, Snort restarts are eliminated 3

scenarios
• FMC must be 6.3. FMC managed
devices can by any supported release
• Locally managed devices (FDM) must be
6.3
Scenarios Addresses in 6.2.2 (Slide 1 of 2)
6.2.2/6.2.3
Scenarios Addresses in 6.2.2 (Slide 2 of 2)
6.2.2/6.2.3
Notes on Remaining Snort Restart Triggers
Snort Restart Scenarios that Remaining in 6.2.3
Policy changes Policy action
Talos VDB Updates Installing/Deploying VDB updates that do not involve App-id detectors
VDB Installation on FMC Installing VDB on FMC causes restarts on all sensors
Eliminate restart during installing SRU Binary Updates, or provide sufficient options to
SRU with Binary Updates
skip installing binary-only updates
File Policy options Enabling/Disabling File policy options that extract files (see notes for details)
SSL Policy Turning on/off SSL policy
Captive Portal Turning on/off Captive portal
Custom App Detectors Creating/Modifying/Activating custom app detectors
VDB updates with new app detectors VDB updates with for App-id detectors (binary changes)
Some MTU changes When maximum MTU across all interfaces changes
Network Discovery advanced options Enabling/Disabling ’Traffic Based Detection’ for Users for protocols: (mdns, ftp & http)
FTD-HA Setup/Breaking Setup or Break HA on FTD

Snort Preserve Connection (6.2.3)
• Already available in 6.2.0.2
• Will not be backported to 6.2.1 or 6.2.2
• Enabled by default
• Snort informs Lina about existing to preserve
• Flows start when Snort is down will still be blocked
• Flows must satisfy the following conditions
• AC rule match where the action is not blocking or resetting the connection
• Traffic must not be tunneled
• Traffic must not be proxied. Examples: SSL Inspection, Safe Search
Snort Restart on SRU with Binary Rules
• SRUs are either plain text or shared objects
• Most are plain text.
• Some are compiled shared objects called binary rules.
• Before 6.3, installing binary rules would cause a Snort restart
• Text based rules only caused a Snort reload
• In 6.3, installing any rules only causes a Snort reload
• Feature applies to both manual and automatic SRUs
• During Snort reload, SRU binary shared objects are dynamically linked
Snort Restarts Due to VDB Updates
• Before 6.3
• Snort restarted when any VDB update was installed. Device is marked as out-of-date.
• Snort restarted again when the policy change is deployed.
• In 6.3, Snort is not restarted or reloaded when VDBs are installed.

• In 6.3, the device is only marked as out-of-date for some VDB updates.
• For VDB updates that do not contain application detector updates (Talos VDB updates):
• The device is not marked as out-of-date so there is nothing to deploy.
• Hence no Snort restart.
• For VDB updates that contain application detector updated (non-Talos VDB updates)
• The device is still marked as out-of-date
• Snort will still restart when the policy changes are deployed.
Snort Restart Warnings Due to VDB Updates
• In 6.3, if Snort will restart during deploy (non-Talos updates), the
administrator is warned twice.
• When VDB update is chosen for
installation
• In the Deploy Policies page
Snort Restart Scenarios Remaining in 6.3
Policy changes Details
Non-Talos VDB updates Deploy VDB updates with application detector updates
Custom Application Detectors Creating/Modifying/Activating custom application detectors
Enabling/Disabling file policy features that change the number of Snort instances:
File Policy options
Spero analysis, dynamic analysis, local malware analysis, store files
SSL Policy Turning on/off SSL policy
Captive Portal Turning on/off Captive portal
Some MTU changes When maximum MTU across all interfaces changes
Network Discovery advanced options Enabling/Disabling ’Traffic Based Detection’ for Users for protocols: (mdns, ftp & http)
FTD-HA Setup/Breaking Setup or Break HA on FTD
Minimum
Architecture
and Minimum
Bandwidths
FTD Configuration Deployment Process
Firepower Management 1. Configuration bundle built for Lina
Centre (limited syntax validation) and Snort
2. Configuration 3. Configuration
bundle ready bundle download
FTD 1 FTD 2
Configuration Communications Configuration Communications
Manager (CCM) Manager (CCM)
4. Configuration 8. Snort configuration

deployment requested applied
HA/CCL
Configuration Configuration
Dispatcher (CD)
Snort Dispatcher (CD)
Snort
5. Configurations 7. Lina configuration applied,

applied to Lina/Snort 6. Configuration bundle Snort bundles passed to CD
replicated in HA/cluster
Data Plane (Lina) Data Plane (Lina)
Management Communication Elements
Data Transfer
Item Typical Package Size Default Timeout
Direction
Device • 1-10MB depending on
Configuration and FMC→FTD features 5 minutes
SRU • Up to 1MB added for SRU
• 20MB for low-end platforms

URL Database FMC→FTD • 40-450MB for high-end 60 minutes
platforms
• 10 minutes under
Asynchronous VDB 10MB
FMC→FTD • 30-70MB every ~6 weeks
Updates • 60 minutes under
4GB
Software Patch and
FMC→FTD • 300MB-1GB 60-100 minutes
Upgrade Images
• Average 700 bytes per event
Security Events FTD→FMC N/A
• URL sizes are highly variable
FMC Link Bandwidth Requirements
• Image file transfer is the bottleneck in terms of minimum bandwidth
• 700Kbps-2.5Mbps depending on platform and bundle size
• Consider manual image upload with SCP or SFMGR
• Configuration bundle size varies based on features
Policy Type Bundle Size Minimum Bandwidth

1 IPS Policy (Balanced Security and Connectivity) 1.8MB 52Kbps
2 IPS Policies (No Rules + Balanced Security and Connectivity) 2.3MB 66Kbps
4 IPS Policies and Minimal AC Policy (All 4 default IPS + 3 AC Rules) 5.3MB 151Kbps
4 IPS Policies and Medium AC Policy (All 4 default IPS + 1000 AC Rules) 7.8MB 221Kbps
4 IPS Policies and Extra Large AC Policy (All 4 default IPS + 5000 AC rules) 8.2MB 234Kbps
4 IPS Policies and Enormous AC Policy (All 4 default IPS + 10000 AC rules) 9MB 255Kbps
FMC Scalability
• FMC managed device scalability is primarily driven by events volume
• 100K CPS can generate at least 200K connection events per second
• Delayed FMC event processing may cause backpressure on FTD device
Disk Usage:0 - Disk Test 2017-09-01 12:21:53 Drain of unprocessed
events from Connection Events
• Basic network audit data can be sent from Lina to an external SIEM
• Configure NSEL with FlexConfig
• Enable syslog and connection messages under Device policy
FTD/FMC Communication
FMC  FTD
0- 10MB depends on policy push, SRU
Device configurations updates adds up to 1MB 5 min
20-450MB of full package, 20-80MB of 10 minutes for files under 10MB;60

URL database incremental (platform dependent) minutes for files under 4GB
Asynchronous VDB 10 minutes for files under 10MB;

30-70MB every ~6 weeks
updates 60 minutes for files under 4GB
Software Patches and

300MB-1GB Avg.(100min) depends on platform
Upgrade Images
FTD  FMC
Events 700 bytes per event on average, but highly
NA
variable
High Bandwidth FMC to FTD Communications
• The most bandwidth intensive operations are software patch and
upgrades
• FMC status is transmitted every 10 mins
• Upgrades require about 400 Kbps of lossless between managed device
and FMC
• Recommended to perform remote upgrade using out of band
management
• URL database updates require a minimum of 45 Kbps
• Typical size is 20 MB of data
• This would take about an hour at 45 Kbps
FTD/FMC Link Bandwidth Requirements
Policy Type Package Size Minimum Link Bandwidth
1 IPS Policy (Balanced Security and

1.8MB 48Kbps
Connectivity)
2 IPS Policies (No Rules + Balanced
2.3MB 62Kbps
Security and Connectivity)
4 IPS Policies and Minimal AC Policy
5.3MB 142Kbps
(All 4 default IPS + 3 AC Rules)
4 IPS Policies and Medium AC Policy
7.8MB 208Kbps
(All 4 default IPS + 1000 AC Rules)
4 IPS Policies and Large AC Policy (All
7.9MB 211Kbps
4 default IPS + 2000 AC rules)
Flexconfigs
Inter-site Clustering on FTD
• Inter-site clustering supported on FTD
• Site IDs can be configured from
Firepower Chassis Manager
• Will need FlexConfig to configure per
site IP and per site MAC
Internet Link
Resiliency
Customer Use Case #1
• Customer has a Leased line that should be used as the primary Internet connection.
• In case the primary connection is down, use the secondary connection via a DSL modem
until the primary link is restored.
Route Tracking
1 2 3
Customer Use Case #2
FTD
• Customer has multiple internet connections and wants to load balance traffic equally across
all of them
• Possibility of asymmetric traffic too
ECMP with Traffic Zones
Traffic zone
configuration can be
used for
1. Traffic Load-
2 balancing (ECMP)
1 2. Route redundancy
3. Asymmetric traffic
handling
The zone-member command should be deployed every

The zone creation command should be deployed only time because FMC overwrites interface configurations
once. Also, notice the additional “ECMP” keyword during each deployment.
compared to the corresponding ASA command
3. Use the FlexObjects in a FlexPolicy and deploy the changes

to the device
SSL Decryption
(Really it’s TLS!)
Customer Use Case
• Protect the network from threats from remote TLS servers
• Called the outbound or unknown key case
• Example: Malware downloaded over HTTPS by users surfing
the web.
• Protect the network from attacks on internal TLS servers
• Called the inbound or known key case
• Example: Protect DMZ HTTPS servers from intrusion attacks
Challenges
• Inspection fails for some applications
• No end-user notifications unless traffic is decrypted
• Inspection fails for some client/server combinations
• Load on firewall creates throughput degradation
• Pre 6.3, TLS is being performed in software
• Post 6.3, TLS decryption in hardware on 2100, 4100, 9300
New in 6.3
SSL Hardware Decryption

• SSL decryption is performed in hardware as of 6.3
by default
• Leverages crypto hardware already present on new
platforms
• Delivered as part of 6.2.3 (non-default though)
• Delivered for these platforms:

• Firepower Threat Defence on 2100/4100/9300
Result: >2.5X performance improvement over software alone

Performance Details Coming Soon
Best Practices
• Block TLS traffic without decrypting
• Block URL categories
• Block Application (approx. 400 applications can be identified)
• Block based on certificate status, TLS version or cipher suite
• Use Replace Key Only feature

• Enable logging
to help
troubleshooting
Deployments
Policy and Traffic Separation
• Operationalise policy separation with low inter-tenant communication
• Assign different tenants interfaces to different zone groups
• Leverage inline SGT to separate traffic for different tenants

• Routing domain separation with transparent and routed/IRB NGFW
BVI1 BVI2 BVI3
FTD 192.168.1.0/24 192.168.2.0/24 192.168.3.0/24
• VoIP inspection requires explicit static routes – no overlapping IP

Firepower 9300 Module-Level Separation
• Each Firepower 9300 module represents a context
• Up to 3 tenants per chassis with full hardware resource separation
• Scales higher with more chassis and relatively low RU count
• Module-level HA provides redundancy; no scalability with clustering
HA Links
Eth1/1 Eth1/2 Eth1/3 Eth1/1 Eth1/2 Eth1/3
Supervisor Supervisor
Eth1/1 Eth1/2 Eth1/3 Eth1/1 Eth1/2 Eth1/3
Pri FTD 1 Pri FTD 3 Sec FTD 3 Sec FTD 1
Pri FTD 2 Chassis 1 Sec FTD 2 Chassis 2
Scalable Multi-Tenant Design outside
ASA Cluster in Multiple-Context Mode ASA Cluster VLAN 900

ASA
Routed Contexts a-la VRF Fusion Context 1 Context 2
Up to 250 contexts, ~20 recommended Routed Routed
Intermediate Switch Connection vPC

Independent ASA/FTD Cluster Operation
FTD Cluster in Transparent Mode VLAN 915 VLAN 910 FTD

Separate Bridge Group for Each Tenant FTD Cluster
BVI 1 BVI 2
VLAN or Zone-Based Policy Separation
Protect up to 512 interfaces on ASA side VLAN 925 VLAN 920
Tenant1:inside Tenant2:inside
vPC
Logical Diagram
Resilient Multi-Tenant Design outside
A/S ASA in Multiple-Context Mode A ASA Failover S VLAN 900

ASA
VLAN 10 VLAN 20
Pair of Standalone FTD Instances

Through-the-Box Etherchannel Inline Sets
Ethernet 2/3-2/4 FTD
VLAN-Based Policy Separation Inline Set
Mid-Flow Pickup on ASA Failover FTD FTD
Ethernet 2/1-2/2
Protect up to 1024 Interfaces on ASA side
vPC
Logical Diagram
Resilient+ Multi-Tenant Design outside
A/S ASA in Multiple-Context Mode A ASA Failover S VLAN 900

ASA
VLAN 10 VLAN 20
FTD Cluster with Inline NGIPS Interfaces

To-the-Box Etherchannel Inline Sets
Port-Channel 3-4 FTD
FTD Cluster
VLAN-Based Policy Separation Inline Set
Full Stateful Switchover on ASA Failover
Port-Channel 1-2
Protect up to 1024 Interfaces on ASA side
vPC
Logical Diagram
FTDv Multi-Tenant Approach
• Large (100+) multi-tenancy deployments can use FTDv
• Leverage ESX or KVM on UCS or any generic compute hardware
• Shared and dedicated vCPU and memory resource pools
• Up to 1.1Gbps of AVC+IPS 1024-byte throughput per tenant
• Ensure proper resource allocation to each instance
• 4 vCPU cores
• 8GB of memory
• 50GB of disk space
New in 6.3
FTD Multi-Instance Solution: 9300 with 3 SM’s

• Create up to 14 logical FTD devices on each SM44 x 3= 42 FTD instances!
• 2 9300’s allows Active Standby HA for each instance from one 9300 to
another
• 3 RU space allows for 42 active standby “contexts” with clustering support
coming for instances in a future release.
Firepower 9300 Firepower 9300
FTD Active FTD Standby

Instance Instance
W CPU FTD Standby W CPU
FTD Active
Instance Instance
X CPU X CPU
FTD Active FTD Standby
FTD Standby Instance FTD Active Instance
Instance Y CPU Instance Y CPU
Z CPU Z CPU
And possibly up to 38 more active standby pairs of instances!

Fail-to-Wire Capability
• Requires special hardware and supports inline NGIPS only
• Dedicated 1GE copper and fibre; 10GE and 40GE fibre modules
• Only available on Firepower 4100 and 9300 for now, 2100 is future
• Designed to engage during unplanned failure or restart events
• Use manual Bypass-Force under Inline Sets for planned events
• Physical relay with finite reaction time
• <90ms reaction time for Standby→Bypass with full power failure
• ~2sec reaction time for Bypass→Standby after full power failure
• Mileage may vary based on adjacent device sensitivity to link/packet drops
Q&A
#CLMEL
Continue
your Cisco
Demos in
Labs Meet The
Expert
Related
sessions
education the World
of
Solutions
#CLMEL © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 120
Complete Your Online Session Evaluation
• Give us your feedback and receive a

complimentary Cisco Live 2019 Power
Bank after completing the overall event
evaluation and 5 session evaluations.
• All evaluations can be completed via
the Cisco Live Melbourne Mobile App.
• Don’t forget: Cisco Live sessions will be
available for viewing on demand after
the event at:
https://ciscolive.cisco.com/on-demand-library/
Thank you
#CLMEL
#CLMEL

BRKSEC-3121 Read It

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BRKSEC-3121 Read It

Uploaded by

Copyright:

Available Formats

#CLMEL

Firepower Threat Defence:

Charlie Stokes, Technical Marketing Engineer

Advanced Inspections Plane

System Processes FTD Data-Plane

Management Interface 1 Interface 2 Interface 3 Interface 4

Total x86 Application System Lina Snort

SFDataCorrelator dynamically borrows cores from Snort for file processing

• Lina ftd# show cpu detailed

• Snort ftd# show asp inspect-dp snort

Id Pid Cpu-Usage Conns Segs/Pkts Status

‘show int ip brief’

• FTD physical Management interface is divided into 2 logical sub-interfaces:

Verification From CLISH CLI: From ASA CLI:

System Processes FTD Data-Plane

Eventing and Deployment ……

Management Interface 1 Interface 2 Interface 3 Interface 4

Eventing and Deployment

Management Interface 1 Interface 2 Interface 3 Interface 4

• DP threads poll on local RX

• Use correctly -- not a “high performance” substitute to NGFW policies

• Every Fastpath-ed TCP/UDP/GRE flow in Prefilter is offloaded

FTD Lina (Prefilter Policy) Snort

New and fully Offload Flow

R3 S3 D3 App=Google+ Permit IPS-1, File-1

ASA global access-group NGFW Access Policy

Helps administrators enforce

APIs Files and database

Centralised management for multi-site deployments

Multi-domain management Firewall & AVC

Role-based access control NGIPS

High availability AMP

APIs and pxGrid integration Security Intelligence

…Available in physical and virtual options

• Evolution of Defence Centre (pre

Integrated on-box option for single instance deployment

Easy set-up NAT and Routing

Intrusion and Malware

High availability Device monitoring

Physical and virtual options VPN support

Multi-Instance for 4100/9300 Airgap/Export Licensing Events direct-from-device

FTD Multi-Instance Solution

Firepower 4100 or Firepower 9300 module

Firepower 4100 or Firepower 9300 module

• Instances are designed such that an Firepower 4110 3

• Talos URL Database

• Unified Eventing Enhancements

• FDM and RAVPN Enhancements

• Access Control Policy Rule Hit Count

• Enhancements to Virtual Deployments

Does not include ASA container support (yet)

Advanced Inspections Plane

Eventing and Deployment

Management Interface 1 Interface 2 Interface 3 Interface 4

• Tune configuration to remove avoidable inspections and optimise the configuration

• Appliances with higher RAM and faster CPUs

• Adopt an architectural approach to avoid making security compromises

• As a solution of last resort, Intelligent Application Bypass (which allows flows to be

• Provides a semi-automated mechanism to Bypass selected traffic

• Processor Utilisation as a percentage - On

• At least one of the performance thresholds is

• Tune configuration to remove avoidable inspections and optimise the configuration

• Appliances with higher RAM and faster CPUs

• Adopt an architectural approach to avoid making security compromises