BRKCRT 2001

#CiscoLive
Top Firepower NGIPS

Simple Yet Costly Mistakes,
Misunderstandings,
and Need-to-Knows
John Wise – Instructional Design & Training Manager

BRKCRT-2001
#CiscoLive
Agenda
• IPS Inspection for ACP Rules
• Network Discovery Policy Mistakes
• Understanding SNORT Restarts
• Firepower Recommendations
• IPS Policy Before ACP
• Understanding the GID and Pre-
Processor Rules
• Latency-Based Protections and Alerts
#CiscoLive BRKCRT-2001 © 2021 Cisco and/or its affiliates. All rights reserved. Cisco Public 3
Missing IPS
Inspection for
ACP Rules
Why Does This Matter? You could be missing IPS
inspection for certain
allowed traffic!
ACP Allow Rule Flow
Allow indicates ‘allow the

traffic but inspect with an
You need to assign Intrusion Policy’
the Intrusion Policy
to send the traffic to!
Allow/ Interactive Block
No IPS Inspection on Allow Rules - A Mistake
By default, there is no ‘Intrusion’ inspection for ACP rules
You need to
assign an
‘Intrusion
Policy’
manually
The Same Goes For ‘Interactive Block’ Rules
Traffic is
Interactive Block Action allowed
User attempts User decides if
to connect to a traffic is allowed
website or blocked Traffic is
blocked
Interactive Block ACP Rules
Intrusion Policy
needs to be
assigned for
‘Interactive
Block’ rules as
well!
Network
Discovery Policy
Mistakes
Why Does This Matter? Network Discovery Policy
also enables Application
Detection!
Network Discovery is
critical to other features,
such as Firepower
Recommendations.
Network Discovery in The Packet Flow
Network Discovery is This is primarily for traffic you are ‘Allowing’
builds ‘Host Profiles’ in your network that will get inspected by an
Intrusion Policy
Network Discovery occurs here
Mistake #1- Deleting/Changing the Default Rule
Do not delete this

rule! Instead,
create a new
Discovery Rule to
discover hosts
SNORT leverages Application Detection and this rule is required!
Mistake #2 – Not Defining Internal Networks
When creating a ‘Host Discovery’ rule, define your networks
Do not use ‘any’ here,

otherwise the FMC will build
host profiles for ALL IPs it
sees, causing performance
issues AND making the host
data incorrect!
Define your network!
Mistake #3 – Overlapping Host Network Ranges
Do NOT add Overlapping can affect
multiple ‘Discover system performance due
Hosts’ rules with to the overlapping host
overlapping IP discovery requirements!
segments
Mistake #4 – Not Excluding Networks
What to exclude?
1) Networks you don’t

want Host Profiles built
for, such as Guest
Wireless
1) NAT Devices and Load

Balancers – these can
create excessive and
misleading events and
overload the FMC
Understanding
SNORT Restarts
Why Does This Matter? SNORT Restarts can
cause traffic interruption
and security issues!
You may be causing

SNORT to restart without
knowing it!
Understanding SNORT Restarts
A SNORT Restart occurs in multiple configuration change scenarios
A SNORT Restart can cause:
1) An interruption in traffic
2) A lack of traffic inspection
Or both.
How does it affect YOUR

environment? It depends!
What Happens When SNORT Restarts?
It depends on your software version and system/interface configuration
Download the fpmc-config-guide for your

managed device in question:
https://www.cisco.com/c/en/us/support/secu
rity/defense-center/products-installation-
and-configuration-guides-list.html
First Map Out How Your Devices Will Respond
Identify exactly how your devices and interface configurations will behave
Find the ‘SNORT Restart Traffic Behavior’

section and go through the tables to
determine how your system and interfaces
respond to SNORT restarts!
For example: In 6.7 software, in Routed and

Transparent mode, most existing TCP/UDF
flows are passed through with no inspection Note: If you are in a failover or
while new flows are dropped. You can also clustering design, you can
change this default behavior to drop ALL manage these restarts without
traffic instead any interruption!
Secondly Learn What Processes Cause a Restart
Again, refer to the fpmc-config-guide for your software version
For example, this is from the

6.7 fpmc-config-guide
Most regular operations such as managing Intrusion

Policy rules and ACP rules do NOT cause a restart!
SNORT Reloads Are Here to Help!
A SNORT Reload causes no traffic or inspection interruptions
Configuration changes that require a SNORT

restart are dwindling thanks to replacing the
configuration change with a SNORT reload
instead.
Expect less configuration changes to restart SNORT in future versions of software!
What About VDB Updates
VDB stands for ‘Vulnerability Database Update’
VDB updates come out approx. once a month (on average)

and update your vulnerabilities, your OS detectors and your
application detectors.
VDB Updates and SNORT Restarts
VDB updates restart SNORT… just not how you might expect!
Ensure your admins

are aware of any un-
deployed VDB
update!
When you install the VBD update, SNORT does not restart
During the next ‘Deploy’ SNORT will then restart!
SNORT Rule Updates (SRU’s) and Older Software
Do you have Managed Devices running software below version 6.3?
Prior to 6.3, certain If an SRU contains a ‘Shared

SRU updates cause Object Rule (GID:3)’ that is
SNORT restarts! then enabled or disabled in
your Intrusion Policy, SNORT
will restart when deployed.
Firepower
Recommendations
Oversights and
Misconfigurations
Why Does This Matter?
Your Firepower
Recommendations may
not be as accurate as
you think!
Firepower Recommendations Mistake #1
Improperly configured Network Discovery Policy
Remember configuring this policy? Ensure this is configured to:

1) Discover ‘Hosts’
2) Discover only YOUR network
The data FP
Recommendations
uses comes
directly from
Network Discovery
Policy!
Not waiting enough time after profiling your network
When you configure Network Discovery Policy to discover

‘Hosts’, it needs to run for some time (several weeks in
some cases) to properly profile your network
Allow time for

profiling First before
generating Firepower
Recommendations!
Only running Recommendations once
Firepower Recommendations need to be updated regularly
Do not overlook this button!
Generally updated at
least weekly, and can
also be scheduled
Firepower Recommendations Rule Overhead
Not understanding ‘Rule Overhead’
This setting determines which
rules should be considered
for Enabling.
Default is set
to ‘Medium’
‘Overhead’ of a rule indicates the
rule’s performance impact relative
to other rules.
A ‘Very High’ rule, for

example, is significantly
more performance-
impacting than a ‘Low’ rule
Rule Overhead Rule Assignment
FP Recommendations is only going to recommend Enabling rules up to this
threshold.
As of 2/2021, this If you adjust this to ‘High’

it can turn on significantly
is how many rules more rules and have a
are assigned to negative performance
each category: impact!
Low: 507
Medium: 8139
High: 8003
Very High: 26682
Understanding
and Managing
the IPS Policy
Before ACP
You might be missing
protection from threats!
You might not be able to

figure out how to tune the
IPS rules that cause
certain events.
Do You Know of the ‘Default Intrusion Policy’
The ‘Default Intrusion Policy’
Default Intrusion Policy Protection
Certain features require Firepower to see 3-5 (or more) packets before
matching
The ‘Default Intrusion Policy’ allows for

intrusion inspection on these first initial
packets before matching the feature’s
rule
Applicable Firepower Features
E.g., App-detection, URL filtering, QOS, and IAB (Intelligent Application
Bypass)
This is an
example of an
app-detect
ACP rule. In
order to match
the flow,
Firepower
would need to
see 3-5
packets on
average FIRST
Configuring The ‘Default Intrusion Policy’
This is assigned in
the ‘Advanced’
section of your
ACP
Tip: Create a ‘User Created’ Policy!
Remember you cannot make changes to system-provided policies
(E.G., Balanced Security and Connectivity). To make the Intrusion
Policy changeable…
Create a New IPS Policy and Assign this new policy to

use this as your Default your ACP in the Advanced
Intrusion Policy Section
Understanding
the GID
(Generator ID)
Why Does This Matter? As an analyst, you need to
know where Intrusion
Events are being
generated from.
Preprocessor rules and

Intrusion Policy rules are
very different from each
other!
'Intrusion Events’ come from SNORT
The GID maps the ‘Intrusion Event’ to the area of SNORT that processed that
rule
Managed by
Network
Analysis
Policy
Managed by
Intrusion
Policies
Understanding the Generator ID (GID)
The GID tells you if the Intrusion Event came from the Detection Engine or a Preprocessor
‘Network Analysis Policy’ ‘Intrusion

Rule Policy’ Rule
Pre-Processor Rules – 100 and above
These are preprocessor rules
Gid 1 = Text-Based (most of your

Processed in rules are this)
the ‘Detection Gid 3 = Shared Object (officiated
Engine’ looking rules) (approx. 2k)
for threats
Used to alert
on certain
preprocessor
settings Gid 100 and above = preprocessor rule
Intrusion Policy Rules = Gid 1-3
Gid 1-3 = Processed in the detection engine(s) and are either disabled,
enabled and dropping traffic, or enabled and only generating events.
GID:1/GID:2/GID:3 processed here
GID:1 example
Managing Pre-
Processor Rules
Why Does This Matter? Enabling preprocessor
rules can have
unexpected results.
Configuration of the
preprocessor rules are not
always mapped to the
preprocessor settings!
Network Analysis Policy (NAP) Rule Automation
Firepower can Automatically

change Network Analysis
Policy configuration based on
the Preprocessor rules you
enable!
However, this is not

represented in the GUI!
Understanding Preprocessor Rules
Example: SIP Preprocessor
Pre-processor rules enable alerting
and drop actions on certain
preprocessor functions
These are all

configured in
the Intrusion
Policy
The GUI ‘Gotcha’ for Preprocessor Rules
Network Analysis Policy
Notice the NAP

Policy has the SIP
Preprocessor set to
‘Disabled’
The GUI ‘Gotcha’ for Preprocessor Rules
Intrusion Policy
In this scenario, the SIP

preprocessor is OFF, and I
enable a SIP rule to
‘Generate Events’ within
this Intrusion Policy
NAP Rule Enabled - Preprocessor is Disabled
NAP has the SIP preprocessor disabled
An Intrusion Policy has a SIP

preprocessor rule configured to
‘Generate Events’ if the anomaly is
seen
The Invisible Preprocessor Setting
Network Analysis Policy
Once deployed, the The GUI of the NAP will

system will enable HOWEVER… NOT reflect that the
the SIP Preprocessor preprocessor is enabled!
automatically
Lessons Learned
If you plan to enable a DISABLING a preproc rule
preprocessor rule, be in the Intrusion Policy will
sure it is configured the NOT disable the preproc
same in the NAP and/or setting if it’s
already enabled in the Moral of the story: The
NAP GUI is trying to protect
you by automating this,
Remember the Intrusion but not knowing how it
Policy and NAP are meant works can really work
to work together! against you
Understanding
and Alerting on
Latency-Based
Performance
Settings
You could be missing
threats!
You could miss

performance issues with
SNORT rules and other
processes.
Firepower Latency Protection
Packet-Based Rule-Based
These are found in
the Access Control
Policy Advanced Tab
Prevents latency for packets Prevents SNORT
going through SNORT rules from
causing latency
Disables and re-

enables SNORT rules
automatically
Turn On Latency Threshold Alerting
By default, you are not alerted when these are triggered
Select the ‘Generate Events’ to generate an Intrusion Event when
they fire
Packet-
latency time
exceeded
Rule disabled
Rule re-
enabled
Further Your Education on Firepower
Enroll for a comprehensive instructor-led experience with hands—on labs and
lots of Firepower!
Questions about the offerings? Email me!
johnwis@cisco.com
https://learninglocator.cloudapps.cisco.com/#/course-
details/8713 - SSNGFW
https://learninglocator.cloudapps.cisco.com/#/course-
details/8678 - SSFIPS
These hyper-links direct you to our training at Cisco
Thank you
#CiscoLive
#CiscoLive

BRKCRT 2001

Uploaded by

Document Information

Original Title

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

BRKCRT 2001

Uploaded by

Copyright:

Available Formats

#CiscoLive

Top Firepower NGIPS

John Wise – Instructional Design & Training Manager

Allow indicates ‘allow the

Allow/ Interactive Block

Network Discovery occurs here

Do not delete this

SNORT leverages Application Detection and this rule is required!

Do not use ‘any’ here,

Define your network!

1) Networks you don’t

1) NAT Devices and Load

You may be causing

A SNORT Restart can cause:

2) A lack of traffic inspection

How does it affect YOUR

Download the fpmc-config-guide for your

Find the ‘SNORT Restart Traffic Behavior’

For example: In 6.7 software, in Routed and

For example, this is from the

Most regular operations such as managing Intrusion

Configuration changes that require a SNORT

Expect less configuration changes to restart SNORT in future versions of software!

VDB updates come out approx. once a month (on average)

Ensure your admins

During the next ‘Deploy’ SNORT will then restart!

Prior to 6.3, certain If an SRU contains a ‘Shared

Remember configuring this policy? Ensure this is configured to:

When you configure Network Discovery Policy to discover

Allow time for

Firepower Recommendations need to be updated regularly

Do not overlook this button!

A ‘Very High’ rule, for

As of 2/2021, this If you adjust this to ‘High’

You might not be able to

The ‘Default Intrusion Policy’

The ‘Default Intrusion Policy’ allows for

Create a New IPS Policy and Assign this new policy to

Preprocessor rules and

‘Network Analysis Policy’ ‘Intrusion

These are preprocessor rules

Gid 1 = Text-Based (most of your

GID:1/GID:2/GID:3 processed here

Firepower can Automatically

However, this is not

These are all

Notice the NAP

In this scenario, the SIP

NAP has the SIP preprocessor disabled

An Intrusion Policy has a SIP

Once deployed, the The GUI of the NAP will

You could miss

Disables and re-

Questions about the offerings? Email me!

These hyper-links direct you to our training at Cisco

You might also like