Bootcamp SSFIPS

Bootcamp SSFIPS
Securing Networks with Cisco Firepower Next-Generation IPS

1
 Bootcamp SSFIPS

Module 1: Security Technology Overview

Overview
Description
In this module, you will learn the fundamental functions of firewalls and intrusion prevention
systems and how they perform distinct roles within a network.
Objectives
Upon completing this module, you will be able to describe the key features and concepts of
next-generation IPS and firewall security.

2
 Bootcamp SSFIPS

Examining IPS and Firewall Technologies

Description

In this lesson, you will examine firewall and IPS fundamentals.

Objectives

After completing this lesson, you will be able to do the following:

• Describe and evaluate next-generation firewall technologies

• Describe and evaluate next-generation IPS technologies

• Describe the differences between firewall and IPS technologies

3
 Bootcamp SSFIPS

Before you begin your learning journey with Cisco Firepower products, you must first
understand the differences between a conventional firewall and an intrusion prevention
system (IPS). You must also understand what the term "next- generation" means in this
context.

A firewall (such as the Cisco ASA) is a hardware or software system that prevents
unauthorized access into or out of a network. Typically, firewalls are used to prevent
unauthorized Internet users from accessing internal networks. In order to achieve this, all
data leaving or entering the intranet must pass through the firewall to reach its destination,
and that any unauthorized data is blocked. The role of the firewall in any network is critical.

Firewall Types

There are three bask: types of fireballs: stateless packet-filtering, stateful packet-filtering,
and application-layer firewalls.

4
 Bootcamp SSFIPS

Stateless Packet-Filtering Firewall

The most basic (and the original) type of firewall, the packet-filtering firewall, examines the
packets as they traverse the firewall. The header of the packet is examined, and based on
this information, the packet is allowed to pass or is dropped. The header field can include the
following information:

• Source IP

• Destination IP

• IP protocol ID

• Port

• ICMP message type

• Fragmentation flags

• IP option settings

Stateful Packet-Filtering Firewall

Far more useful is the stateful packet-filtering firewall. This type of firewall performs the
same header inspection as the stateless packet-filtering firewall but also keeps track of the
connection state. This is a critical difference. To keep track of the state, these firewalls
maintain a state table.

Typically, unless otherwise configured in the firewall, all sessions that are initiated from the
Internet are not allowed. Connections that are allowed already have a session active in the
state table. Most of these connections are initiated by your internal network, with the
exception of connections that are built into the firewall policy—for example, sessions that are
initiated from the Internet to your internally hosted Web server.

The Cisco ASA adaptive security appliance, for example, maintains state. Here is how it
manages state in connections:

• New connections—If it is a new connection, the Cisco ASA appliance must check the
packet against access lists and perform other tasks to determine if the packet is allowed
or denied. To perform this check, the first packet of the session goes through the session
management path, and depending on the type of traffic, it might also pass through the
control plane path.

The session management path is responsible for the following tasks:

- Performing the access list checks

- Performing route lookups

- Allocating NAT translations (xlates)

- Establishing sessions in the "fast path'

The Cisco ASA appliance creates forward and reverse flows in thefast path for TCP traffic: the appliance als

5
 Bootcamp SSFIPS

• Established connections—If the connection is already established, the Cisco ASA

security appliance does not need to recheck packets: most matching packets can go
through the 'fast' path both directions. The fast path is responsible for the following tasks:

- IP checksum verification

- Session lookup

- TCP sequence number check

- NAT translations based on existing sessions

- Layer 3 and Layer 4 header adjustments

Application-Layer Firewall

The most advanced type of firewall is the application-layer firewall. With this type, deep
inspection of the packet occurs all the way up to the OSI model's Layer 7.

In the next topics, you will look at the basics of an IPS and how it differs from a firewall.
There are subtle differences among some of the terms that describe advanced firewalls and
IPS or IDS. The difference is that a firewall typically has static rules, whereas an advanced
IPS (namely. Cisco Firepower) learns and creates rules, and therefore is "smart."

6
 Bootcamp SSFIPS

An IPS, unlike a typical firewall, serves an altogether different purpose in your network. An
IPS can perform deep packet inspection {up to Layer 7 on the OSI model) in the same way
as an application level firewall. However, this is only the beginning of the capabilities of an
IPS. A next-generation IPS looks at a deeper level and is typically placed in a different pan
of the network from a firewall. A next-generation IPS can detect suspicious behavior and can
often perform advanced correlations on this information.

Next-generation IPS features include the following:

 Anomaly detection

 Rules or signatures to match against known attacks and attack patterns

 Alerting about suspicious behavior

 Traffic analysis

 Malware detection

 Security Intelligence

Throughout this course, you will learn about the specific features of the Cisco Firepower
Next-Generation IPS.

IDS and IPS functions often cause confusion. They are described in the following subtopics.

7
 Bootcamp SSFIPS

Intrusion Detection System

An intrusion detection system (IDS) does not interrupt the traffic flow IDS devices are
indirectly connected to the network. Typically, they are connected to the network by means
of a Switched Port Analyzer (SPAN) port on a switch or by means of a Tap.

IDS devices monitor traffic and send alerts, but have no actual interaction with the traffic as it
passes through the network.

Intrusion Prevention System

An intrusion prevention system (IPS) sits inline, and all traffic inspected must pass through
the IPS in order to reach its destination. IPSs are a fairly recent strategy, because of the
potential impact that a poorly performing IPS device can have on network performance. For
example, if an IPS has a hardware or software issue or incorrectly performs its inspection
(such as deeming a packet malicious when it is in fact good) it cannot only cause issues on
the network: it can take it down completely.

Recent advancements in IPS technology, especially in bandwidth capabilities, combined with

the recent explosion of known security breaches occurring across the world mean that IPS
devices not only are commonly used but are regarded as essential.

Which technology is correct for your network. IPS or IDS? It depends. Often, deployments
are set up as IDS initially. Once the installed technology is configured and tuned, it can be
placed inline as an IPS.

8
 Bootcamp SSFIPS

Firewall vs. IPS

Why would you use an IPS Instead of a firewall? This question is complex, with no right or
wrong answers. The following are some basic principles that can help you answer this
question:

 In general, a firewall sits on the edge of the protected network. This device often also
performs Network Address Translation {NAT}. This is typically the network's first line
of defense. This can be equated to The security guard on the outside of the gale. The
guard can ask for basic credentials, deny those who are not authorized, and also
check a guest list for deciding who can pass. (In firewall terms, the guest list is called
an access control list, or ACL) The advantage of the firewall (the gate security guard)
is that it can manage the first line of defense and keep out most unauthorized guests.

 An IPS is typically positioned on the inside of the outermost gate. Think of this as a
guard on the inside of the house. This guard can detect suspicious behavior like
anomalies and patterns that are not correct and might even do a more thorough
search of anything suspicious. This guard has far more visibility into the activities
within the protected network, or "house."

 You might now be wondering. Why not have only the inside guard? The logic is
simple. If there were no guard at the gate, and everyone was let into the house, the
inside guards would be overwhelmed. This scenario goes against the network
security principle of "layered security."

9
 Bootcamp SSFIPS

Lesson Summary

In this lesson, you learned the following:

 The most advanced type of firewall is the application-layer firewall which performs a
deep inspection of the packet all the way up to the OSI mode's Layer 7.

 An NGIPS also performs deep packet inspection but at a deeper level An NGIPS can
detect suspicious behavior and can often perform advanced correlators on that
information.

 Firewalls and IPS devices are typically used in different places within a network.
Firewalls are typically on the edge of the network, and IPS devices are typically on
the inside of the network.

10
 Bootcamp SSFIPS

Module Summary for "Security Technology Overview"

In this module, you learned the following:

 Firewalls typically sit on the edge of the protected network and provide the network's
first line of defense. An NGIPS is typically positioned on the inside of the network,
has far more visibility into the
activities within the protected network, and detects suspicious behavior such as
anomalies and incorrect patterns.

11
 Bootcamp SSFIPS

12
 Bootcamp SSFIPS
Module 2: Cisco Firepower NGIPS Components and Features

Overview

Description

This module examines The Cisco Firepower Next Generation Intrusion Prevention System
(NGIPS) platforms, naming conventions, and features. You will also be introduced to the lab
network and the associated Firepower implementation customer scenario that you will use
throughout this course.

Objectives

Upon completing this module, you will be able to describe the Cisco Firepower NGIPS
system components, features, and high-level implementation steps. This ability includes
being able to meet these objectives:

• Describe the Cisco Firepower System concepts and challenges

• Identify the components of the Cisco Firepower System

• Introduce a typical deployment scenario and describe the procedures required for
implementing a Cisco Firepower System

13
 Bootcamp SSFIPS
Cisco Firepower System Overview

Description

This lesson provides a history of the Firepower technology and describes the features of the
system, including how they address modern security challenges.

Objectives

After completing this lesson, you will be able to do the following:

• Describe the relationship between Cisco. Sourcefire, and Snort

• Describe the features of the Firepower System

• Identify the security challenges to be addressed

14
 Bootcamp SSFIPS
Relationship Between Cisco, Sourcefire, and Snort

Following the previous module’s introduction to IPS and firewall security, this lesson
introduces the Firepower System.

Firepower technology was created by Sourcefire Technologies and is based on Snort

technology Cisco acquired Sourcefire in 2013, this acquisition included the Firepower
technology. The Firepower System began with Snort in 1988.

This class will focus on the Cisco Firepower NGIPS. To understand where this product
offering fits into Cisco's portfolio of security products, click the following link:

http://www Cisco com/c/en/us/products/security/index.htm#

15
 Bootcamp SSFIPS
Firepower 6.x Software Features

There are many new features in the Firepower Release 6.0 that provide increased threat
visibility and flexible deployment options. Among these options are the introduction of URL
and DNS visibility into security intelligence, new user control options such as the Identity
Services Engine USE) and domain awareness.

Firepower 6.0 New Features—Threat and Visibility

The graphic shows the latest threat and visibility features that have been added to the
Firepower Release 6.0. These features include the following:

• URL-based Security Intelligence and DNS inspection

• File property analysis and local malware checks

• OpenAppID integration

• Threat Grid integration for both cloud-based and on-premises sandboxing

16
 Bootcamp SSFIPS
Firepower 6.0 New Features—Flexible Deployment

The graphic shews the latest flexible deployment features that have been added to the
Firepower Release 6.0. These features include the following:

• 6.0 SSL decryption, available in Cisco ASA Firepower Services

• Captive portal active authentication support

• ISE session attributes, including identity, device, and security group tags

• Multidomain management with role-based access and policy inheritance

17
 Bootcamp SSFIPS
Security Requirements

Firepower is built for any size of network. Release 6.0 has a new level of scalability with
domain-level visibility.

Firepower Security Automation

The Firepower System can be divided into three distinct categories:

• Analytics

• Remediation

• Operations

Each of these categories is covered in this course.

18
 Bootcamp SSFIPS
Example: One Day of Defending Cisco

An example of what Cisco protects and analyzes is provided here. Every network is different,
but most networks have common points of challenges for protecting their given network. You
see here an example of what defending a larger network looks like.

19
 Bootcamp SSFIPS

Lesson Summary

In this lesson, you learned the following:

• Sourcefire, acquired by Cisco in 2013, created Firepower technology, when is based

on Snort technology.

• Firepower technology is a complex engine that provides threat visibility and flexible
deployment features that are capable of handling multidomain environments. Threat
Grid integration, advanced malware detection, and more.

• The Firepower System addresses network threats by using automated analytics,

remediation, and operations.

20
 Bootcamp SSFIPS
Examining Cisco Firepower Components

Description

This lesson identifies the essential Firepower System components, the naming conventions
that are associated to these components, and the key Firepower products that Cisco offers.

Objectives

After completing this lesson, you will be able to do the following:

• Describe the components of the Cisco Firepower System

• Describe the Firepower product-naming progression

• Identify the key Firepower products (physical and virtual)

21
 Bootcamp SSFIPS
Firepower System Components

Starting in Release 5.x, both the Management Center (previously called the Defense Center
[DC] and the Firesight Manager) and the managed device (typically called a sensor, or
simply the IPS) are required. Unlike in Release 4.x. a standalone managed device is not an
option. A critical part of understanding how to manage these devices is to understand their
roles in your network, as well as their communication channels. You will continue to learn
more about this topic throughout this course.

Firepower Management Center

The Firepower Management Center is not only the manager of the system: it is where you
will spend most (if not all) your time. The Firepower Management Center is a critical part of
this system. Keep in mind that the Firepower Management Center does not detect the
network traffic. That role belongs to the managed device, which is discussed next.

22
 Bootcamp SSFIPS

Firepower Managed Device

The managed device is what detects The Traffic. Whether inline, commonly referred to as
IPS, or passive, commonly referred to as IDS, the device that detects the traffic that it is
inspecting in the managed device (or sensor). Notice in the diagram that the sensor sits line.
You can also be physically inline as shown here and yet still technically be deployed
passively. This is called tap mode. In addition, you could feed the network traffic to the
sensor outside the flow of traffic by means of a span port or a network tap. There are many
deployment models that you can use.

23
 Bootcamp SSFIPS
Firepower Product-Naming Progression

As you can see, the naming conventions have changed over the years. Keep this in mind as
you traverse the documentation (such as the user guide or Internet-based information). Take
the time to understand these terms. Different documentation might reference these terms
differently. The most common mistake is confusing the managed device (sensor) with the
Firepower Management Center (previously called the Defense Center). Keep in mind that
every Firepower deployment has both a managed device and a Firepower Management
Center and that these devices are not the same architecture.

24
 Bootcamp SSFIPS
Firepower Platforms

The current hardware has three distinct platforms. Do not let this confuse you: the
fundamentals are the same for all of them. This course examines the key features and flow
of the Firepower 7000 and 8000 Series, but also apples to the alternative platforms as well.
When deciding on a platform, keep in mind how you are physically deployed. In addition, be
mindful of what software applications you have running in your environment, how much
traffic you are seeing, and which licenses you plan to have installed. Also note that the ASA
with Firepower will have most of the features to be discussed in this course, but not all.

Cisco ASA with FirePOWER Services

The Cisco ASA with FirePOWER services has fast become one of Cisco's most popular
offerings. As the ASA has delivered world-renowned firewall capabilities for years, it is now
coupled with world-renowned IPS capabilities. Keep in mind that this course is only for the
Firepower component of the system. You can think of the ASA with FirePOWER services as
having both an ASA and an IPS. They are independently operated and managed, however,
with the exception of Threat Defense, where the code has become merged. You will manage
the ASA and FirePOWER services separately in Release 6.0

25
 Bootcamp SSFIPS
FirePOWER 7000 and 8000 Series Devices

The graphic shows the key features of the 7000 and 8000 Series devices. These are
standalone devices that are not part of the ASA or other network device.

Device Stacking—8000 Series Only

Device stacking allows you to increase the amount of traffic inspected on a network segment
by connecting two to four devices in a slacked configuration. When you establish a slacked
configuration, you combine the resources of each stacked device into a single, snared
configuration.

For each stacked configuration, all devices in the stack must have the same hardware.
However, none some, or all devices might have an installed malware storage pack. The
slacked configuration is supported for FirePOWER 8140. 8200 family. 8300 family devices.
You can purchase devices stacked, or purchase them one at a time and stack them as
needed to meet your environments growing needs.

When you establish a stacked configuration, you combine the resources of each stacked
device into a single, snared configuration.

You designate one device as the primary device, where you configure the interfaces for the
entire stack. You designate the other devices as secondary. Secondary devices must not be
currently sensing any traffic.

26
 Bootcamp SSFIPS

Connect the primary device to the network segment you want to analyze in the same way
you would configure a single device. Conr.ec: the secondary devices to the primary device
using the stacked device cabling instructions found in the Firepower System Installation
Guide.
All devices in the slacked configuration must have the same hardware, run the same
software version, and have the same licenses. If the devices are targeted by MAT policies,
both the primary and secondary device must have the same MAT policy. You must deploy
updates to the entire stack from the Firepower Management Center. If an update fails on one
or more devices in the stack, the stack enters a mixed-version state. You cannot deploy
policies to or update a stack in a mixed-version slate. To correct this state, you can break the
stack or remove individual devices with different versions, update the individual devices,
then reestablish the stacked configuration. After you stack the devices, you can change the
licenses only for the entire stack at once.

After you establish the slacked configuration, the devices act like a single, snared
configuration. If the primary device fails, no traffic is passed lo the secondary devices. Health
alerts are generated indicating that the stacking heartbeat has failed on the secondary
devices.

If the secondary device in a stack fails, inline sets with configurable bypass enabled go into
bypass mode on the primary device. For all other configurations, the system continues to
load balance traffic to the failed secondary device. In either case, a health alert is generated
to indicate loss of link.

You can use a device stack as you would a single device in your deployment, with a few
exceptions. If you have 7000 or 8000 Series devices in a high-availability pair, you cannot
stack a device high-availability pair or a device in a high-availability pair. You also cannot
configure MAT on a device stack.

In a multidomain deployment, you can only stack devices that belong to the same domain.

Firepower Threat Defense

Firepower Threat Defense is 3 new software Image that combines Firepower Services with
select ASA Functionary.

27
 Bootcamp SSFIPS
This software will allow the management of ASA functionality and Firepower services from
one manager; the Firepower Management Center Licensing is managed by the same
subscriptions as with Firepower Services, but are provided by Smart Licensing This course
details the Firepower Services component of the Firepower Threat Defense software which
is Included whether using the Threat Defense Image.
Standalone Firepower appliances, or ASA with FirePOWER services.

Firepower Threat Defense Platforms

Firepower Threat Defense is supported on ell 5500-X devices (except the 5535-X) and the
new Firepower 4100 and S300 platforms. These can all be managed using the Firepower
Management Center 6.0. Using the Firepower Management Center v6.0 onwards enables
you to manage all or a combination of these platforms in the same network.

Firepower Management Center Appliances

Just as you have a choice of managed devices, you also have a choice of Firepower
Management Center. This appliance is a critical component in your environment, because it
not only manages the managed device but it also is the analysis tool that you will use. Here
are the current specifications for the available models of the Firepower Management Center.

28
 Bootcamp SSFIPS

Hardware and Software Version History

There are a few hardware and software versions that it is important to be familiar with.

Firepower hardware has two distinct types: Series 2 and Series 3. Series 2 devices are older
hardware, in production prior to 2010. Any of these devices are limited in what versions they
can update to, as well as features that they can have enabled. Most features that you will
examine in this course are not available in Series 2 devices.

Not many Series 2 devices are still in deployment, so you are most likely working exclusively
with the latest hardware version. Series 3. Series 3 hardware is the most current and can
potentially run all the Release 6.0 features, assuming that the individual model is capable
and licensed appropriately. The Firepower System has many available features and
capabilities, so you must choose carefully and deploy the Firepower System intelligently in
order to maximize throughput and performance while still enjoying the benefits. It is not
realistic to enable all the Release 6.0 features on all your network traffic using one device.
You must be careful in how you plan your the Firepower System deployment.

Software versions also have a history. This course is for Release 6 0, which also includes
relevant content for 5.x software code. Every version has its own feature sets and GUI
changes. Release 5.x is the most recent behind 6.0 and is considered current. You likely
have 5.x software in your enterprise Release 5.4 was the most notable of all the 5.x
versions, because it was the first to be released since the acquisition of Sourcefire and
included such advancements as SSL decryption within the managed device and increased
versatility with variable sets.

Release 4.x software code is not commonly used. If the specifications on the hardware that
you are using allow an upgrade to 5.x. be aware that any upgrade path from 4x requires a
wipe-arc-replace approach, because there is no direct upgrade path.

29
 Bootcamp SSFIPS

Lesson Summary

In this lesson, you learned the following:

• The Firepower System has two essential components: the Firepower Management Center
and the managed device.

• The Firepower Management Center was previously known as the Defense Center or the
FireSIGHT Management Center: similarly, the managed device was previously known as the
appliance or simply as
“IPS”

• Firepower support can be provided by ASA with FirePOWER Services, standalone

Firepower appliances, and virtual appliances.

30
 Bootcamp SSFIPS

Cisco Firepower Implementation Procedure-Scenario

Description
This lesson will introduce you to the fictitious customer scenario that you will use throughout
the course. The lesson will also give you an understanding of the lab environment.

Objectives
After completing this lesson, you will be able to do the following:
• Detail s Firepower System implementation scenario.
• Describe the lab environment.

31
 Bootcamp SSFIPS

Firepower Implementation Scenario

You will refer to the following scenario throughout the course to help provide use case
examples of the features and functionality of the Firepower System.

The customer SecureBank has grown quickly to a user base of 800-plus employees and has
recognized the need for a more secure network. The network consists of both internal users,
mostly in one location, and a variety of critical data servers that must be protected from
malicious attacks and exfiltration of data. SecureBank has recently purchased Cisco's
Firepower 7110 solution. They have a Firepower Management Center FS2000 to manage
their device and future devices. They expect that the future requirements will be in excess of
the 2000 hosts and users combined that the smaller FS750 can support.

Logical Couse Outline

The example customer scenario described in the previous slide will be followed throughout
this course and is divided into two general categories: setup and, implementation. The
graphic shows the logical course outline that is required for following this scenario.

32
 Bootcamp SSFIPS

Lab Topology

The graphic shows the virtual lab topology that will be used for the lab exercises throughout
the course.

Each pod has access to the following equipment:

• Ernakh/Jumphost— Connect using RDP and use to launch browser sessions to the
Firepower Management Center and PuTTY sessions to the lab devices.

• A virtual Firepower Management Center.

• A virtual Firepower managed device.

• Five Linux virtual machines:

- Rugila— SMTP and IMAP server

- Attila—NMAP and PCAPs server
- Bleda—FTP. Web and LDAP server
- Lamp—MySQL. Web and Syslog server
- Kali—Metasploit and Armitage tools

• A virtual router.

33
 Bootcamp SSFIPS

Lab Network Components

The lab network is divided into the following zones:

Production Zone:

• General Network
- Rugila
- Attila
- Kali
- Student Jump Host

. DMZ Network
- Bleda
- Lamp

Management Zone:

• Management Network
- Firepower Management Center (Virtual)
- Managed Device (Virtual)

34
 Bootcamp SSFIPS

Lesson Summary

In this lesson you learned the following:

• The customer SecureBank will be implementing a Firepower System NGIPSv to

protect a user base of 800-plus users.
•
• The lab environment is based on virtual equipment, including NGIPSv, a virtual
Firepower Management Center, and other VM-based hosts.

35
 Bootcamp SSFIPS

Module Summary for “Cisco Firepower NGIPS Components and Features”

In this you learned the following:

• Firepower technology is a complex engine that offers threat visibility and flexible
deployment features to provide automated analytics, remediation, and operations.

• The Firepower System has two key components: the Management Center and tie managed
device, which can be virtual or physics appliances.

• This course will demonstrate a typical deployment scenario through the use of a fictitious
customer named SecureBank.

36
 Bootcamp SSFIPS

Knowledge Check

37
 Bootcamp SSFIPS

Module 3: Cisco Firepower Management Center Introduction

Overview

Description
This module introduces you to the Firepower Management Center interface and
components. This module also introduces you to how the Firepower Management Center
uses policies to manage traffic decisions in your managed device.

Objectives
Upon completing this module, you will be able to navigate the Cisco Firepower management
center GUI and understand the role of policies when configuring the Cisco Firepower
System. This ability includes being able to meet these objectives:

• Identify the key features of the Firepower Management Center

• Describe the role and relationship of policies in configuring the Firepower System

38
 Bootcamp SSFIPS

Exploring the Firepower Management Center GUI

Description

This lesson introduces you to the Firepower Management Center GUI layout including the
login process and the menus.

Objectives

After completing this lesson you will be able to do the following:

• Log in lo the Firepower Management Center GUI

• Describe the features of the key Firepower Management Center GUI menus

39
 Bootcamp SSFIPS

Firepower Management Center Basics

The Firepower Management Center, formally called the Defense Center (DC) and Firesight
Manager, is a critical part of you* Firepower System. The Firepower System requires both
the sensor (managed device) that sees the traffic that you are monitoring, and the Firepower
Management Center. This is the case for all Firepower platforms.

A Firepower Management Center is a fault-tolerant, purpose-built network appliance that

provides a centralized management console and database repository for your Firepower
System deployment. You can also deploy 64-bit virtual Firepower Management Centers as
ESXi hosts by using the VMware vSphere Hypervisor or vCloud Director environment.
Firepower Management Centers have a range of device
management, event storage, host-monitoring, and user-monitoring capabilities. Any
Firepower Management Center can manage any type of Firepower System device.

Firepower Management Centers aggregate and correlate network traffic information and
performance data, assessing the impact of events on particular hosts. You can monitor the
information that your devices report, and assess and control the overall activity that occurs
on your network. Firepower Management Centers also control the network management
features on your devices: switching, routing. NAT, VPN, and so on.

Key features of the Firepower Management Center include the following:

• Device, license, and policy management

• Event and contextual information displayed in tables, graphs, and charts

•
• Health and performance monitoring
•
• External notification and alerting
•
• Correlation, indications of compromise, and remediation features for real-time threat
response

• Custom and template-based reporting

40
 Bootcamp SSFIPS

Communications with the Managed Device

Once the communication channel is set up between the Firepower Management Center and
the managed device, basic information is exchanged between the two appliances, as shown
in the graphic. It is important to note that these are both 'push' communications. This means
that the data is sent from the device, as opposed to being polled or pulled down. As an
example, if you change a policy configuration on the Firepower Management Center for a
managed device, those policy changes will not take effect until you "push" mat policy (known
as an apply). This could be done immediately or at a future time.

Firepower Management Center

The Firepower Management Center is primarily accessed by means of https but can also be
accessed by the CLI. Most configurations, however, must be performed by the GUI via https.
You can also restrict how the Firepower Management Center is accessed by only certain
IPs, for example.

41
 Bootcamp SSFIPS

Firepower Management Center Host Limits

The Firepower Management Center is the governing manage for all the managed devices in
your enterprise. The Firepower Management Center can manage a number of managed
devices, and these managed devices can protect a number of hosts. The host limits in the
Firepower Management Center must account for all hosts potentially detected. This is
important to consider when deploying and selecting a model of Firepower Management
Center.

The number of hosts that a Firepower Management Center can monitor, and therefore store
in network maps, depends on its model. In a multidomain deployment, leaf domains share
the available pool of monitored hosts but have separate network maps.

To ensure that each leaf domain can populate its network map, you can set host limits at
each subdomain level. If you set a domain's host limit to 0, the domain shares in the general
pool.

Setting the host limit has a different effect at each domain level:

• Leaf—For a leaf domain, a host limit is a simple limit on the number of hosts that the
leaf domain can monitor.

• Second Level—For a second-level domain that manages third-level leaf domains, a

host limit represents the total number of hosts that the leaf domains can monitor. The
leaf domains share the pool of available hosts
•
• Global—For the global domain, the host limit is equal to the total number of hosts
that a Firepower Management Center can monitor. You cannot change it.

The sum of subdomains' host limits can add up to more than their parent domain's host limit.
For example, if the global domain host limit is 150.000, you can configure multiple
subdomains, each with a host limit of 100.000. Any of those domains, but not all, can
monitor 100.000 hosts.

The network discovery policy controls what happens when you detect a new host after you
reach the host limit; you can drop the new host, or replace the host that has been inactive for
the longest time. Because each leaf domain has its own network discovery policy, each leaf
domain governs its own behavior when the system discovers a new host. If you reduce the

42
 Bootcamp SSFIPS
host limit for a domain and its network map contains more hosts than the new limit, the
system deletes the hosts that have been inactive the longest.

Firepower Management Center GUI

Log in to The Firepower Management Center by browsing to the IP via https and enter your
account credentials. You can authenticate by using local authentication or by using external
authentication such Radius and LDAP.

Firepower Management Center Top-Level Menus

The Firepower Management Center has many management and analysis components, such
as device management and policy management. The reference guide for all current
Firepower features is the Firepower Management Center Configuration Guide. This is a
critical document for you as you operate the system, and you should have it readily available
when administrating the system.

You can download the guide from this link:

43
 Bootcamp SSFIPS

Firepower Management Center Analysis Menu

The Analysis section is for analyzing all events in the Firepower Management Center. The
Firepower Management Center is not only a management tool for the managed device; it is
also an extensive analysis tool. You can set up the Firepower Management Center to send
certain data, such as intrusion events, to other systems that you manage, like a SIEM. The
Firepower Management Center itself is designed to be an
analyst's tool and is typically used in this way by most analysts.

FMC Policies Menu

Firepower Management Center Policies Menu

The Policies sector, is where all policies are set up on the Firepower System. Policies
include Intrusion, Access Control, Malware, DNS, Identity, and SSL. It is critical to note that
the Firepower Management Center is where all policies are built and managed When you
are ready for the changes to take effect (typically, during a maintenance window) you apply

44
 Bootcamp SSFIPS
the policies. This is when the Firepower Management Center communicates the policy
changes you made to the managed device, so that the managed device can be aware of any
changes and apply them to its configuration.

Firepower Management Center Devices Menu

The Devices Sector, is where all your registered managed devices are stored in the
Firepower Management Center GUI. You can manage many of the device settings here,
inducing licensing and interfaces. You can also add and delete registered devices in this
section.

45
 Bootcamp SSFIPS

Lesson Summary

In this lesson, you learned the following:

• The Firepower Management Center is a Firepower device that is used to manage a

managed device, and it is managed primarily through a web-based GUI via login credentials
that you specify.

• The Firepower Management Center consists primarily of Analysis. Policy, and Device
menus that allow you to perform both management and analysis tasks.

46
 Bootcamp SSFIPS

Introducing Firepower Management Center Policies

Description
This lesson describes policies that are managed by your Firepower Management Center,
and describes their purpose in the Firepower System. You will see row policies relate to
traffic flow in your managed device and how policies are deployed and maintained.

Objectives

After completing this lesson, you will be able to do the following:

• Describe the role of policies in configuring the Firepower System

• Describe the order in which policies are applied in relation to traffic flow

• Describe the policy deployment process

• Describe the policy deployment messages

47
 Bootcamp SSFIPS
Policy Basics

Policies can be divided into two general groups: those for configuring traffic-based device
settings and those for general device configurations. Traffic-based refers to how the traffic is
dealt with by your managed device, whereas general device configurators relate to the
settings and optional features of both the Firepower Management Center and the managed
device.

Policies Fundamental to Traffic Management

The policies fundamental to traffic management are as follows:

• Access control policy

• Intrusion policy

• Malware and file policy

• DNS policy

• Identity Policy

• SSL policy

48
 Bootcamp SSFIPS

Management Device Traffic Flow

The flowchart in the graphic represents the administrative flow in your system. These are the
policies that you manage and the order in which the traffic flows through these policies. You
will be directed back to this flowchart throughout this course

Asa with FirePOWER Services Traffic Flow

This flowchart shows how the Firepower System fits into the flow of traffic in the ASA. This
course is based on the Firepower portion. As with a standalone ASA, basic firewalling is still
performed on the ASA. You specify the traffic to be sent to the Firepower module in the ASA.
When the Firepower module has finished processing the traffic, it sends all the traffic back to
the ASA. If the Firepower module has specified any traffic to be dropped, the ASA drops that
traffic. Although they are in one physical appliance, they operate independently. This course
details the Firepower module of the ASA with FirePOWER Services only.

49
 Bootcamp SSFIPS

Redirecting Traffic to the FirePOWER Module

Use the commands shown in the graphic to configure inline or passive deployments of the
Fire-CWER module.

Inspection Capabilities

The graphic details the responsibilities of each policy. The following text provides examples
for each policy:

• Security Intelligence—Block blacklisted IP addresses known to be malicious. An

example would be a known CnC server These IPs are managed and updated by
Talos and are fed into the system regularly.

• SSL Policy—Decrypt traffic between your web server and Internet IPs. Once it is
decrypted, you can inspect the traffic with the other policies.

• Access Control Policy—Prevent certain users from accessing certain URLs Choose
not to inspect SIP traffic by any farther policies. Block certain application traffic.

50
 Bootcamp SSFIPS
• Intrusion Policy—Send all traffic for inspection by Snort Rules. Detect on attempts to
compromise vulnerable applications on your host.

• Malware Policy—Inspect files between your user segment and the Internet for
malware. If files are determined to be malware, block the file.

Policy Event Management

Here you see the same managed device policies and where they are managed. You also
see where to manage logging decisions, and what events are generated for that given
policy.

Policy Deployment

51
 Bootcamp SSFIPS

After you use the Firepower Management Center to configure your deployment, and any tme
you make changes to that configuration, you must deploy the new configuration to applicable
devices Note that prior to 6.0, policy changes were managed within each respective policy.
Firepower 6.0 introduced Policy Deploy in one centralized location where you can see all the
available policy changes and can manage all of them in one location. This eliminated the
need to visit multiple areas of the Firepower Management Center GUI to manage all your
Firepower Policy deployments.

The Deploy Policies dialog box lists all devices where the system has identified an out-of-
date configuration The Version field at the top of the dialog box specifies the time at which
you last made configuration changes. The Current Version column in the device table
specifies the time of the most recent prior deployment to that device.

Policy Deployment Components

The deployment scion distributes the following configuration components:

• Access control policies and all associated policies: DNS, file, identity, intrusion, network
analysis, SSL

• Any associated rule configurations and objects associated with a policy to be deployed

• Intrusion rule updates

• Device and interface configurations

• Platform settings

• VPN deployments

• Network discovery policy

• NAT policies

You can configure the system to deploy the configuration automatically by scheduling a
deployment task or by setting the system to deploy the configuration when importing

52
 Bootcamp SSFIPS
intrusion rule updates. Automating policy deployment is especially useful if you allow
intrusion rule updates to modify system-provided base policies for intrusion and network
analysis. Note that intrusion rule updates can also modify default values for the advanced
preprocessing and performance options in your access control policies.

In a multidomain deployment:

• You can deploy changes for any domain to which your user account belongs.

• You can deploy changes for all subdomains at the same time if you switch to the Global
domain before deploying the changes.

• You can deploy changes for an individual subdomain if you switch to the leaf domain
before deploying the changes.

After you initiate a deployment, you can view the deployment status in the Message Center.

Policy Deployment Window

You can go to the Deploy tab to the upper-right of the GUI to see if any policies are out of
date. From here, you can deploy the necessary configurations.

Procedure

1. Click Deploy

The Deploy Policies dialog box appears.

2. Identify the devices where you want to deploy configuration changes. You can do the
following:

• Sort—Sort the device list by clicking a column heading

• Filter—Filter the device list. To do so, click the arrow in the upper-right corner of any
column heading in the display, enter text in the Filter text box. and press Enter

53
 Bootcamp SSFIPS

3. Optionally, expand the device listing to view the configuration changes to be

deployed.

The system marks out-of-date policies with an index icon

4. Choose the devices where you want to deploy configuration changes.

5. Click Deploy

6. If the system identifies errors or warnings in the changes to be deployed, you have
the following choices:

• Click Proceed to continue deploying the configuration without resolving error or

warning conditions. This button is enabled if the system identifies only warnings for
the deployment: it is disabled if the system certifies an error in the deployment.

• Click Cancel to exit without deploying the configuration Resolve the error and
warning conditions, and attempt to deploy the configuration again

54
 Bootcamp SSFIPS

Complete the activity to perform the task shown in the graphic. The simulation win provide
prompts to assist you.

Complete the following steps:

Step 1

Select Deploy from the upper right toolbar.

Step 2

From the Deploy Policies window, expand the policy list for the managed device by
selecting the + icon.

Step 3

To deploy the policy changes, select the check box associated with the managed device
and select the Deploy button.

Step 4

To view the deployment status, open the Message Center by clicking the system status icon,
located to the immediate right of the Deploy button in the main menu

Step 5

The deployment progress will be displayed in a drop down screen.

Step 6

For information on previous tasks, select the Tasks tab in the drop down screen

Step 7

To return to the main GUI, again select the icon next to the Deploy button in the upper right
toolbar.

55
 Bootcamp SSFIPS

Policy Deployment Messages

The system uses warning and error icons to mark configurations in policies that could
adversely affect traffic analysis and flow Depending on the issue, the system may also warn
you at deployment time or prevent the policy deployment entirely.

Error Message

If a rule or configuration has an error, you cannot apply the policy until you correct the issue,
even if you disable any affected rules.

Error Message Example

A rule that performs URL filtering might be valid until you target a device that does not have
a URL filtering license. At that point, an error icon appears next to the rule, and you cannot
apply the policy to that device until you edit or delete the rule retarget the policy, or enable
the appropriate license.

Warning Message

You can apply an access control policy that displays rule or other warnings. However,
misconfigurations marked with warnings have no effect.

If you disable a rule with a warning, the warning icon disappears. II reappears if you enable
the rule without correcting the underlying issue.

56
 Bootcamp SSFIPS

Warning Message Example

Preempted rules or rules that cannot match traffic due to misconfiguration have no effect.
These include conditions using empty object groups, application filters that match no
applications, excluded LDAP users,
invalid ports, and so on.

However, if a warning icon marks a licensing error or model mismatch, you cannot deploy
the policy until you correct the issue.

Information Message

Information icons convey helpful information about configurations that may affect the flow of
traffic. These issues do not prevent you from applying the policy.

Information Message Example

With application control and URL filtering, the system may skip matching the first few
packets of a connection against some access control rules, until the system identifies the
application or web traffic in that connection.

This action allows connections to be established so that applications and HTTP requests can
be identified.

57
 Bootcamp SSFIPS

Lesson Summary

In this lesson, you learned the following:

• Policies have both a device configuration role (for both the Firepower Management Center
and the managed device) and a traffic-flow role in your Firepower System.

• Policies that have a traffic-flow role are typically processed in a specific order, beginning
with Security Intelligence and ending with Intrusion Policy and/or Malware & File Policy.

• Policy deployment occurs after configuration changes are made to a policy, and are now
managed in one central location in the Firepower Management Center GUI, called Deploy.

• Policy Deployment messages consist of Error. Warning, and Information messages that
give contextual information to potential issues with the policy deployment

58
 Bootcamp SSFIPS

Module Summary for "Cisco Firepower Management Center Introduction"

In this module, you learned die following:

• The key features of the Firepower Management Center are Policy settings. Device settings,
and Analysis settings, and these settings are primarily managed in the GUI by navigating to
the Firepower
Management Center from a web browser

• Policies serve both System Administration Management and Traffic Flow Management in
the Firepower Management Center, and traffic flow policies are processed in order on the
managed device once they are deployed via the Deploy feature in the Firepower
Management Center.

59
 Bootcamp SSFIPS

Knowledge Check

60
 Bootcamp SSFIPS

Module 4: Deploying Cisco Firepower Managed Devices

Overview

Description

This module provides an overview of the typical Firepower deployment architectures, and
describes the steps required for deploying and configuring a managed device in your
Firepower Management Center. The module concludes with a detailed examination of the
Firepower Classic licensing model.

Objectives

Upon completing this module, you will be able to deploy and manage Cisco Firepower
managed devices. This ability includes being able to meet these objectives:

• Identify the various Firepower System deployment architectures

• Perform device setup tasks

• Manage Firepower System licensing

61
 Bootcamp SSFIPS

SecureBank Scenario-Device Management

This module will describe the deployment and initial management procedures for Cisco
Firepower managed devices that can be used to address the scenario in the graphic.

Logical Course Outline

Throughout this course, you will be following the logical course outline as shown in the
graphic. In this module, you will learn about the initial stage of deployment, device
management fundamentals, and Firepower licensing.

62
 Bootcamp SSFIPS

Examining Deployment Architectures

Description

This lesson describes the basic deployment topology for Firepower Systems while focusing
heavily on the inline deployment interface and management features and options.

Objectives

After completing this lesson, you will be able to do the following:

• Identify the deployment topologies supported in Firepower 6.0

• Describe the Inline deployment model

• Describe the 7000/8000 Series Inline Set Interface Options

• Describe the Passive deployment model

• Describe the Advanced Deployment options

63
 Bootcamp SSFIPS

Firepower Managed Device Deployment Options

In most scenarios, the Firepower managed device will be deployed either passively or inline.
You can also configure the managed device to act as a router or switch, although this is rot
common. The next topic looks are the fundamentals of these two deployments.

64
 Bootcamp SSFIPS

Inline Deployment-IPS

In an inline IPS deployment, you configure the Firepower System transparently on a network
segment by binding two pons together. This action allows the system to be instated in any
network environment without the configuration of adjacent network devices. Inline interfaces
receive all traffic unconditionally, all traffic received on these interfaces is retransmitted out
of an inline set unless dropped by an explicit rule or through the detection of malicious traffic
or files.

For the system to affect traffic, you must deploy relevant configurations to managed devices
by using routed, switched, or transparent interfaces, or inline interface pairs.

Inline Interface Pairs (Sets)

65
 Bootcamp SSFIPS
Before you can use Inline interfaces in an inline deployment, you must configure inline sets
and assign inline interface pairs to them. An inline set is a grouping of one or more inline
interface pairs on a device; an inline interface pair can belong to only one inline set at a time.

The Inline Sets tab of the Device Management page displays a 1st of all inline sets that you
have configured on a device. Note that you cannot configure inline sets to go into bypass
mode on NGIPSv devices. The Inline Sets Table View Fields table includes summary
information about each set.

You can assign only inline interface pairs to an inline set. If you want to create an inline set
before you configure the inline interfaces on your managed devices, you can create an
empty inline set aid add interfaces to it later. You can use alphanumeric characters and
spaces when you type a name for an inline set.

66
 Bootcamp SSFIPS
7000 and 8000 Series Specific Inline Configuration

When the managed device is deployed inline, you risk interfering with network traffic and
other network devices. The 7000 and 8000 Series appliances allow for failsafe and bypass
modes to respond to this potential issue.

Firepower 7000 and 8000 Series devices support a failsafe mode, where traffic is allowed to
bypass detection and continue through the device. Managed devices monitor internal traffic
buffers arc bypass detection if those buffers are full.

Firepower 7000 and 8000 Series devices support a bypass mode to configure how the
relays in the inline interfaces respond when an interface fails. The bypass mode allows traffic
to continue to pass through the interfaces. The nonbypass mode blocks traffic.

You cannot configure bypass mode for inline sets in the following cases:

• For 7000 or 8000 Series devices in a high-availability pair

• For inline sets on an NGIPSv device

• For nonbypass network modules on 8000 Series devices

• For SFP modules on Firepower 7115 or 7125 devices

67
 Bootcamp SSFIPS
Inline Interface Advanced Option-Tap Mode

Tap mode is a way to deploy inline physically but not interact with the traffic directly This is
particularly useful when you plan to deploy inline eventually but are introducing Firepower
into your network and need to ensure that you will not drop traffic unintentionally first. This
way, you can tune your system before potentially making any mistakes that may cause
network issues. Tap mode is available on 7000 and 8000 Series devices when you create an
inline, or an inline with a fail-open interface set.

With tap mode, the device is deployed inline, but instead of the packet flow passing through
the device, a copy of each packet is sent to the device and the network traffic flow is
undisturbed Because you are working with copies of packets rather than the packets
themselves, rules that you set to drop and rules that use the replace keyword do not affect
the packet stream. However, rules of these types do generate intrusion events when they
are triggered, and the table view of intrusion events indicates that the triggering packets
would have dropped in an inline deployment.

There are benefits to using tap mode with devices that are deployed inline. For example, you
can set up the cabling between the device and the network as if the device were inline and
analyze the kinds of intrusion events that the device generates. Based on the results, you
can modify your intrusion policy and add the drop rules that best protect your network
without impacting its efficiency. When you are ready to deploy the device inline, you can
disable tap mode and begin dropping suspicious traffic without having to reconfigure the
cabling between the device and the network.

Inline Interface Advanced Option-Propagate Link State

68
 Bootcamp SSFIPS
Link-state propagator is a feature for inline sets configured in bypass mode so that both pairs
of an inline set track state. Link-state propagation is available for both copper-and fiber-
configurable bypass interfaces. Link-state propagation automatically brings down the second
interface in the inline interface pair when one of the interfaces in an inline set goes down.
When the downed interface comes back up, the second interface automatically comes back
up also. In other words, if the link state of one interface changes, the appliance senses the
change and updates the link state of the other interface to match it.

Link-state propagator is especially useful in resilient network environments where routers are
configured to reroute traffic automatically around network devices that are in a failure state.

You cannot disable link-state propagation for inline sets configured on 7000 and 8000 Series
devices in high-availability pairs.

Inline Interface Advanced Option-Transparent Inline Mode and Strict TCP

Enforcement

Transparent Inline Mode option allows the device to act as a “bump in the wire," which
means that the device forwards all the network traffic that it sees, regardless of its source
and destination. Note that you
cannot disable this option on 7000 and 8000 Series devices.

To maximize TCP security, you can enable strict TCP enforcement, which blocks connectors
where the three-way handshake was rot completed. Strict enforcement also blocks the
bowing:

• Non-SYN TCP packets for connections where the three-way handshake was not
completed

• Non-SYN/RST packets from the initiator on a TCP connection before the responder
send the SYN-ACK

69
 Bootcamp SSFIPS

• Non-SYN-ACK/RST packets from the responder on a TCP connection after the SYN
but before the session is established

• SYN packets on an established TCP connection from either the initiator or the
responder

70
 Bootcamp SSFIPS

Passive Deployment-IDS

In a passive deployment, you deploy the system out-of-band from the flow of network traffic.
In a passive IPS deployment, the Firepower System monitors traffic flowing across a network
by using a switch SPAN or mirror port. The SPAN or mirror port allows for traffic to be copied
from other ports on the switch.

This action provides the system visibility within the network without being in the flow of
network traffic. When configured in a passive deployment, the system cannot take certain
actions such as blocking or shaping traffic.

Passive interfaces receive all traffic unconditionally, and no traffic received on these
interfaces is retransmitted.

Passive Interfaces on the Firepower System

You can configure one or more physical ports on a managed device as passive interfaces.

When you enable a passive interface to monitor traffic, you designate mode and MDI/MDIX
settings, which are available only for copper interfaces. Interfaces on 8000 Series appliances
do not support half-duplex options.

When you disable a passive interface, users can no longer access it for security purposes.

71
 Bootcamp SSFIPS

Advanced Deployments Options

You can configure your interfaces to perform routing and switching as well. This is not common, because
typically you would use a firewall (like the ASA) to perform these tasks. The ASA with Firepower separates
these duties, with the ASA performing firewall features separately and sending traffic to the Firepower module
for NGIPS tasks. Firepower Threat Defense can also perform these types of deployments, however.
This is new unified code that merges the ASA code with Firepower, allowing you to manage all the firewall and
NGIPS features on one platform.

Switching

You can configure the Firepower System in a Layer 2 deployment so that it provides packet
switching between two or more network segments. In a Layer 2 deployment, you configure
switched interfaces and virtual switches on 7000 and 8000 Series devices to operate as
standalone broadcast domains. A virtual switch uses the MAC address from a host to
determine where to send packets. You can also group multiple physical interfaces into a
single logical link that provides packet switching between two endpoints in your network.

The endpoints can be two 7000 and 8000 Series devices, or a managed device connected
to a third-party access switch.

Routing

You can configure the Firepower System in a Layer 3 deployment so that it routes traffic
between two or more interfaces In a Layer 3 deployment, you configure routed interfaces
and virtual routers on 7000 and 8000 Series devices to receive and forward traffic. The
system routes packets by making packet-forwarding decisions according to the destination
IP address. Routers obtain the destination from the outgoing interface based on the
forwarding criteria, and access control rules designate the security policies to apply.

When you configure virtual routers, you can define static routes. In addition, you can
configure Routing Information Protocol (RIP) and Open Shortest Path First (OSPF) dynamic
routing protocols. You can also configure a combination of static routes and RIP or static
routes and OSPF. You can set up DHCP relay for each virtual router that you configure.

If you use both virtual switches and virtual routers in your deployment, you can configure
associated hybrid interfaces to bridge traffic between them. These utilities analyze traffic to
determine its type and the appropriate response (route, switch, or otherwise). You can also
group multiple physical interfaces into a single logical link that routes traffic between two

72
 Bootcamp SSFIPS
endpoints in your network. The endpoints can be two 7000
and 8000 Series devices, or a managed device connected to a third-party router.
NAT

In a Layer 3 deployment, you can configure network address translation (NAT) using 7000
and 8000 Series devices. You can expose an internal server to an external network, or allow
an internal host or server to connect to an external application. You can also configure NAT
to hide private network addresses from an external network by using a block of IP
addresses, or by using a limited block of IP addresses and port translation.

VPN

A virtual private network (VPN) is a network connection that establishes a secure tunnel
between endpoints by means of a public source, like the Internet or other network. You can
configure the Firepower System to build secure VPN tunnels between the virtual routers of
7000 and 8000 Series devices.

High Availability—7000 and 8000 Series Only

Device high availability is available in the 7000 and 8000 Series. With 7000 and 8000 Series
device high availability. You can establish redundancy of networking functionality and
configuration data between two peer devices or two peer device stacks. You achieve
configuration redundancy by configuring two peer devices or two peer device stacks into a
high-availability pair to act as a single logical system for policy
deployments, system updates, and registration. The system automatically synchronizes
other configuration data.

High-Availability Requirements

Before you can configure a 7000 and 8000 Series device high-availability pair, both devices
or device stack primary members must be the same model and must have identical copper
or fiber interfaces Both devices or device stacks must also be running the same software
and have the same licenses. Device stacks must have identical hardware configurations,
except for an instated malware storage pack. For example, you can pair a Firepower 8290
with another Firepower 8290. None, one, or all devices in either stack might have a malware
storage pack. If the devices are targeted by NAT policies, both peers must
have the same NAT policy. After you pair the devices, you cannot change the license
options for individual paired devices, but you can change the license for the entire high-
availability pair.

73
 Bootcamp SSFIPS

High-Availability Failover and Maintenance Mode

With a 7000 and 8000 Series device high availability, the system fails over either manually or
automatically. You manually trigger failover by placing one of the pair devices or stacks in
maintenance mode. Automatic failover occurs after the health of the active device or stack
becomes compromised, during a system update, or after a user with Administrator privileges
shuts down the device. Automatic failover also occurs after an active device or device stack
experiences hardware failure, firmware failure, critical process failure, a disk full condition, or
link failure between two stacked devices. If the health of the backup device
or stack becomes similarly compromised, the system does not fail over and enters a
degraded state. The system also does not fail over when one of the devices or device stacks
is in maintenance mode. Note that disconnecting the stacking cable from an active stack
sends that stack into maintenance mode.

Shutting down the secondary device in an active stack also sends that stack into
maintenance mode.

Deploying Policies and Updates in High Availability

When you deploy a policy, you deploy it to the device high-availability pair instead of to the
individual devices or stacks If the policy fails, the system does not deploy it to either the
device or the stack The policy is first deployed to the active device or stack and then to the
backup, so that the high-availability pair always has one peer handling network traffic.
Devices in high-availability pairs receive updates as a single entity rather than as individual
devices or stacks.

When the update is started, the system first deploys it to the backup device or stack, which
goes into maintenance mode until any necessary processes restart and the device begins
processing traffic again. The system then deploys the update to the active device or stack,
which follows the same process.

In most cases, you can achieve Layer 3 redundancy without configuring a high-availability
pair, by using the SourceFire Routing Protocol (SFRP). SFRP allows devices to act as
redundant gateways for specified IP addresses. With network redundancy, you can
configure two or more devices or stacks to provide identical network connections, ensuring
connectivity for other hosts on the network

For further information and best practices for high availability, refer to the user guide:

74
 Bootcamp SSFIPS

Lesson Summary

In this lesson, you learned the following:

• Firepower 6.0 supports inline, passive, and advanced deployment options that allow for
routing and switching.

• The inline deployment model of the Firepower System involves putting the managed device
into the flow of traffic by configuring an 'inline set"

• The 7000 and 8000 Series inline deployment options contain various settings that allow for
a passive-like configuration as well as settings that dictate what to do when hardware or
software issues arise.

• The passive deployment model of the Firepower System involves putting the managed
device outside the flow of traffic typically by either a span port or a network tap.

• Advanced deployment options in the Firepower System are for the 7000 and 8000 Series
appliances and allow for high availability and typical firewall features such as routing and
switching.

75
 Bootcamp SSFIPS

Managing Devices

Description

This lesson will walk you through correcting your Managed Device to your Firepower
Management Center, and outline the device settings and domain-based features available to
you.

Objectives

After completing this lesson, you will be able to do the following:

• Describe the process for connecting managed devices to tie Firepower Management
Center

• Describe and edit managed device settings

• Describe the role-based domain features

76
 Bootcamp SSFIPS

Firepower Device Registration Procedure

Mounting a managed device to the management center is a process known as device

registration. Device registration is a two-part process in which you configure the managed
device to communicate with a management center, and you configure the management
center to accept communications from the managed device. The process of connecting
these devices to the Firepower Management Center begins with configuring the managed
device to communicate with the management center, to verify me connection credentials,
and to establish the command and control channel. The exact process may differ slightly
from one device to another. This is because some devices are configured by way of the
device's graphical interface, while others must use the CLI for the initial configuration.

A device unboxed or deployed for the first time can take a while to initialize. Depending on
the device type, it could take up to 45 minutes to initialize and build out its database table
schema. So, if you are installing a device for the first time, be prepared to allocate a
sufficient amount of time to complete the installation.

Managed Device Setup

When the device initializes, you can access it to perform its initial configuration by using
either of the following methods:

1 Attach a US5 keyboard and monitor to the appropriate ports on the device for console
access to the device. Of course, in virtual installations, this is not necessary, because the
hypervisor platform will provide console access to the virtual device.

77
 Bootcamp SSFIPS
2. Connect a network cable to the management port and an out-of-band switch. Then
connect a laptop to the switch and change the laptop's IP address to something in the
192.163.45.0/24 range. Once the
laptop is configured, you can use SSH to connect to the managed device and configure it
from the CLI. A managed device's default IP address is 192 163.45 45, so do not use this
address to configure the
laptop. Also, the default login credentials for a device are as follows:
• User: admin
• Password: Admin123

From the CLI, you will be asked a series of questions to set up the managed device's
network configuration. On hardware-based managed devices, such as FirePOWER or
Series II devices, you can continue the
configuration from the graphical interface if you want to do so, or you can do it all from the
CLI.

With the device initialized, you must configure its manager. From the CLI, you can issue the
following command:

The <host> parameter is the IP address of the management center.

The <key> parameter is the registration key, which, in the device registration process, is an
authentication token. The management center must provide the same hey values for the
registration to be completed
successfully

The <nat_ID> is an optional parameter, which is relevant only in cases where a NAT device
sits between the management eerier and the managed device. This nat_ID is used to
uniquely identify a device behind a
NAT box, because all the correctors from the NAT box w appear to be the same IP address.

You can perform this process from a hardware-based devices graphical interface if you want
to. The path to the remote management registration page is System > Local >
Registration. From this page, click the
Add Manager button arc provide the required registration information:

• Management Host

• Registration Key

• Unique NAT ID

The procedure is as follows:

Step 1

One the web interface for the device that you want to manage, choose System >
Integration.

Step 2

Click the Remote Management tab. if it is not already displayed

78
 Bootcamp SSFIPS

Step 3

Click Add Manager

Step 4

In the Management Host field, enter one of the following for the Firepower Management
Center that you want to use to manage this appliance:

- The IP address

- The fully qualified domain name or the name that resolves through the local DNS to a
valid IP address (that is, the hostname)

In a NAT environment, you do not need to specify an IP address or hostname here if you
plan to specify it when you add the managed appliance In this case, the Firepower System
uses the NAT ID that you will provide later to identify the remote manager on the managed
appliance's web interface.

Step 5

In the Registration Key field, enter the registration Key that you want to use to set up
communications between appliances.

Step 6

For NAT environments, in the Unique NAT ID field, enter a unique alphanumeric NAT ID that
you want to use to set up communications between appliances.

Step 7

Click Save.

Once the registration process on the managed device is completed, the device will be in a
"pending" state while it waits for the management center to communicate with it and initialize
the communication channel.

79
 Bootcamp SSFIPS
Firepower Management Center Setup

To complete the registration process, you must identify the managed device to the
management center, so that it can authenticate the managed device and complete the
process of establishing the communication channel.

Click the Devices selection from the main menu to display the device list. Then click Add
and select Add Device

80
 Bootcamp SSFIPS
Managed Device Properties

Each managed device must be registered separately Once it is registered, you can perform
most management from the Firepower Management Center Once this step is completed,
you will use the Firepower Management Center System configuration and policies to
manage most aspects of the managed device

Device Properties—General

In your Firepower Management Center, you manage your devices under the Device tab. The
General subtab options are out ted as follows:

• Name is the display name of the device on the Firepower Management Center It is
wise to use a name that represents the sensor easily for the users of the system. You
will see this name often throughout the Firepower Management Center.

• To allow the device to transfer packets to the Firepower Management Center, check
the Transfer Packets check box. This option is enabled by default. If you disable it,
you completely prohibit packet transfer to the Firepower Management Center.

• New in 6.0, Force Deploy forces deployment of all policies and device configuration
updates on the device. This is a very useful feature to keep in mind. Remember that
the alternative means of deploying is by means of the Deploy tab in the upper-right
corner of the Firepower Management Center GUI.

81
 Bootcamp SSFIPS
Device Properties—System

Systems settings are as follows:

• Model—The model name an: number for the managed device.

• Serial—The serial number of the chassis of the managed device.

• Time—The current system t me of the device

• Version—The version of the software currently Installed or the managed device.

• Policy—A link to the platform settings policy currently deployed to the managed device.

You can also shut down or restart the device. Note that if you shut the system down from the
Stop button, you will not be able to start it again from the GUI by default.

Lights Out Management can be configure: to remote y turn the system on.

Device Properties—Advanced

82
 Bootcamp SSFIPS
Automatic Application Bypass

The Automatic Application Bypass (AAB) feature limits the time allowed to process packets
through an interface and allows packets to bypass detection if the time is exceeded. The
feature functions with any
deployment, however, it is most valuable in inline deployments.

You balance packet-processing delays with your networks tolerance for packet latency.
When a malfunction within Snort or a device misconfiguration causes traffic processing time
to exceed a specified threshold, AAB causes Snort to restart within 10 minutes of the failure,
and generates troubleshooting data that can be analyzed to investigate the cause of the
excessive processing time.

In Version 6.0 and later, the default behavior for the AAB option is as follows:

• 7000 and 8000 Series, NGIPSv: off

• ASA FirePOVVER: off

If you upgrade from a version earlier than 5.3, the existing setting is retained. You can
change the bypass threshold if the option is selected. The default setting is 3000
milliseconds (ms). The valid range is from 250 ms to 60.000 ms.

Typically, you use Rule Latency Thresholding, configured in the advanced settings of the
access control policy, to fast-path packets after the latency threshold value is exceeded Rule
Latency Thresholding does not shut down the engine or generate troubleshooting data.

If detection is bypassed, the device generates a health-monitoring alert.

Device Properties-Fast Path Rules

83
 Bootcamp SSFIPS
You can create fast-path rules to send traffic directly through an 8000 Series device with no
further inspection.

Fast-path rules divert traffic that does not need to be analyze: to bypass the device Fast-
path rules either send traffic to the fast path (out of the interface) or allow it to continue into
the device for further analysis. Their advantage is the speed at which they determine the
correct path for the traffic. Because the fast-path rules function at the hardware level, they
determine only faulted information about the packet.

You can use the following criteria to specify which IPv4 traffic you want to divert to the fast
path and not inspect

• Initiator or responder IP address or CIDR block

• Protocol

• Initiator or responder port, for TCP or UDP protocols

• VLANID

• Bidirectional option

Device Properties-Management

This sector is where the actual IP of the device is located. As you might recall, the General
section had a Name option. This is the location of the IP of the managed device. You also
have the option to disable the management channel with the managed device. The status
icon is particularly useful for ensuring that your communication channel is still operating
normally.

84
 Bootcamp SSFIPS
Domain Awareness

New in 6.0, the domains feature allows you to implement multitenancy within a Firepower
System deployment by segmenting user access to managed devices, configurations, and
events. You can create up to 50 subdomains under a top-level Global domain, in two or
three levels.

When you log in to the Firepower Management Center, you log in to a single domain, called
the current domain.

Depending on your user account, you may be able to switch to other domains.

In addition to any restrictions imposed by your use role, your current domain level can also
limit your ability to modify various Firepower System configurations. The system limits most
management tasks, like system software updates, to the Global domain.

Domain Levels Definitions

85
 Bootcamp SSFIPS
The domain levels are as follow:

• Leaf domain

- Domain with no subdomains

• Descendent domain

- A domain descending from the current domain in the hierarchy

• Child domain

- A domain’s descendent

• Ancestor domain

- A domain from which the current domain descends

• Parent domain

- A domain's direct ancestor

• Sibling domain

- A domain with the same parent

Three Domain Levels

The system limits other tasks to leaf domains, which are domains with no subdomains. For
example, managed devices must belong to leaf domains. After you register a device to the
Firepower Management Center, you perform all device management tasks from the device's
leaf domain.

86
 Bootcamp SSFIPS
One Domain Level—Global

If you do rot configure multitenancy, all devices, configurations, and events belong to the
Global domain, which is by definition a leaf domain. Except for domain management, the
system hides domain-specific configurations and analysis options until you add subdomains.

Two Domain Levels—Global and Second-Level (Leaf)

In a two-level multidomain deployment, the Global domain has direct descendant domains
only. For example, a managed security service provider (MSSP) can use a single Firepower
Management Center to managed network security for multiple customers:

• Administrators at the MSSP can log in to the Global domain to manage all customers'
deployments.

• Administrators for each customer can log in to second-level named subdomains to manage
only the devices, configurations, and events applicable to their organizations. These local
administrators cannot view or affect tie deployments of other customers of the MSSP.

Three Domain Levels—Global, Second-Level, and Third-Level (Leaf)

In a three-level multidomain deployment, the Global domain has subdomains, at least one of
which has its own subdomain. To extend the previous example, consider a scenario where
an MSSP customer—already restricted to a subdomain—wants to further segment its
deployment. This customer wants to separately manage two Passes of device: devices
placed on network edges and devices placed internally:

• Administrators for the customer can log in to a second-level subdomain to manage the
customer’s entire deployment.

• Administrators for the customer's edge network can log in to a leaf domain to manage only
the devices, configurations, and events applicable to devices deployed on the network edge.
Similarly, administrators for the customer's internal network can log in to a different third-
level domain to manage internal devices, configurations, and events Edge and internal
administrators cannot view each other's deployment.

Domain Considerations

87
 Bootcamp SSFIPS
Creating a New Domain

You can create one or two levels of subdomain below the Global domain. You can have a
total of 50 domains, including the Global domain.

You must assign all devices to a leaf domain before you can save the domain configuration.
When you add a subdomain to a leaf domain, the domain stops being a leaf domain and you
must reassign its devices.

The procedure is as follows:

Step 1

In a Global or a second-level domain, choose System > Domains

Step 2

Click Add Domain, or click the Add Subdomain icon next to the parent domain

Step 3

Enter a name and description.

Step 4

Choose a parent domain.

Step 5

On the Devices tab. choose the available devices that you want to add to the domain. Then
click Add to Domain or drag and drop the device names into the Selected Devices 1st.

Step 6

Optionally, click the Advanced tab to limit the number of hosts that the new domain can
monitor.

Step 7

Click Save to create the new domain.

The system warns you if any devices are assignee to nonleaf domains. Click Create New
Domain to create a new domain, or Keep Unassigned to cancel.

Step 8

Click Save to save the domain configuration.

88
 Bootcamp SSFIPS
Moving a Device Between Domains

Moving a device between domains can affect the configurations and policies applied to the
device. The system automatically keeps and updates what it can, and deletes what it cannot.

When you move a device, the system can prompt you to choose the following new, essential
configurations:

• Access Control Policy—If the access control policy assigned to a moved device is not
valid or accessible in the new domain, choose a new policy. Every device must have an
assigned access control policy.

• Health Policy—If the health policy applied to a moved device is inaccessible in the new
domain, you can choose a new health policy.

• Security Zones—If the interfaces on the moved devices belong to a security zone that is
inaccessible in the new domain, you can choose a new zone.

If devices require a policy update but you do not need to move interfaces between zones,
the system displays a message stating that zone configurations are up-to-date. For example,
if a device's interfaces belong to a security zone configured in a common ancestor domain,
you do not need to update zone configurations when you move devices from subdomain to
subdomain.

Moving Data Between Domains

Because events and network maps are associated with leaf domains, when you change a
leaf domain to a parent domain, you have two choices:

• Move the network map and associate; events to a new leaf domain.

• Delete the network map but retain the events. In this case, the events remain associated
with the parent domain until the system prunes events as needed or as configured—or you
can delete old events manually.

89
 Bootcamp SSFIPS
Lesson Summary
In this lesson, you learned the following:

• Connecting managed devices to the Firepower Management Center requires a process

that includes, first, assigning a registration key to the managed device, and then associating
that key to the Firepower Management Center to establish the communication channel.

• Managed device settings include device-relevant features such as whether the device will
send packets to the Firepower Management Center for intrusion events and assigning a
unique name to the device, so that all references to that device are displayed with that
identification.

• Role-based domains allow the Firepower Management Center to manage multiple groups
of managed devices separately, so that the devices, event messages, and configurations are
independently managed and contained.

90
 Bootcamp SSFIPS
Firepower Licensing

Description

This lesson introduces you to the Firepower classic licensing model and describes each
license's purpose and potential usage in your deployment.

Objectives

After completing this lesson, you will be able to do the following:

• Describe the Firepower Management Center Classic licensing model

• Describe the procedure for establishing and applying Classic licenses

91
 Bootcamp SSFIPS
Firepower Classic System License Model

You can license a variety of features to create an optimal Firepower System deployment for
your organization.

You use the Firepower Management Center to manage licenses for itself and the devices
that it manages. The license types offered by the Firepower System depend upon the type of
device that you want to manage.

Firepower Classic System Licensing

Classic License Types and Restrictions

This topic describes the types of Classic licenses available in a Firepower System
deployment. The licenses that you can enable on a device depend on its model, version, and
the other licenses that are enabled.

For NGIPSv and 7000 and 8000 Series devices, and ASA FirePOWER modules, licenses
are model-specific; you cannot enable a license on a managed device unless the license
exactly matches the device's model. For example, you carrot use a Firepower 8250
protection license to enable Protection capabilities on an 3140 device.

Devices that use Classic licenses are sometimes referred to as Classic devices

92
 Bootcamp SSFIPS

There are a few ways you may lose access to licensed features in the Firepower System:

• You can remove Classic licenses from the Firepower Management Center, which affects all
of its managed devices.

• You can disable licensed capabilities on specific managed devices.

• Though there are some exceptions, you cannot use the features associated with an
expired or deleted license.

Firepower Protection License

A Protection license allows you to perform intrusion detector and prevention, file control, and
Security Intelligence filtering:

• Intrusion detection and prevention allows you to analyze network traffic for intrusions and
exploits and, optionally, drop offending packets.

• File control allows you to detect and. optionally, block users from uploading (sending) or
downloading (receiving) files of specific types over specific application protocols. AMP for
Firepower, which requires a Malware license, allow you to inspect and bock a restricted set
of those file types based on their dispositions.

• Security Intelligence filtering allows you to blacklist—deny traffic to and from—specific IP

addresses. URLs, and DNS domain names, before the traffic is subjected to analysis by
access control rules. Dynamic feeds allow you to immediately blacklist connections based on
the latest intelligence. Optionally, you can use a "monitor-only” setting for Security
Intelligence filtering.

Although you can configure an access control policy to perform Protection-related inspection
without a license, you cannot deploy the policy until you first add a Protection license to the
Firepower Management Center, and then enable it on the devices targeted by the policy.

If you delete your Protection license from the Firepower Management Center or disable
Protection on managed devices, the Firepower Management Center stops acknowledging
intrusion and file events from the affected devices. As a consequence, correlation rules that
use those events as a trigger criteria stop firing. Additionally, the Firepower Management
Center will not contact the Internet for either Cisco or third-party

93
 Bootcamp SSFIPS
Security Intelligence information. You cannot redeploy existing policies until you re-enable
Protection.

Because a Protection license is required for URL Filtering. Malware, and Control licenses,
deleting or disabling a Protection license has the same effect as deleting or disabling your
URL Filtering. Malware, or Control license.

Firepower Control License

A Control license allows you to implement user and application control by adding user and
application conditions to access control rules. It also allows you to configure 7000 and 8000
Series devices to perform switching and routing (including DHCP relay and NAT), as well as
to configure 7000 and 8000 Series device high-availability pairs. To enable Control on a
managed device, you must also enable Protection.

Although you can add user and application conditions to access control rules without a
Control license, you cannot deploy the policy until you first add a Control license to the
Firepower Management Center, and then enable it on the devices targeted by the policy.

Without a Control license, you cannot do the following:

• Create switched, routed, or hybrid interfaces on your managed devices.

• Create NAT entries.

• Configure DHCP relay for virtual routers.

Although you can create virtual switches and routers, they are not useful without switched
and routed interfaces to populate them. Furthermore, you cannot deploy a device
configuration that includes switching or routing to a managed device where you have not
enabled Control Additionally, establishing high availability between managed 7000 or 8000
Series devices requires that the devices are enabled for Control.

If you delete your Control license from the Firepower Management Center or disable Control
on individual devices, the affected devices do not stop performing switching or routing, nor
do 7000 or 8000 Series device high-availability pairs break.

Although you can edit and delete existing configurations, you cannot deploy your changes to
the affected devices. You cannot add new switched, routed, or hybrid interfaces, nor can you

94
 Bootcamp SSFIPS
add new NAT entries, configure DHCP relay, or establish 7000 or 8000 Series device high
availability. Finally, you cannot redeploy existing access control policies if they include rules
with user or application conditions.

Firepower Malware License

A Malware license allows you to perform Cisco Advanced Malware Protection (AMP) with
AMP for Firepower and AMP Threat Grid You can use managed devices to detect and block
malware in files transmitted over your network. To enable a Classic Malware license on a
managed device, you must also enable Protection.

You configure AMP for Firepower as pan of a He policy, which you then associate with one
or more access control rules. File policies can detect your users uploading or downloading
files of specific types over specific application protocols AMP for Firepower allows you to use
local malware analysis and file ^reclassification to inspect a restricted set of those file types
for malware. You can also download and submit specific file types to the AMP Threat Grid
cloud for dynamic and Spero analysis to determine whether they contain malware.

For these files, you can view the network file trajectory, which details the path that the file
has taken through your network The Malware license also allows you to add specific files to
a file Est and enable the fie list within a file policy, allowing those files to be automatically
allowed or blocked on detection.

Before you can deploy an access control policy that includes AMP for Firepower
configurations, you must add a Malware license and then enable it on the devices targeted
by the policy. If you later disable the license on the devices, you cannot redeploy the existing
access control policy to those devices.

If you delete all your Malware licenses or they all expire, the system stops querying the AMP
cloud and also stops acknowledging retrospective events sent from the AMP cloud. You
cannot redeploy existing access control policies if they include AMP for Firepower
configurations. Note that, for a very brief time after a Malware license expires or is deleted,
the system can use existing cached file dispositions. After the time window expires, the
system assigns a disposition of Unavailable to those files.

95
 Bootcamp SSFIPS

Firepower URL Filtering License

URL filtering slows you to write access control rules that determine the traffic that can
traverse your network based on URLs requested by monitored hosts, correlated with
information about those URLs. To enable a Classic URL Filtering license, you must also
enable a Protection license.

Without a URL Filtering license, you can specify individual URLs or groups of URLs to allow
or block. This gives you granular, custom control over web traffic, but does not allow you to
use URL category and reputation data to filter network traffic.

You may lose access to URL fleering if you delete the license from the Firepower
Management Center or disable URL Filtering on managed devices. Also. URL Filtering
licenses may expire. If your license expires or if you delete or disable it, access control rules
with URL conditions immediately stop filtering URLs, and your Firepower Management
Center can no longer download updates to URL data. You cannot redeploy existing access
control policies if they include rules with category and reputation-based URL conditions.

96
 Bootcamp SSFIPS
Firepower Licensing Procedure

Before you add a Classic license to the Firepower Management Center make sure that you
have tie activation key provided by Cisco when you purchased the license. If you have a
legacy. Sourcefire license, contact Support.

You must enable licenses on your managed devices before you can use licensed features.
You can enable a license either when you add a device to the Firepower Management
Center, or by editing the device's general properties after you add the device.

The procedure is as follows:

Step 1

Choose System > Licenses > Classic Licenses

Step 2

Click Add New License.

Step 3

You have the following options:

- If you received an email with your license, copy the license from the email, paste it into the
License field, and click Submit License. If the license is correct, slop the rest of the
procedure.

- If you did not receive an email with your license, click Get License.

If you cannot access the Internet using your current computer, switch to another computer.

Step 4

Follow the on-screen instructions to obtain your license, which will be sent to you in an
email.
Tip: You can also request a license on the Licenses tab after you log in to the Support Site

Step 5

Copy the license from the email, paste it into the License field in the Firepower Management
Center's web interface, and click Submit License.

97
 Bootcamp SSFIPS

Assigning Licenses to Managed Devices

You can change the licensed capacities of any individual managed device by editing the
device's general properties. Although there are some exceptions, you cannot use the
features associated with a license if you disable it on a managed device.

The procedure is as follows:

Step 1

Choose Devices > Device Management

Step 2

Next to the device where you want to enable or disable a 'cense, click "he edit icon.
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to
switch.

Step 3

Click the Device tab

Step 4

Next to the License section, click the edit icon.

Step 5

Enable or disable the licensed capabilities of the device by clearing or selecting the
appropriate check boxes.

Step 6

Click Save.

98
 Bootcamp SSFIPS

Lesson Summary

In this lesson, you learned the following:

• The Firepower Classic licensing model includes device-specific licenses that are applied to
the managed device based on the features that you want to enable on that managed device.

• A Classic license must first be registered to the Firepower Management Center c-y means
of a registration key provided to you by Cisco, and then must be applied to the managed
device in order for you to utilize that license’s features.

99
 Bootcamp SSFIPS

SecureBank Scenario-Device Management

The graphic shows the solutions to the requirements outlined for SecureBank at the
beginning of this module.

100
 Bootcamp SSFIPS

Module Summary for "Deploying Cisco Firepower Managed Devices"

In this module, you learned the following:

• The Firepower System can be deployed in various ways in your environment, either inline
or passively. How you deploy it depends on many factors, including the type of Firepower
device that you have and where you have it deployed in the network.

• Upon first setup, you must register the managed device to the Firepower Management
Center, which is a multistep process that establishes the communication channel between
the two.

• Firepower Classic licenses are now device-specific licenses. They are managed on your
Firepower Management Center and are applied to the managed devices based on the
features that you choose to enable on those devices.

101
 Bootcamp SSFIPS

Knowledge Check

102
 Bootcamp SSFIPS

Module 5: Firepower Discovery

Overview

Description
This module will give you a thorough understanding of the Firepower discovery process.
Firepower discovery involves the collection of host and user information performed by the
managed device and the information is stored in your Firepower Management Center.

Objectives
Upon completing this module. You will be able to perform an initial Cisco Firepower
discovery to identify hosts, applications, and services. This ability includes being able to
meet these objectives:

 Describe Firepower discovery

 Interpret host profile information
 Describe user identity

103
 Bootcamp SSFIPS

Secure Bank Scenario- Firepower Discovery

Requirements

SecureBank needs to tune discovery parameters to help prevent future issues with
performance and to help minimize false positives.

They are concerned that they eventually might have more hosts than are supported based
on the Firepower Management Center's capabilities.

SecureBank does not intend to monitor users.

This module will describe how the Firepower discovery process can be used to help meet
the requirements shown in the graphic

Logical Course Outline

SETUP IMPLEMENTATION

Deploying Cisco Access Control Policy Prerequisits Next Generation intrusión prevention
Systems NGIPS
Firepower
Managed Devices
Implementing Access Control Policies
Network Analisys Policies

Security Intelligent
Detailed Analisys Techniques
Firepower recovery
File control and Adv.
Malvare Protection

Now that you have the Firepower System set up, you will need to configure your Discovery.
This is a critical step for your deployment, because the firepower System relies on this
discovered information to protect your network

104
 Bootcamp SSFIPS
Examining Network Discovery
Description
This lesson introduces the Discovery types and the firepower System. The lesson concludes
with an introduction to Discovery policies that allow the Discovery to be configured.

Objectives
After completing this lesson, you will be able to do the following

 Introduce Firepower Discovery concepts

 Describe host fingerprinting
 Describe the Network Discovery modes
 Describe the operation of Current Identity
 Describe Firepower Discovery policies

105
 Bootcamp SSFIPS
Firepower Discovery Components

 Firepower Discovery inspects the traffic passing through the managed device and
discovers
o Users
o Hosts

Firepower Discovery inspects the traffic passing through the managed device and discovers
both users and hosts. User Discovery requires the configuration of an identity source, or
passive Discovery. Hosts are discovered by default. Acitve Discovery is optional to augment
the discovery if needed.

Why Perform Discovery of Hosts and Users?

You will use this discovered information throughout your Firepower
System for analysis and automation of security protection

106
 Bootcamp SSFIPS
Host Fingerprinting

New information about your discovered hosts is changing in real time. This behavior is
expected. The identity of the operating system and its associated applications at any one
time is referred to as the host's current identity.
Vulnerabilities are based on what has been detected passively on the host profile.
For example. Linux 2.6 is detected as an operating system. The system has a vulnerability
database" that lists all known vulnerabilities for this operating system. These vulnerabilities
are automatically appended to the host profile. This action occurs for applications and
Services automatically as well.

How Firepower Obtains Host Information

► Firepower uses host fingerprinting to determine host information.

■ Matches against specific packet header values.
■ Other unique data from network traffic against established definitions.
► Custom fingerprints can also be created (if systems cannot identify unique
operating systems).
► Firepower can determine
■ Number and types of hosts
■ Including load balancers, routers, bridges, and NAT devices
■ Basic network topology (including hop counts from discovery point)
■ Operating systems running on the hosts
■ Applications on the hosts and users associated with those applications

The Firepower System performs host discovery by host fingerprinting. As the Firepower
System passively monitors the traffic that travels through your network, it compares

107
 Bootcamp SSFIPS
Specific packet header values and other unique data from network traffic against established
definitions {called fingerprints) to determine information about the hosts on your network
including the following:
• The number and types of hosts {including network devices such as bridges. routers. load
balancers. and NAT devices)
• Basic network topology data, including the number of hops from the discovery point on the
network to the hosts
• The operating systems running on the hosts
• Applications on the hosts and users associated with these applications
If the system cannot identify a hosts operating system, you can create custom client or
server fingerprints.
The system uses these fingerprints to identify new hosts. You can map fingerprints to
systems in the vulnerability database (VDB) to allow the appropriate vulnerability information
to be displayed whenever a host is identified with the custom fingerprint.

108
 Bootcamp SSFIPS
Network Discovery Modes

There are two types of detection: passive and active. The purpose of both types is to
populate host application and user data in the system. This is a primary function of
Firepower because this data is used to both augment analysis and protect these hosts.
For hosts passive discovery is the default and ¡t happens automatically when a discovery
policy is configured. It is also the primary way to populate your host profile database. If the
information detected by these hosts is incomplete, you can enable active discovery as well
to augment the data collected about these hosts. You would need to set this up and
configure it but it is typically not necessary.
For users passive discovery is for plain-text user information only. This is not authenticated
information {the information is seen in the traffic passively and is not authenticated by a
trusted source) and may have limited use in your environment.
If you want to pull in authenticated users you must set up active discovery of users. This will
be discussed later in this module.

109
 Bootcamp SSFIPS
Passive Detection-Default for host

Passive detection is the detection of host operating system, client and application
information through the analysis of traffic passively collected by the system. The system
uses information in the VDB to help it identify your network assets.
If the system cannot identify an operating system on a host, you can manually determine it
and then create a custom server or client fingerprint to help the system recognize that
operating system on other hosts with similar operating system characteristics.
The system uses all collected passive fingerprints for a host operating system to create a
derived fingerprint.
The system creates derived fingerprints by applying a formula that calculates the most likely
identity by using the confidence value of each collected fingerprint and the amount of
corroborating fingerprint data between identities. Common elements are identified between
identities.
If you use custom applications on your network, you can augment the system's application
detection capabilities by creating custom application detection that provide the system with
the information it needs to identify those applications. Data from NetFIow exporters can also
add passively detected application information to the network map.

110
 Bootcamp SSFIPS
Active detection adds host information collected by active sources to network maps. For
example: you can use the Nmap scanner, built into the Firepower Management
Center and managed device, to actively scan the hosts that you target on your network.
Nmap discovers operating systems and applications on hosts.
In addition, the host input feature allows you to actively add host input data to network maps.
There are two categories of host input data:
• User input data—Data added through the Firepower System user interface. You can
modify a hosts operating system or application identity through this interface.
• Host import input data—Data imported using a command-line utility.
The system retains one identity for each actively source. When you run an Nmap scan
instance, for example: the results of the previous scan are replaced with the new scan
results. However, if you run an Nmap scan and then replace those results with data from a
client whose results are imported through the command line, the system retains both the
identities from the Nmap results and the identities from the import client. The system then
uses the priorities set in the network discovery policy to determine which actively identity to
use as the current identity.
Note that user input is considered one source, even if it comes from different users. As an
example. if UserA sets the operating system through the host profile, and then UserB
changes that definition through the host profile. The definition set by UserB is retained, and
the definition set by UserA is discarded. In addition, note that user input overrides all other
actively sources and is used as the current identity if it exists.

You can augment the network map by importing network map data from third parties. You
can also use the host input feature by modifying operating system or application identities or
deleting application protocols, protocols, host attributes, or clients, by using the web
interface.
The system may reconcile data from multiple sources to determine the current identity of an
operating system or application.
All data except third-party vulnerabilities is discarded when the affected host is removed
from the network map. For more information on setting up scripts or import files, see the
Firepower System Host Input API Guide.

111
 Bootcamp SSFIPS
To include imported data in impact correlations, you must map the data to the operating
system and application definitions in the database.

Requirements for Using Third-Party Data

You can import discovery data from third-party systems on your network. However, to enable
features where intrusion and discovery data are used together, such as Firepower
recommendations, adaptive profiles, or impact assessment. You should map as many
elements of it as possible to corresponding definitions. Consider the following requirements
for using third-party data:
• If you have a third-party system that has specific data on your network assets, you can
import that data by using the host input feature. However, because third parties may name
the products differently, you must map the third-party vendor, product, and versions to the
corresponding Cisco product definition.
After you map the products, you must enable vulnerability mappings for impact assessment
in the Firepower Management Center configuration to allow impact correlation. For version
less or vendor less application protocols, you need to map vulnerabilities for the application
protocols in the Firepower Management Center configuration.
• If you import patch information from a third party and you want to mark all vulnerabilities
fixed by that patch as invalid. You must map the third-party fix name to a fix definition in the
database. All vulnerabilities addressed by the fix will then be removed from hosts where you
add that fix.
• If you import operating system and application protocol vulnerabilities from a third party and
you want to use them for impact correlation. You must map the third-party vulnerability
identification string to vulnerabilities in the database. Note that although many clients have
associated vulnerabilities, and clients are used for impact assessment. You cannot import
and map third-party client vulnerabilities.
After the vulnerabilities are mapped, you must enable third-party vulnerability mappings for
impact assessment in the Firepower Management Center configuration. To cause
application protocols without vendor or version information to map to vulnerabilities. an
administrative user must also map vulnerabilities for the applications in the Firepower
Management Center configuration.
• If you import application data and you want to use that data for impact correlation you must
map the vendor string for each application protocol to the corresponding Cisco application
protocol definition.

Third-Party Product Mappings

When you add data from third parties to the network map through the user input feature, you
must map the vendor, product, and version names used by the third party to the Cisco
product definitions. Mapping the products to Cisco definitions assigns vulnerabilities based
on those definitions.
Similarly, if you are importing patch information from a third party, such as a patch
management product, you must map the name for the fix to the appropriate vendor and
product and the corresponding fix in the database.

112
 Bootcamp SSFIPS
Refer to the Firepower System Host Input API Guide for configuration:
http:/.\sww.cisco.com.'’c/en/uS',td.'doc&'Seajr¡ty/f¡repower/60/ap¡.''host-input''Ho3tl
nputAPIGuide.html

Identities can change or can be initially incorrect. The Firepower System works to best
determine the correct identity, and based on its processing may change identity if it is
determined that the identity has changed. This happens automatically and without manual
intervention. Current identity is the identity that the Firepower System detects as correct at
the current time.
The current identity for an application or an operating system on a host is the identity that the
system finds most likely to be correct
The system uses the current identity for an operating system or application for the following
purposes:
• To assign vulnerabilities to a host
• For impact assessment
• When evaluating correlation rules written against operating system identifications, host
profile qualifications, and compliance whitelists
• For display in the hosts and servers table views in workflows
• For display in the host profile
• To calculate the operating system and application statistics on the Discovery Statistics
page
The system uses source priorities to determine which active identity should be used as the
current identity for an application or operating system.

113
 Bootcamp SSFIPS
NetFIow Data in the Firepower System
NetFIow is a Cisco IOS application that provides statistics on packets flowing through a
router. It is available on Cisco networking devices and can also be embedded in Juniper.
FreeBSD. and OpenBSD devices.
When NetFIow is enabled on a network device. a database on the device {the NetFIow
cache) stores records of the flows that pass through the router. A flow. called a connection in
the Firepower System, is a sequence of packets that represents a session between a source
and destination host. using specific ports, protocol. And application protocol. The network
device can be configured to export this NetFIow data. In this documentation, network
devices configured in this way are called NetFIow exporters.
Firepower System managed devices can be configured to collect records from NetFIow
exporters, generate unidirectional end-of-connection events based on the data in those
records, and finally send those events to the Firepower Management Center to be logged in
the connection event database. You can also configure the network discovery policy to add
host and application protocol information to the database based on the information in
NetFIow connections.
You can use this discovery and connection data to supplement the data gathered directly by
your managed devices. This is especially useful if you have NetFIow exporters monitoring
networks that your managed devices cannot monitor.

Current Identity-Workflow Graph

To demonstrate current identity. look at the example in the graphic. A user sets the operating
system to Windows 2012 Server on a host, and Windows 2012 Server is the current identity.
Attach that target Windows 2012 Server vulnerabilities on that host are given a higher
impact. (Impact refers to the potential impact that an attack can have on a host and the
likelihood that the event is a false positive or a real event.) The vulnerabilities listed for that

114
 Bootcamp SSFIPS
host in the host profile include Windows 2012 Server vulnerabilities. The database may
retain information from several sources for the operating system or for a particular
application on a host.
The system treats an operating system or application identity as the current identity when
the source for the data has the highest source priority. Possible sources have the following
priority order:
1. User
2. Scanner and application {set in the network discovery policy)
3. Managed devices
4. NetFIow records
A new higher-priority application identity will not override a current application identity if it
has less detail than the current identity.
In addition, when an identity conflict occurs, the resolution of the conflict depends on settings
in the network discovery policy or on your manual resolution.

Identity conflict-Workflow Graph

What happens if there are conflicting identities'’ The system call this an identity conflict. An
identity conflict occurs when the system reports a new passive identity that conflicts with the
current active identity and previously reported passive identities. For example. the previous
passive identity for an operating system is reported as Windows 2000. and then an active
identity of Windows XP becomes current. Next. the system detects a new passive identity of
Ubuntu Linux 8.04.1. The Windows XP and the Ubuntu Linux identities are in conflict.
When an identity conflict exists for the identity of the host s operating system or one of the
applications on the host. the system lists both conflicting identities as current and uses both
for impact assessment until the conflict is resolved.

115
 Bootcamp SSFIPS
A user with Administrator privileges can resolve identity conflicts automatically by choosing
to always use the passive identity or always use the active identity. Unless you disable
automatic resolution of identity conflicts. identity conflicts are always automatically resolved.
A user with Administrator privileges can also configure the system to generate an event
when an identity conflict occurs. That user can then set up a correlation policy with a
correlation rule that uses an Nmap scan as a correlation response. When an event occurs.
Nmap scans the host to obtain updated host operating system and application data.

Built into the Firepower System is an awareness technology that helps automatically identify
properties of your network. This includes information about hosts, users, applications.
Services, traffic and potential vulnerabilities that may exist based on the preceding
information. This awareness is automatic and is based upon networks defined within your
discovery policy.

Host, Application, and User Detection

The Firepower System uses network discovery and identity policies to collect host,
application, and user data for traffic on your network. You can use certain types of discovery
and identity data to build a comprehensive map of your network assets, perform forensic
analysis, behavioral profiling, and access control, and mitigate and respond to the
vulnerabilities and exploits to which your organization is susceptible.
The data collect can assist with analysis by automatically correlating threats to potential
vulnerabilities within your environment and generating what are known as impact flags.
These flags can be used to quickly prioritize what threats should receive priority attention
within your environment. Discovery information can also be used through correlation polices
to quickly alert you to the presence of new applications or hosts within a given network. This
capability is useful for identifying avidity that the IPS may not be looking for, such as new
network Services.

116
 Bootcamp SSFIPS
Host and Application Data
Host and application data is collect by host identity sources and application detectors
according to the settings in your network discovery policy. Managed devices observe traffic
on the network segments that you specify.
The system determines the following:
• The number and types of hosts {including network devices) on your network. You can
supplement network discovery host data with data from exported NetFIow records. Nmap
active scanning, and the host input feature.
The operating systems. active applications, and open ports on those hosts.

User Data
User data is collect by user identity sources according to the settings in your network
discovery and identity policies
• Nonauthoritative traffic-based detection collects user data for user awareness. You can
configure managed devices to detect LDAP. AIM. POP3. IMAP. Orade. SI (VolP). FTP.
HTTP. MDNS. and SMTP logins.
• Authoritative User Agent reporting collect user data for user awareness and user access
control.
• Authoritative Identity Services Engine (ISE) reporting collect user data for user awareness
and user access control.
• Authoritative captive portal authentication actively authenticates users on your network and
collects user data for user awareness and user control.

Network Discovery Policy

The network discovery policy is how you manage your discovery information. Upon initial
setup. this is set to be only passive detection and to discover all hosts. Any IP detected will
be seen as a host. and a "host profile" will be created for that host. A host profile is a
collection of information about a host. such as operating system. Open ports. connections
detected. and so on. By default. the system will collect this information for all traffic that it
detects, including public IPs. If your system sees traffic that is represented by the conditions
specified in your network discovery policy. it will build host profiles for them. Upon initial

117
 Bootcamp SSFIPS
deployment. you should define what network ranges you want to protect in the network
discovery policy.
Upon initial deployment. you will want to first identify your network You do this in a network
discovery policy. This policy is set to discover everything it detects. Including hosts on the
Internet. This is not typically desired, and defining this policy is critical.
The network discovery policy on the Firepower Management Center Controls how the
system collect data on your organization's network assets and which network segments and
ports are monitored.
In a multi domain deployment. each leaf domain has an independent network discovery
policy. Network discovery policy rules and other settings cannot be shared inherited. or
copied between domains. Whenever you create a new domain. the system creates a
Network discovery policy for the new domain. using default settings. You must explicitly
apply any desired customizations to the new policy.
Remember that the access control policy for each managed device defines the traffic that
you permit for that device and. Therefore, the traffic you can monitor with network discovery.
If you block certain traffic by using access control, the system cannot examine that traffic for
host, user, or application activity. For example. if an access control policy blocks access to
social networking applications, the system cannot provide any discovery data on those
applications.
If you enable traffic-based user detection in your discovery rules, you can detected
nonauthoritative users through user login activity in traffic over a set of application protocols.
You can disable discovery in particular protocols across all rules if needed. Disabling some
protocols can help avoid reaching the user limit associated with your Firepower Management
Center model, reserving available user count for users from the other protocols.
Advanced network discovery settings allow you to manage what data is logged, how
discovery data is stored, what indications of compromise (IOC) rules are active, what
vulnerability mappings are used for impact assessment, and what happens when sources
offer conflicting discovery data. You can also add sources for host input and
NetFIow exporters to monitor.

Network Discovery Policy-Rules

118
 Bootcamp SSFIPS
You create rules to define what is to be discovered in your network and what will not be
discovered. For example. "Define private IP address ranges only." This way. The system
does not automatically build host profiles on traffic hat exists on the Internet, outside your
network
In creating and managing a network discovery policy, you use rules. Network discovery rules
allow you to tailor the information discovered for your network map to include only the
specific data that you want. Rules in your network discovery policy are evaluated
sequentially. You can create rules with overlapping monitoring criteria, but doing so may
affect your system performance.
Discovery rules within the policy specify which network and ports the Firepower System
monitors to generate discovery data based on network data in traffic, and the zones to which
the policy is deployed. Within a rule, you can configure whether hosts, applications, and
nonauthoritative users are discovered. You can create rules to exclude networking and
zones from discovery. You can configure discovery of data from NetFIow exporters and
restrict the protocols for traffic where user data is discovered on your network
The network discovery policy has a single default rule in place, configured to discover
applications from all observed traffic. The rule does not exclude any networks zones, or
ports, host and user discovery is not configured, and the rule is not configured to monitor a
NetFIow exporter This policy is deployed by default to any managed devices when they are
registered to the Firepower Management Center. To begin collecting host or data, you must
add or modify discovery rules and redeploy the policy to a device. If you want to adjust the
scope of network discovery. you can create additional discovery rules and modify or remove
the default rule.
When you exclude a host or a network from monitoring. the host or network does not appear
in the network map and no events are reported for it. Cisco recommends that you exclude
load balancers {or specific ports on load balancers) and NAT devices from monitoring.
These devices may create excessive and misleading events, filling the database and
overloading the Firepower Management Center. For example. a monitored NAT device
might exhibit multiple updates of its operating system in a short period of time. If you know
the IP addresses of your load balancers and NAT devices, you can exclude them from
monitoring. The system can identify many load balancers and NAT devices by examining
your network traffic.
In addition. if you need to create a custom server fingerprint. you should temporarily exclude
from monitoring the IP address that you are using to communicate with the host that you are
fingerprinting. Otherwise, the network map and discovery event views will be cluttered with
inaccurate information about the host represented by that IP address. After you create the
fingerprint. you can configure your policy to monitor that IP address again.
Cisco also recommends that you not monitor the same network segment with NetFIow
exporters and Firepower System managed devices. Although. Ideally, you should configure
your network discovery policy with nonoverlapping rules, the system does drop duplicate
connection logs generated by managed devices. However. you cannot drop duplicate
connection logs for connection detected by both a managed device and a NetFIow.

119
 Bootcamp SSFIPS
Network Discovery Policy-Rule Actions

Rules have the action of either Discover or Exclude. The following list details the options:
• Exclude—Excludes the specified network from monitoring. If the source or destination host
for a connection is exclude from discovery, the connection is recorded but discovery events
are not created for exclude hosts.
• Discover Hosts—Adds hosts to the network map based on discovery events. (Optional.
unless user discovery is enabled. in which case it is required.)
• Discover Applications—Adds applications to the network map based on application
detectors. Note that you cannot discover hosts or users in a rule without also discovering
applications. (Required.)
• Discover Users—Adds users to the users table, and logs user activity based on traffic-
based detection on the user protocols configured in the network discovery policy. (Optional.)

Firepower Management Center Host Limits

120
 Bootcamp SSFIPS
The Firepower Management Center is designed to detect multiple hosts but must be kept in
check to ensure that it is not over its capacity. Keep in mind that if the host limit is full, the
last seen host will drop out of the table and you will likely see a performance impact on the
system. This is why it is critical to define your network discovery policy in tuning to ensure
that you are collecting only host profile information that represents what you want to protect
in your network.
The system adds a host to the network map when it detects activity associate with an IP
address in your monitored network {as defined in your network discovery policy).The number
of hosts that a Firepower Management Center can monitor, and therefore store in the
network map, depends on its model.
You cannot view contextual data for hosts that are not in the network map. However. you
can perform access control. For example. you can perform application control on Traffic to
and from a host not in the network map, even though you cannot use a compliance whitelist
to monitor the hosts network compliance.

The system counts MAC-only hosts separately from hosts identified by both IP addresses
and MAC addresses. All IP addresses assonated with a host are counted together as one
host.

121
 Bootcamp SSFIPS

Lesson Summary

ln this lesson. you learned the following:

• Firepower Discovery ¡s how the Firepower System collects both host and user data about
your environment and uses that information for both analysis and security automation.
• Host fingerprinting ¡s how the Firepower System uses the network traffic that the
managed device detects and. based on network discovery and other configurations.
automatically populates information in your host profiles.
• Of the two network discovery modes—active and passive—passive happens
automatically and is how host profiles get populated. Active can be used to pull in
authenticated user data and to augment your hosts.
• Current identity is what Firepower detects as the most accurate identity of your hosts. It
is designed to change. based on the traffic that your managed device detects.
• Firepower discovery policies must be set up to define your network and enable you to
dictate which hosts that are detected in the traffic should have host profiles built.

Interpreting Host Profile Information

Description

This lesson explores Host Profiles, which are the host tables that are automatically
populated by the Firepower Discovery. You will see a breakdown of the host profile
information, along with how vulnerabilities are detected based on that information. The
lesson concludes with some troubleshooting tips.

Objectives

After completing this lesson. you will be able to do the following:

 Describe host profiles

 Define basic host profile information
 Define further host profile ¡information
 Describe vulnerabilities as they relate to your host profiles
 Describe how to troubleshoot inaccurate host profile information

122
 Bootcamp SSFIPS

A host profile provides a complete view of all the information that the system has gathered
about a single host. You just saw how the Firepower System gathers this information. Now
you will learn what information has been gathered.
To access a host profile, do the following:
• Navigate from any network map view.
• Navigate from any event view that includes the IP addresses of hosts on monitored
networks.
Host profiles provide basic information about detected hosts or devices, such as the host
name or MAC addresses. Depending on your licenses and system configuration, host
profiles can also provide you with the following information:
• the operating system running on a host
• the servers running on a host
• the clients and web applications running on a host
• the protocols running on a host
• the indications of compromise (IOC) tags on a host
• the VLAN tags on a host
• the last 24 hours of user activity on your network
• the whitelist violations associated with a host
• the most recent malware events for a host
• the vulnerabilities associated with a host
• the Nmap scan results for a host

Host attributes are also listed in the profile. You can use host attributes to classify hosts in
ways that are important to your network environment. For example, you can do the following:
• Assign a host attribute that indicates the building where the host is located
• Use the host criticality attribute to designate the business criticality of a given host
and tailor correlation policies and alerts based on host criticality

From a host profile, you can view the existing host attributes applied to that host and modify
the host attribute values.

If you use adaptive profiles as part of intrusion prevention, you can tailor the way that the
system processes traffic, so that it best fits the type of operating system on the host and the
servers and clients that the host is running.

123
 Bootcamp SSFIPS
Optionally, you can perform an Nmap scan from the host profile to augment the server and
operating system information in your host profile. The Nmap scanner actively probes the
host to obtain information about the operating system and servers running on the host. The
results of the scan are added to the list of operating system and server identities for the host.

This topic describes each of the basic host profile fields.

Domain

The domain field displays the domain associated with the host.

IP Addresses

The IP addresses field displays the all IP addresses {both IPv4 and IPv6) associated with
the host. The system detects IP addresses associated with hosts and. where supported,
groups multiple IP addresses used by the same host. IPv6 hosts often have at least two IPv6
addresses {local-only and globally routable) and may also have IPv4 addresses. IPv4-only
hosts may have multiple IPv4 addresses.

The host profile lists all detected IP addresses associated with that host. Where available,
routable host IP addresses also include a flag icon and country code indicating the
geolocation data associated with that address.

Note that only the first three addresses are shown by default. Click show all to show all
addresses for a host.

Hostname

The hostname field displays the fully qualified domain name of the host, if known.

NetBIOS Name

The NetBIOS Name field displays the NetBIOS name of the host, if available. Microsoft
Windows hosts, as well as Macintosh. Linux, or other platforms configured to use NetBIOS,

124
 Bootcamp SSFIPS
can have a NetBIOS name. For example. Linux hosts configured as Samba servers have
NetBIOS names.

MAC Addresses (TTL)

The host's detected MAC address or addresses and associated NIC vendors, with the NIC's
hardware vendor and current time-to-live {TTL) value in parentheses. If the MAC address is
displayed in a bold font, the MAC address is the actual MAC address of the host, detected
by the system through ARP and DHCP traffic. If multiple devices detected the host, the
Firepower Management Center displays all MAC addresses and TTL values associated with
the host, regardless of which device reported them. Router host profiles typically show the
hosts (IP addresses) in the network segments that they route in this list, and the IP
addresses of monitored routers frequently appear in this list for monitored workstations and
servers. The true IP address for the MAC address is displayed in bold.

Host Type

The type of device that the system detected: host, mobile device, jail-broken mobile device,
router, bridge. NAT device, or load balancer. The methods that the system uses to
distinguish network devices include the following:
• The analysis of Cisco Discovery Protocol messages, which can identify network devices
and their type (Cisco devices only).
• The detection of the Spanning Tree Protocol (STP), which identifies a device as a switch
or bridge.
• The detection of multiple hosts using the same MAC address, which identifies the MAC
address as belonging to a router.
• The detection of TTL value changes from the client side, or TTL values that change more
frequently than a typical boot time, which identify NAT devices and load balancers.
The methods that the system uses to distinguish mobile devices include the following:

125
 Bootcamp SSFIPS
• Analysis of User-Agent strings in HTTP traffic from the mobile device's mobile browser
• Monitoring of HTTP traffic of specific mobile applications
If a device is not identified as a network device or a mobile device, it is categorized as a
host.

Last Seen

The last seen field contains the date and time that any of a host's IP addresses was last
detected.
Current User

The current user field contains the user most recently logged in to this host.

A nonauthoritative user logging in to a host registers as the current user on the host
only if the existing current user is not an authoritative user.

View

This menu contains links to views of connection, discovery, malware, and intrusion event
data, using the default workflow for that event type and constrained to show events related
to the host. Where possible, these events include all IP addresses associated with the host.

The Servers Section of the host profile lists servers either detected on hosts on your
monitored network, added from exported NetFlow records, or added through an active
source like a scanner or the host input feature.

The list can include up to 100 servers per host. After that limit is reached, new server
information from any source, whether active or passive, is discarded until you delete a server
from the host or a server times out. If you scan a host using Nmap. Nmap adds the results of
previously undetected servers running on open TCP ports to the Servers list. If you perform
an Nmap scan or import Nmap results, an expandable Scan Results section also appears in
the host profile, listing the server information detected on the host by the Nmap scan.

126
 Bootcamp SSFIPS
In addition, if the host is deleted from the network map, the Nmap scan results for that server
for the host are discarded.

The system passively detects the identity of the operating system running on a host by
analyzing the network and application stack in traffic generated by the host or by analyzing
host data reported by the User Agent.

The system also collates operating system information from other sources, such as the
Nmap scanner or application data imported through the host input feature. The system
considers the priority assigned to each identity source when determining which identity to
use. By default, user input has the highest priority, followed by application or scanner
sources, followed by the discovered identity.

Sometimes the system supplies a general operating system definition rather than a specific
one, because the traffic and other identity sources do not provide sufficient information for a
more focused identity. The system collates information from the sources to use the most
detailed definition possible.

Because the operating system affects the vulnerabilities list for the host and the event impact
correlation for events targeting the host, you may want to manually supply more specific
operating system information. In addition, you can indicate that fixes have been applied to
the operating system, such as service packs and updates, and invalidate any vulnerabilities
addressed by the fixes.

For example, if the system identifies a host's operating system as Microsoft Windows 7. but
you know that the host is actually running Microsoft Windows 8. you can set the operating
system identity accordingly. Setting a more specific operating system identity refines the list
of vulnerabilities for the host, so your impact correlation for that host is more focused and
accurate.

If the system detects operating system information for a host and that information conflicts
with a current operating system identity that was supplied by an active source, an identity
conflict occurs. When an identity conflict is in effect, the system uses both identities for
vulnerabilities and impact correlation. You can configure the network discovery policy to add

127
 Bootcamp SSFIPS
discovery data to the network map for hosts monitored by NetFlow exporters. However,
there is no operating system data available for these hosts, unless you use the host input
feature to set the operating system identity.

If a host is running an operating system that violates a compliance whitelist in an activated

network discovery policy, the Firepower Management Center marks the operating system
information with the whitelist violation icon. In addition, if a jail-broken mobile device violates
an active whitelist. the icon appears next to the operating system for the device. You can set
a custom display string for the host's operating system identity. That display string is then
used in the host profile.

In the host profile for a network device, the label for the Operating Systems section changes
to Systems and an additional Hardware column appears. If a value for a hardware platform
is listed under Systems, that system represents a mobile device or devices detected behind
the network device. Note that mobile devices may or may not have hardware platform
information, but hardware platform information is never detected for systems that are not
mobile devices.

The Web Application section of the host profile displays the clients and web applications that
the system identifies as running on the hosts on your network. The system can identify client
and web application information from both passive and active detection sources, although
the information for hosts added from NetFlow records is limited.

Details in this section include the product and version of the detected applications on a host,
any available client or web application information, and the time that the application was last
detected in use. The section lists up to 1© clients running on the host. After that limit is
reached, new client information from any source, whether active or passive, is discarded
until you delete a client application from the host or the system deletes the client from the
host profile due to inactivity {the client times out). Additionally, for each detected web
browser, the system displays the first 100 web applications accessed.

128
 Bootcamp SSFIPS

After that limit is reached, new web applications associated with that browser from any
source, whether active or passive, are discarded until either of the following occurs:
• The web browser client application times out.
• You delete application information associated with a web application from the host
profile.

If the host is running an application that violates a compliance whitelist in an activated

correlation policy, the Firepower Management Center marks the noncompliant application
with a whitelist violation icon.

Descriptions of the application information that appears in a host profile follow.

Application Protocol

The Application Protocol column displays the application protocol used by the application
(HTTP browser. DNS client, and so on).

Client

The Client column displays information derived from payload if identified by the Firepower
System, captured by Nmap, or acquired via the host input feature. The field is blank if none
of the available sources provides an identification.

Version
The Version column displays the version of the client

Web Application
For web browsers. Web Application is the content detected by the system in the http traffic.
Web application information indicates the specific type of content {for example. WMV or
QuickTime) identified by the Firepower System, captured by Nmap. or acquired via the host
input feature. The field is blank if none of the available sources provides an identification.

Host Protocols in the Host Profile

Each host profile contains information about the protocols detected in the network traffic
associated with the host. This information includes the following:
• Protocol—The name of a protocol used by the host
• Layer—The network layer where the protocol runs (Network or Transport)
If a protocol displayed in the host profile violates a compliance whitelist in an activated
correlation policy, the Firepower Management Center marks the noncompliant protocol with
the whitelist violation icon.
If the host profile lists protocols that you know are not running on the host, you can delete
those protocols. Deleting a protocol from a host may bring the host into compliance with a
compliance whitelist.

129
 Bootcamp SSFIPS

Introduced in Firepower Version 5.3.

the Firepower System can correlate various types of data {intrusion events. Security
Intelligence, connection events, and file or malware events) associated with hosts to
determine whether a host on your monitored network is likely to be compromised by
malicious means.

Certain combinations and frequencies of event data trigger indication-of-compromise (IOC)

tags on affected hosts. The Indications of Compromise section of the host profile displays all
IOC tags for a host. In that section, you can view details of the threats facing the host, jump
to the events that triggered an IOC tag, edit IOC rule states, and resolve IOC tags that are
no longer relevant.

To use the IOC feature, you must activate the feature and at least one IOC rule in your
discovery policy. You can also edit IOC rule states for individual hosts from that host's host
profile page. Each IOC rule corresponds to one type of IOC tag; you can activate any or all
rules, depending on your organization's needs. In addition to its presence in the host profile,
you can also analyze IOC data in the event viewer.

The following subtopics describe the IOC information fields displayed in the host profile:

• IP Address—The IP address associated with the host that triggered the IOC.
• Category—Brief description of the type of compromise indicated, such as Malware
Executed or Impact 1 Attack.
• Event Type—Identifier associated with a specific IOC, referring to the event that
triggered it.
• Description—Description of what threatens the potentially compromised host, such as
"This host may be under remote control or malware has been executed on this host."

First/Last Seen—The first {or most recent) date and time that events triggering a host's IOC
occurred.

130
 Bootcamp SSFIPS

An optional piece of data that you can use to augment the host profile is what is called a host
attribute. This action does not occur by default, but it can help the analyst garner meta
information when looking at a given host. You can use host attributes to classify hosts in
ways that are important to your network environment. Three types of attributes are present in
the Firepower System:
• Predefined host attributes
• Whitelist host attributes
• User-defined host attributes

After you set a predefined host attribute or create a user-defined host attribute, you must
assign a host attribute value.

Predefined Host Attributes

• Host Criticality—Use this attribute to designate the business criticality of a given host
and to tailor correlation responses to host criticality. For example, if you consider your
organization's mail servers as more critical to your business than a typical user
workstation, you can assign a value of High to your mail servers and other business-
critical devices, and Medium or Low to other hosts. You can then create a correlation
policy that launches various alerts based on the criticality of an affected host.

Use this host-specific attribute to record information about the host that you want other
analysts to view. For example, if you have a computer on the network that has an older,
unpatched version of an operating system that you use for testing, you can use the Notes
feature to indicate that the system is intentionally unpatched.

• White List Host Attributes—Each compliance whitelist that you create automatically
creates a host attribute with the same name as the whitelist. Possible values for whitelist
host attributes are as follows:
- Compliant—Identifies hosts that are compliant with the whitelist.
- Non-Compliant—Identifies hosts that violate the whitelist.
- Not Evaluated—Identifies hosts that are not valid targets of the whitelist or
have not been evaluated for any reason.

You cannot edit the value of a whitelist host attribute, or delete a whitelist host attribute.

131
 Bootcamp SSFIPS
User-Defined Host Attributes

If you want to identify hosts using criteria that differs from those used in the predefined host
attributes or whitelist host attributes, you can create user-defined host attributes. For
example, you can do the following:

• Assign physical location identifiers to hosts, such as a facility code. city, or room number.
• Assign a Responsible Party Identifier that indicates which system administrator is
responsible for a given host. You can then craft correlation rules and policies to send
alerts to the correct system administrator when problems related to a host are detected.
• Automatically assign values to hosts from a predefined list based on the hosts' IP
addresses. This feature can be useful for assigning values to new hosts when they
appear on your network for the first time.

User-defined host attributes appear in the host profile page, where you can assign values on
a per-host basis. You can also do the following:

• Use the attributes in correlation policies and searches.

• View the attributes on the host attribute table view of events and generate reports based
on them.

The following are types of user-defined host attributes that you can create:

• Text—Allows you to manually assign a text string to a host.

• Integer—Allows you to specify the first and last number of a range of positive integers,
and then manually assign one of these numbers to a host.
• List—Allows you to create a list of string values, and then manually assign one of the
values to a host. You can also automatically assign values to hosts based on the host's
IP addresses.

If you auto-assign values based on one IP address of a host with multiple IP addresses,
those values will apply across all addresses associated with that host. Keep this in mind
when you view the Host Attributes table. When automatically assigning list values, consider
using network objects rather than literal IP addresses. This approach can improve
maintainability, particularly in a multidomain deployment where using override-enabled
objects allows descendant domain administrators to tailor ancestor configurations to their
local environments. In a multidomain deployment, be careful when defining auto-assigned
lists at ancestor domain levels, to avoid matching unintended hosts when the descendant
domains use overlapping IP addresses.

 URL—Allows you to manually assign a URL value to a host.

132
 Bootcamp SSFIPS

In the host profiles, the operating system, services seen, and applications detected can have
associated vulnerability data. This data will automatically be appended to the host profile
when a new operating system, application, or service is detected.

Vulnerabilities in the Firepower System are an important way in which the system both
protects your network and provides critical analysis functionality. This is done from
automated analyst components called Impact Flags, as well as automated Firepower
processes that protect your hosts, such as Firepower Recommendations.

The Vulnerabilities sections of the host profile list the vulnerabilities that affect that host.
These vulnerabilities are based on the operating system, servers, and applications that the
system detected on the host.

133
 Bootcamp SSFIPS
If there is an identity conflict for either the identity of the host's operating system or one of
the application protocols on the host, the system lists vulnerabilities for both identities until
the conflict is resolved.

Because no operating system information is available for hosts added to the network map
from NetFlow data, the system cannot assign Vulnerable {impact level 1: red) impact levels
for intrusion events involving those hosts. In such cases, use the host input feature to
manually set the operating system identity for the hosts. Server vendor and version
information is often not included in traffic. By default, the system does not map the
associated vulnerabilities for the sending and receiving hosts of such traffic. However, you
can configure the system to map vulnerabilities for specific application protocols that do not
have vendor or version information.

If you use the host input feature to add third-party vulnerability information for the hosts on
your network, additional Vulnerabilities sections appear. For example, if you import
vulnerabilities from a QualysGuard Scanner, host profiles include a QualysGuard
Vulnerabilities section. For third-party vulnerabilities, the information in the corresponding
Vulnerabilities section in the host profile is limited to the information that you provided when
you imported the vulnerability data, using the host input feature. You can associate third-
party vulnerabilities with operating systems and application protocols, but not clients.

For information on importing third-party vulnerabilities, see the Firepower System Host Input
API Guide at http:ZAvww.cisoo.eom/c/en/us/td/docs/securityZfirepower/60/api /host-
input’HostlnputAPIGuide.html.

Descriptions of the columns in the Vulnerabilities sections of the host profile are as follows:

• Name—The name of the vulnerability.

• Remote—Indicates whether the vulnerability can be remotely exploited. If this
column is blank, the vulnerability definition does not include this information.
• Component—The name of the operating system, application protocol, or client
associated with the vulnerability.
 Port—A port number, if the vulnerability is associated with an application protocol
running on a specific port.

134
 Bootcamp SSFIPS

Expanding the vulnerability can show you details on the vulnerability, as shown in the
graphic. This is particularly useful for the analyst when researching a malicious event related
to the host.

You can download patches to mitigate the vulnerabilities discovered on the hosts on your
network.

Follow these steps:

Step 1
Access the host profile of a host for which you want to download a patch.
Step 2
Expand the Vulnerabilities section.
Step 3
Click the name of the vulnerability that you want to patch.

135
 Bootcamp SSFIPS
Step 4
Expand the Fixes section to display the list of patches for the vulnerability.

Step 5
Click Download next to the patch that you want to download.
Step 6
Download the patch and apply it to your affected systems.

Network discovery is a critical part of your system. Improper discovery of traffic will result in
many capabilities of the Firepower System becoming either unavailable to you or greatly
diminished. The issues described in this topic are the most common types that you may see.
and the questions listed in the graphic can help you determine the cause.

Missing Host Profiles

A host profile may not be available for every host on your network. Some possible reasons
are as follows:
• The host was deleted from the network map because it timed out.
• You have reached your host license limit.
• The host resides in a network segment that is not monitored by the network
discovery policy.

Pending or Unknown Operating Systems

Keep in mind that seeing the "Pending or unknown operating systems" message in the host
profile is part of how the system works. If a user who has never been seen before logs in to
the network and simply browses the web for a few minutes, it may not be enough data for
the Firepower System to detect the operating system. However, if in your largely static
network segment you see the "Pending or unknown operating systems" message there may
be an issue. If you have a vulnerability scanner in your network, for example, pulling this
data into the system can greatly improve the operation of your system. You will see more
precisely how in later modules of this course.

136
 Bootcamp SSFIPS

Lesson Summary

In this lesson, you learned the following:

• Host profiles are automatically generated by the Firepower System, based on the traffic
inspected as defined by the network discovery policy.
• Basic Host profile information includes the IP. current user, and hops from the managed
devices that identified the traffic associated with that host.
• Host profiles also contain information such as the operating system detected on that
host, applications seen running on the host, protocols seen, indications of compromise,
and any host attributes that were configured.
• Vulnerabilities for your host profiles come from the VDB in the Firepower System and are
automatically populated based on what is detected on that host.
• Missing host profiles and inaccurate operating system information on your hosts are the
two most common Firepower Discovery issues.

Examining User Identity

Description

This lesson explores user identity, where the Firepower System can collect and store user
information from either passive traffic observation or an external authenticated source, such
as ISE, AD, and the system's active authentication option. Captive Portal.
Objectives
After completing this lesson, you will be able to do the following:
• Describe the role of user identity
• Describe the user identity sources
• Describe the nonauthoritative identity source
• Describe the User Agent identity source
• Describe the ISE identity source
• Describe the Captive Portal identity source
• Describe the steps for creating an authoritative user identity source

137
 Bootcamp SSFIPS

The Firepower System can capture and manage user information in addition to hosts. This
capability can serve many purposes and can be put into two categories: authoritative
authentication and user awareness. User awareness is the process of simply maintaining
user data in the system. The type of data depends on many factors, mostly the identity
source. Authoritative authentication can allow the administrator to use users in access
control policy. This allows for user and group control for your managed users.

As with host limits that you saw earlier, the Firepower Management Center also has
restriction on user limits. Before configuring your Firepower Management Center for user
visibility and control, you will need to determine how many users you can manage, based on
the system limits. It is best to not approach the capacity of the system, because performance
issues can ensue.

Firepower System User Limit

Your Firepower Management Center model determines how many individual users you can
monitor. When the system detects activity from a new user, that user is added to the Users
database on the Firepower Management Center. You can detect users by using User
Agents. ISE. Captive Portal, and traffic-based detection. There are two types of user limits to
consider:

• The authoritative user limit, which is the number of access-controlled users that you can
store in the database and use for access control. Authoritative user data is gathered by
User Agents. ISE devices, and Captive Portal.
• The total user limit, which is the number of authoritative and nonauthoritative users that
you can store in the database. This limit includes User Agent. ISE. and Captive Portal
data, as well as nonauthoritative user data gathered with the use of traffic-based
detection.

138
 Bootcamp SSFIPS
When the system detects a new. previously undetected user after the limit has been
reached, it prioritizes user data based on their identity source:
• If the new user is from a nonauthoritative identity source, the system does not add the
user to the database. To allow new users to be added, you must delete users manually
or with a database purge.
• If the new user is from an authoritative identity source, the system deletes the
nonauthoritative user who has remained inactive for the longest period and adds the new
user to the database.

You have four user identity sources to choose from when capturing user identities. These
are divided into two categories: Authoritative and Non-Authoritative.

Authoritative identity sources are those that require a realm and an identity policy. A realm
consists of one or more LDAP or Microsoft Active Directory servers that share the same
credentials. You must configure a realm if you want to perform user and user group queries
or user access control, or if you want to configure an authoritative identity source {User
Agent. ISE. or Captive Portal).

An identity policy associates traffic on your network with an authoritative identity source and
a realm. After configuring an identity policies, you can associate it with an access control
policy and deploy the access control policy to a managed device.

Active Detection

You configure the Firepower Management Center to work with user data from Active
Directory. LDAP, or other external systems. This is known as authoritative.

139
 Bootcamp SSFIPS
Passive Detection

Passive detection works automatically from plain text users seen in the traffic passing
through your managed device. It is also called nonauthoritative.

Data from the identity sources is stored in the Firepower Management Center's users
database and the user activity database. You can configure Firepower Management Center
server user downloads to automatically and regularly download new user data to your
databases.

Traffic-based detection is the only nonauthoritative identity source supported by the

Firepower System. When configured, managed devices detect LDAP. AIM. POP3. IMAP.
Oracle. SIP (VoIP). FTP. HTTP. MDNS. and SMTP logins on the networks you specify. The
data gained from traffic-based detection can be used only for user awareness. Unlike with
authoritative identity sources, you configure traffic-based detection in your network discovery
policy.

Note the following limitations:

• Traffic-based detection interprets only Kerberos logins for LDAP connections as LDAP
authentications. Managed devices cannot detect encrypted LDAP authentications using
protocols such as SSL or TLS.
• Traffic-based detection detects AIM logins using the OSCAR protocol only. They cannot
detect AIM logins using TOC2.
• Traffic-based detection cannot restrict SMTP logging, because users are not added to
the database based on SMTP logins. Although the system detects SMTP logins, the
logins are not recorded unless there is already a user with a matching email address in
the database.
Traffic-based detection also records failed login attempts. A failed login attempt does not add
a new user to the list of users in the database. The user activity type for detected failed login
activity detected by traffic-based detection is Failed User Login.

140
 Bootcamp SSFIPS

When a device detects a login using traffic-based detection, it sends the following
information to the Firepower Management Center to be logged as user activity:
• The username identified in the login
• The time of the login
• The IP address involved in the login, which can be the IP address of the user's host {for
LDAP. POP3. IMAP, and AIM logins), the server (for HTTP. MDNS. FTP. SMTP and
Oracle logins), or the session originator {for SIP logins)
• The user's email address {for POPS. IMAP, and SMTP logins)
• The name of the device that detected the login

If the user was previously detected, the Firepower Management Center updates that user's
login history. Note that the Firepower Management Center can use the email addresses in
POP3 and IMAP logins to correlate with LDAP users. This means that, for example, if the
Firepower Management Center detects a new IMAP login, and the email address in the
IMAP login matches that for an existing LDAP user, the IMAP login does not create a new
user; rather, it updates the LDAP user's history.

If the user was previously undetected, the Firepower Management Center adds the user to
the users database. Unique AIM. SIP, and Oracle logins always create new user records,
because there is no data in those login events that the Firepower Management Center can
correlate with other login types.
The Firepower Management Center does not log user activity or user identities in the
following cases:

• If you configured the network discovery policy to ignore that login type
• If a managed device detects an SMTP login, but the users database does not contain a
previously detected LDAP. POP3, or IMAP user with a matching email address

The user data is added to the users table.

141
 Bootcamp SSFIPS
Traffic-Based Detection Strategies

You can restrict the protocols where user activity is discovered, to reduce the total number of
detected users so that you can focus on users likely to provide the most complete user
information. Limiting protocol detection helps minimize username clutter and preserve
storage space on your Firepower Management Center. Consider the following when
selecting traffic-based detection protocols:
• Obtaining usernames through protocols such as AIM. POP3, and IMAP may introduce
usernames not relevant to your organization, due to network access from contractors,
visitors, and other guests.
• AIM. Oracle, and SIP logins may create extraneous user records. This occurs because
these login types are not associated with any of the user metadata that the system
obtains from an LDAP server, nor are they associated with any of the information
contained in the other types of login that your managed devices detect. Therefore, the
Firepower Management Center cannot correlate these users with other types of users.

The User Agent is a passive authentication method and one of the authoritative identity
sources supported by the Firepower System. When integrated with the Firepower System,
the agent monitors users when they log in and out of hosts or authenticate with Active
Directory credentials. The User Agent does not report failed login attempts. The data gained
from the User Agent can be used for user awareness and user control. You invoke passive
authentication in your identity policy.

Installing and using User Agents allows you to perform user control: the agents associate
users with IP addresses, which allows access control rules with user conditions to trigger.
You can use one agent to monitor user activity on up to five Active Directory servers and
send encrypted data to up to five Firepower Management Centers.

The User Agent requires a multistep configuration and includes the following:
• Computers or servers with the agent installed
• Connections between a Firepower Management Center and the computers or Active
Directory servers with the agent installed
• Connections between each Firepower Management Center and the monitored Active
Directory servers, configured as directories within identity realms

You can install an agent on any computer or server running one of the following:

142
 Bootcamp SSFIPS
• Microsoft Windows Vista
• Microsoft Windows 7
• Microsoft Windows 8
• Microsoft Windows Server 2003
• Microsoft Windows Server 2008
• Microsoft Windows Server 2012

The computer must also have TCP/IP access to the Firepower Management Center and the
Microsoft Active Directory servers that you want to monitor. You can also install an agent on
any Active Directory server running one of the supported operating systems. If you want to
perform real-time data retrieval, the server must be running Windows Server 2008 or
Windows Server 2012.

Make sure that the time on your computer or Active Directory server is synchronized with the
time on the Firepower Management Center. If the appliances are not synchronized, the
system may perform user timeouts at unexpected intervals.

For detailed information about the multistep User Agent configuration and a complete
discussion of the server requirements, see the Firepower User Agent Configuration Guide,
located here:

http:/?\s\sw.dsco.com.'’o’en/us''support''security/defense-center/products-installation-and-
configuration-guides-list.html

The Firepower Management Center connection not only allows you to retrieve metadata for
the users whose logins and logoffs were detected by User Agents, but also is used to specify
the users and groups that you want to use in access control rules. If the agent is configured
to exclude specific usernames, login data for those usernames is not reported to the
Firepower Management Center. User agent data is stored in the user database and user
activity database on the Firepower Management Center.

All of the data gained from the Identity Services Engine (ISE) can be used on the Firepower
Management Center for user awareness. The data gained from ISE about users who
authenticated via an AD domain controller can be used for user control. You cannot perform

143
 Bootcamp SSFIPS
user control on users who were authenticated via LDAP. RADIUS, or RSA domain
controllers.

ISE. which is new in Version 6.0. does not report failed login attempts.
Version 1.3 of ISE is supported with this version of the Firepower System.

Configuring an ISE connection also populates the Firepower Management Center database
with ISE attribute data. ISE attributes can be used for user awareness and in access control
rule conditions.

Security Group Tag (SGT)

The Security Group Tag (SGT) attribute is applied by Cisco TrustSec as packets enter
trusted TrustSec networks. With ISE configured, the system identifies users and their SGT.
which you can use for access control.

Endpoint Location

The Endpoint Location attribute is the IP address of the network device that used ISE to
authenticate the user, as identified by ISE.

Endpoint Profile

The Endpoint Profile attribute is the user's endpoint device type, as identified by ISE.
For more information about the ISE product, see the Cisco Identity Services Engine
Administrator Guide, at http:/Avww.cisoo.co(TVc/en/us/td/docs/security/ise/1-3
/admin_guide.'b_ise_admin_guide_13.html.

144
 Bootcamp SSFIPS
ISE Fields

The following fields are used to configure a connection to ISE:

• Primary and Secondary Host Name/IP Address—The hostname or IP address for

the primary and. optionally, the secondary ISE servers.
• pxGrid Server CA—The certificate authority for the pxGrid framework. If your
deployment includes a primary and a secondary pxGrid node, the certificates for both nodes
must be signed by the same certificate authority.
• MNT Server CA—The certificate authority for the ISE certificate when performing
bulk downloads. If your deployment includes a primary and a secondary MNT node, the
certificates for both nodes must be signed by the same certificate authority.
• NIC Server Certificate—The certificate and key that the Firepower Management
Center should provide to ISE when connecting to ISE or performing bulk downloads.
• ISE Network Filter—An optional filter that you can set to restrict the data that ISE
reports to the Firepower Management Center.
If you provide a network filter. ISE reports data from the networks within that filter. You can
specify a filter in the following ways:
• Leave the field blank to specify any.
• Enter a single IPv4 address block, using CIDR notation.
• Enter a list of IPv4 address blocks, using CIDR notation, separated by commas.

For more information, see the Cisco Identity Services Engine Administrator Guide.

Captive Portal is one of the authoritative identity sources supported by the Firepower
System. It is the only active authentication method supported by the Firepower System,
where users can authenticate onto the network through a managed device.

When you configure and deploy Captive Portal in an identity policy, users from specified
realms authenticate through your virtual routers to access your network. The authentication
data gained from Captive Portal can be used for user awareness and user control.

Captive Portal also records failed authentication attempts. A failed attempt does not add a
new user to the list of users in the database. The user activity type for failed authentication
activity reported by Captive Portal is Failed Auth User.

145
 Bootcamp SSFIPS
You configure Captive Portal in your identity policy and invoke it {active authentication) in
your identity rules. Identity policies are invoked in your access control policies.
Captive portal can only be performed by a device with a routed interface configured. If the
identity polio/ referenced by your access control policy contains one or more captive portal
identity rules and you deploy the policy on a Firepower Management Center that manages:

• One or more devices with routed interfaces configured, the policy deployment succeeds
and the supported devices perform captive portal.
• Exclusively devices without routed interfaces configured, the policy deployment
succeeds and users in traffic matching those rules are identified as Unknown.
• One or more NGIPSv devices, the policy deployment fails.
Note the following access control rule and SSL rule requirements and limitations:
• You must create an access control rule in order to allow traffic destined for the IP
address and port of the device that you plan to use for Captive Portal. Traffic cannot be
authenticated using Captive Portal if the destination is not allowed in your access control
policy.
• You must create an SSL rule in order to decrypt the traffic originating from the users that
you want to authenticate using Captive Portal.

After the system authenticates a Captive Portal user, it handles the user traffic according to
the settings in your access control and SSL policies.

Now that you have seen the various methods of tying in the Firepower Management Center
to identity sources, you will learn how to incorporate them into the Firepower Management
Center. There are two concepts that you must be familiar with as you begin: realms and
identity policies.

Introduction: Realms and Identity Policies

A realm consists of one or more LDAP or Microsoft Active Directory servers that share the
same credentials. You must configure a realm if you want to perform user and user group
queries or user access control, or if you want to configure an authoritative identity source

146
 Bootcamp SSFIPS
(User Agent. ISE. or Captive Portal). After configuring one or more realms, you can
configure an identity policy.

An identity policy associates traffic on your network with an authoritative identity source and
a realm. After configuring one or more identity policies, you can associate one with an
access control policy and deploy the access control policy to a managed device.
Before you can perform user control (create access control rule conditions based on entire
realms, individual users, user groups, or ISE attributes), you must do the following:

• Configure a realm for each Microsoft Active Directory or LDAP server that you want to
monitor (including your ISE or User Agent servers). If you enable a user download for the
realm, the Firepower Management Center regularly and automatically queries the server
to download metadata for newly or already-reported authoritative users and user groups.

• Create an identity policy to associate the realm with an authentication method.

• Configure one or more User Agents or ISE devices, or Captive Portal. If you want to use
an ISE attribute (SGT. Endpoint Profile, or Endpoint Location) condition, you must
configure ISE.

User Agents. ISE. and Captive Portal collect authoritative user data that can be used for
user control in access control rule conditions. The identity sources monitor specified users
as they log in or out of hosts or authenticate using LDAP or AD credentials.

First, you must create a realm.

Realms establish connections between the Firepower Management Center and the servers
targeted for monitoring. They specify the connection settings and authentication filter
settings for the server. Realms can do the following:

• Specify the users and user groups whose activity you want to monitor.

• Allow you to query the server for user metadata on authoritative users, as well as some
nonauthoritative users: POP3 and IMAP users detected by traffic-based detection and
users detected by traffic-based detection, a User Agent, or ISE.

You can add multiple servers as directories within a realm, but they must share the same
basic realm information. The directories within a realm must be exclusively LDAP or
exclusive AD servers. After you enable a realm, your saved changes take effect next
time the Firepower Management Center queries the server.

147
 Bootcamp SSFIPS

To perform user awareness, you must configure a realm for any of the supported server
types. The system uses these connections to query the servers for data associates with
POP3 and IMAP users, and to collect data about LDAP users discovered through traffic-
based detection. The system uses the email addresses in POP3 and IMAP logins to
correlate with LDAP users on an Active Directory. OpenLDAP. or Oracle Directory Server
Enterprise Edition server. For example, if a managed device detects a POP3 login for a user
with the same email address as an LDAP user, the system associates the LDAP user's
metadata with that user.
To perform user access control, you can configure the following:
• A realm for an AD server configured for either a User Agent or ISE device
• A realm for an AD. Oracle Directory, or OpenLDAP server configured for Captive
Portal.

If you configure a realm to download users (for user awareness or user control), the
Firepower Management Center regularly queries the server to obtain metadata for new and
updated users whose activity was detected since the last query.

User activity data is stored in the user activity database and user identity data is stored in the
users database. The maximum number of users that you can store and use in access control
depends on your Firepower Management Center model. When choosing which users and
groups to include, make sure that the total number of users is less than your model limit. If
your access control parameters are too broad, the Firepower Management Center obtains
information on as many users as it can, and reports the number of users that it failed to
retrieve in the Tasks tab of the Message Center.

Second, you create an identity policy. Identity policies contain identity rules. Identity rules
associate sets of traffic with a realm and an authentication method: passive authentication,
active authentication, or no authentication.

You must fully configure the realms and authentication methods that you plan to use before
you can invoke them in your identity rules:

• You configure realms outside your identity policy, at System > Integration > Realms.

148
 Bootcamp SSFIPS
• You configure the passive authentication identity sources, the User Agent and ISE.
at System > Integration > Identity Sources.
• You configure the active authentication identity source. Captive Portal, within the
identity policy.

After you configure one or more identity policies, you must invoke one identity policy in your
access control policy. When traffic on your network matches the conditions in your identity
rule, the system associates the traffic with the specified realm and authenticates the users in
the traffic using the specified identity source.

If you do not configure an identity policy, the system does not perform user authentication.

Lastly, you must tie the identity policy into your ACP.

You can combine realm, user, group, and ISE attribute conditions to create simple or
complex access control rules, matching and inspecting traffic by using multiple conditions.

You can add a maximum of 50 realms, users, and groups to Selected Users in a single user
condition.

Conditions with user groups match traffic to or from any of the group's members, including
members of any subgroups, with the exception of individually excluded users and members
of excluded subgroups.

Including a user group automatically includes all of that group's members, including
members of any secondary groups. However, if you want to use the secondary group in
access control rules, you must explicitly include the secondary group.

149
 Bootcamp SSFIPS
Lesson Summary

In this lesson, you learned the following:

• User Identity can be used to gain awareness into user information that can be tied to
your hosts including authoritative data that can tie the user identity into your access
control policy.
• Authoritative identity sources require a realm and an identity policy.
• The nonauthoritative identity source is traffic based detection, where users are seen in
traffic that is not authenticated.
• The User Agent identity source provides information about user logins and logouts to
active directory servers.
• The ISE identity source, which is new in Version 6.0, utilizes the integration of Cisco ISE
to retrieve ISE information for use in the Firepower Management Center.
• The Captive Portal identity source, new in Version 6.0. is the system's only active identity
source, and it allows for authentication through the managed device.
• To create an authoritative user identity source, first create a realm, then associate it with
an identity policy, and finally, associate that identity policy with an ACP.

The graphic show the solutions to the requirements outlined for SecureBank at the beginning
of this module.

Module Summary for “Firepower Discovery”

In this module, you learned the following:

• Network Discovery inspects traffic to discover hosts and users and to obtain critical
information about those hosts and users.
• Host profiles are the host tables that are automatically created and populated in your
system. They contain information such as IP addresses, active services, open ports, and
vulnerabilities associated with that information.
• User identities in the Firepower System are either authoritative or nonauthoritative. and
can use valuable user data from other sources for user control within ACPs or for
analysis.

150
 Bootcamp SSFIPS

151
 Bootcamp SSFIPS

Module 6: Access Control Policy Prerequisites

Overview

Description

This module introduces objects maintained in the Firepower Management Center that are
used by various other areas of your Firepower System, in particular those objects used in
your access control policy.

Objectives

Upon completing this module, you will be able to identify and create the objects required as
a prerequisite to implementing access control policies. This ability includes being able to
meet these objectives:

 Describe the role of access control policies and objects within the Firepower System

 Describe the object types and their uses within the Firepower System

152
 Bootcamp SSFIPS

153
 Bootcamp SSFIPS
Introducing Objects and Access Control Policies

Description

This lesson describes the roles and relationship of access control policies and objects in the
Firepower System.

Objectives

After completing this lesson, you will be able to do the following:

• Describe the role of access control policies and objects within the Firepower System

• Describe the fundamental features of objects

• Describe how access control policies utilize objects

154
 Bootcamp SSFIPS

This flowchart represents the "administrative flow" in your system. Objects, as seen here,
are used by access control policy. Objects are also used elsewhere in the system, but most
commonly in the ACP.

Your access control policy is the application firewall in your Firepower System. You may
choose to do deep-packet inspection and block applications and ports with this policy, or
simply choose traffic to inspect by the intrusion and/or malware portion of your Firepower
System. Unlike a traditional firewall, the ACP in Firepower is application-aware and has
multiple points of protection for your network.

Access control is a hierarchical policy-based feature that allows you to specify, inspect, and
log (non-fast-pathed) network traffic. It is especially useful in multidomain deployments,
because you can nest access control policies, where each policy inherits the rules and
settings from an ancestor {or base) policy. You can enforce this inheritance, or allow lower-
level policies to override their ancestors. Each managed device can be targeted by one
access control policy.

The data that the policy's target devices collect about your network traffic can be used to
filter and control that traffic based on the following:

• Simple, easily determined transport and network layer characteristics: source and
destination, port, protocol, and so on.
• The latest contextual information on the traffic, including characteristics such as
reputation, risk, business relevance, application used, or URL visited.
• Realm, user, or user group.
• Characteristics of encrypted traffic; you can also decrypt this traffic for further
analysis.
• Whether unencrypted or decrypted traffic contains a prohibited file, detected
malware, or intrusion attempt.

Each type of traffic inspection and control occurs where it makes the most sense for
maximum flexibility and performance. For example, reputation-based blacklisting uses
simple source and destination data, so it can block prohibited traffic early in the process. In
contrast, detecting and blocking intrusions and exploits is a last-line defense.

155
 Bootcamp SSFIPS

Although you can configure the system without licensing your deployment, many features
require that you enable the appropriate licenses before you deploy. Also, some features are
available only on certain device models. Warning icons and confirmation dialog boxes
designate unsupported features.

156
 Bootcamp SSFIPS

Navigate to the "Objects" areas of your Firepower Management Center's GUI. and you will
see all available objects listed. Note that, out of the box, these are essentially containers.
You will want to build these out according to what you plan to do with your various ACPs.
Objects are reusable configurations that associate a name with a value. When you want to
use that value, use the named object instead.

You can create the following types of objects:

• Network-based objects that represent IP addresses and networks, port/protocol

pairs. VLAN tags, security zones, and origin/destination country {geolocation)

• Reputation-based objects that represent security intelligence feeds and lists,

application filters based on category and reputation, and file lists

• Non-reputation-based objects, such as URL categories

• Intrusion policy variable sets containing variables that you associate with an intrusion
policy

• Objects that help you handle encrypted traffic, including cipher suites, public key
certificates and paired private keys, and certificate distinguished names

You can use these objects in various places in the system's web interface, including access
control policies, network analysis policies, intrusion policies and rules, network discovery
rules, event searches, reports, dashboards, and so on.

Object Manager

You can use the object manager to create and manage objects and object groups.

The object manager displays 20 objects or groups per page. If you have more than 20 of any
type of object or group, use the navigation links at the bottom of the page to view additional
pages. You can also go to a specific page or dick the Refresh icon to refresh your view. By
default, the page lists objects and groups alphabetically by name.

However, you can sort each type of object or group by any column in the display. You can
also filter the objects on the page by name or value.

157
 Bootcamp SSFIPS

Grouping objects allows you to reference multiple objects with a single configuration. The
system allows you to use objects and object groups interchangeably in the web interface.
You can group network, port. VLAN tag. URL. and PKI objects. For example, anywhere you
would use a port object, you can also use a port object group.

Objects and object groups of the same type cannot have the same name. In a multidomain
deployment, the names of object groups must be unique within the domain hierarchy. Note
that the system may identify a conflict with the name of an object group that you cannot view
in your current domain.

When you edit an object group used in a policy {for example, a network object group used in
an access control policy), you must redeploy the changed configuration for your changes to
take effect.

Deleting a group does not delete the objects in the group; it deletes only their association
with each other. Additionally, you cannot delete a group that is in use in an active policy. For
example, you cannot delete a VLAN tag group that you are using in a VLAN condition in a
saved access control policy.

158
 Bootcamp SSFIPS

An object override allows you to define an alternate value for an object, which the system
uses for the devices you speedy.

You can create an object whose definition works for most devices, and then use overrides to
speedy modifications to the object for the few devices that require different definitions. You
can also create an object that needs to be overridden for all devices, but its use allows you
to create a single policy for all devices.

Object overrides allow you to create a smaller set of shared polices for use across devices
without giving up the ability to alter polices when needed for individual devices.
For example, you might want to deny ICMP traffic to the different departments in your
company, each of which is connected to a different network. You can do this by defining an
access control policy with a rule that includes a network object called Departmental Network.
By allowing overrides for this object, you can then create overrides on each relevant device
that speediest the actual network where that device is connected.

In a multidomain deployment, you can define a default value for an object in an ancestor
domain and allow administrators in descendant domains to add override values for that
object. For example, a managed security service provider (MSSP) might use a single
Firepower Management Center to manage network security for multiple customers.
Administrators at the MSSP can define an object in the Global domain for use in all
customers' deployments. Administrators for each customer can log in to descendant
domains to override that object for their organizations. These local administrators cannot
view or affect the override values of other customers of the MSSP.

You can target an object override to a specific domain. In this case, the system uses the
object override value for all devices in the targeted domain unless you override it at the
device level.

From the object manager, you can choose an object that can be overridden and define a list
of device-level or domain-level overrides for that object.

You can use object overrides with the following object types only:

• Network
• Port
• VLAN tag
• URL
• SLA Monitor
• Prefix List
• Route Map
• Access List
• AS Path
• Community List
• Policy List

If you can override an object, the Override column appears for the object type in the object
manager. Possible values for this column include the following:

• Green checkmark—Indicates that you can create overrides for the object and no
overrides have been added yet.

159
 Bootcamp SSFIPS

• Red X—Indicates that you cannot create overrides for the object.

• Number—Represents a count of the overrides.

Objects are linked to your AC Policies, and therefore, the following applies:

• You can create objects as required directly within your ACP.

• Editing an object used in an AC policy will require a re-apply of that AC policy.
• You cannot delete an object that is used in an access control policy.

In a multidomain deployment, object names must be unique within the domain hierarchy.
The system may identify a conflict with the name of an object you cannot view in your
current domain.

In a multidomain deployment, the system displays objects created in the current domain,
which you can edit. It also displays objects created in ancestor domains, which you cannot
edit in most cases. The only ancestor objects that you can edit are security zones. If object
overrides are allowed, you can add override values to objects created in ancestor domains.

160
 Bootcamp SSFIPS
Objects in the Firepower System are where you manage many aspects of your AC policy. As
a general rule, if you plan to create multiple AC policy 'rules* {and you likely will), you will
want to first create objects in order to identify certain matching criteria in your traffic.

Objects are where you first go when deploying your Firepower System to define certain
things, such as a subnet to a name, like "Finance Department.'

161
 Bootcamp SSFIPS
Lesson Summary

In this lesson, you learned the following:

• Access control policies in the Firepower System are used to manage traffic and
connection logging, and certain objects are used as containers within these access
control policies.

• Objects are containers used throughout the system that can be both grouped and
overridden for container variability.

• Access control policies use objects either directly managed in the objects section of the
GUI or directly in the ACP, depending on the object type and management procedure
utilized.

162
 Bootcamp SSFIPS
Examining Objects

Description

This lesson describes the object types, including general objects and advanced objects, and
introduces Firepower's application awareness and variables features.

Objectives

After completing this lesson, you will be able to do the following:

• Describe the general object types
• Describe application awareness features
• Describe the advanced object types
• Describe the role of variables and variable sets

163
 Bootcamp SSFIPS

A network object represents one or more IP addresses that you can specify either
individually or as address blocks. You can use network objects and groups in various places
in the system's web interface, including access control policies, network variables, intrusion
rules, identity rules, network discovery rules, event searches, reports, and so on. It is likely
that you will create network objects in your environment regardless of how you are deployed.

The procedure steps are as follows:

Step 1
Choose Objects > Object Management.

Step 2
Choose Network from the list of object types.

Step 3
Choose Add Object from the Add Network drop-down menu.

Step 4
Enter a name.

164
 Bootcamp SSFIPS
In a multidomain deployment, object names must be unique within the domain hierarchy.
The system may identify a conflict with the name of an object that you cannot view in your
current domain.

Step 5
Optionally, enter a description.

Step 6
In the Network field, enter an IP address or address block to add to the object.

Step 7
Manage overrides for the object:

• If you want to allow overrides for this object, check the Allow Overrides check box.
If you want to add override values to this object, expand the Override section and dick Add.

Step 8 ´Click Save

You will most likely first create network objects to represent individual hosts as well subnets
{perhaps creating a network object for the subnets assigned to your HR dept. as an
example). From here, you can also group these objects for even more thorough
management. There is no right or wrong way to do this, nor is it required, but for
manageability it is highly recommended.

165
 Bootcamp SSFIPS
ICMP and ICMPv6 (IPv6-ICMP)

A port object represents the Internet layer protocol, plus an optional type and code. For
example: ICMP(1):3:3.

You can restrict an ICMP or IPV6-ICMP port object by type and. if applicable, by code. For
more information on ICMP types and codes, see the following:

http:/?\s\sw.iana.org.'’assignments''icmp-parameters'icmp-parameters.xml

http:/?\s\sw.iana.org.'’assignments''icmpv6-parameters'icmpv6-parameters.xml

Other Protocols

A port object can represent other protocols that do not use ports.

The Firepower System provides default port objects for well-known ports. You cannot modify
or delete these default objects. You can create custom port objects in addition to the default
objects.

You can use port objects and groups in various places in the system's web interface,
inducing access control polices, identity rules, network discovery rules, port variables, and
event searches. For example, if your organization uses a custom client that uses a specific
range of ports and causes the system to generate excessive and misleading events, you can
configure your network discovery policy to exclude monitoring those ports.

When using port objects, observe the following guidelines:

• You cannot add any protocol other than TCP or UDP for source port conditions in access
control rules. Also, you cannot mix transport protocols when setting both source and
destination port conditions in a rule.
• If you add an unsupported protocol to a port object group used in a source port condition,
the rule where it is used does not take effed on the managed device when the
configuration is deployed.
• If you create a port object containing both TCP and UDP ports, add it as a source port
condition in a rule. You cannot add a destination port, and vice versa.

Creating Port Objects

To create port objects, following these steps:

Step 1
Choose Objects > Object Management.

Step 2
Choose Port from the list of object types.

Step 3
Choose Add Object from the Add Port drop-down list.

Step 4
Enter a name.

166
 Bootcamp SSFIPS

Step 5
Choose a protocol.
Available protocols include TCP. UDP. IP. ICMP. IPv6-ICMP. and any protocol from the
Other drop-down list (which includes All).

Step 6
If you want to restrict a TCP or UDP object by port or port range, or if you chose All from the
Other drop-down list, enter a value in the Port field. You can specify any port or port range
from 1 to ©5535. or any to match all ports. Use a hyphen to specify a range of ports.

Step 7
Restrict an ICMP or IPV6-ICMP port object by type and. if applicable, by code.
You can set the type to Any to match any type, or set the code to Any to match any code for
the specified type.

Step 8
Manage overrides for the object.

Step 9
Click Save.

A security zone is a grouping of one or more inline, passive, switched, routed, or ASA
FirePOWER interfaces.

Zones divide the network into segments to help you manage and classify traffic flow in
various policies and configurations.

The interfaces in a single zone may span multiple devices; you can also configure multiple
zones on a single device. An interface can belong to only one zone. All interfaces in a
security zone must be of the same type—that is. all inline, passive, switched, routed, or ASA
FirePOWER. After you create a security zone, you cannot change the type of interfaces it
contains.

You can use zones in various places in the system's web interface, including access control
policies, network discovery rules, and event searches. For example, you could constrain an

167
 Bootcamp SSFIPS
access control rule by zone, so that it matches only traffic flowing through a particular set of
interfaces.

Security zones are created in the following ways:

• The system creates security zones upon device registration, depending on the detection
mode you selected for the device during its initial configuration. For example, the system
creates a Passive zone in passive deployments, while in inline deployments the system
creates External and Internal zones.
• You can create security zones on the fly while configuring interfaces on a managed
device.
• You can create security zones by using the object manager (Objects > Object
Management).

The Security Zones page of the object manager lists the zones configured on your managed
devices. The page also displays the type of interfaces in each zone, and you can expand
each zone to view which interfaces on which devices belong to each zone.

In a multidomain deployment, you can create security zones at any level. A zone created in
an ancestor domain can contain interfaces that reside on devices in different domains. In this
situation, subdomain users viewing the ancestor zone configuration in the object manager
can see only the interfaces in their domain. Unless restricted by role, subdomain users can
view and edit zones created in ancestor domains. Subdomain users can add and delete
interfaces from these zones. They cannot, however, delete or rename the zones. You can
neither view nor edit zones created in descendant domains.

If you modify your ASA FirePOWER security contexts, switching from single context mode to
multicontext mode or vice versa, the system removes all interfaces from your security zone
configurations.

When you update a security zone object, redeploy configuration changes to managed
devices.

Step 1
Choose Objects > Object Management.

Step 2
Choose Security Zones from the list of object types.

Step 3
Click Add Security Zone.

Step 4
Enter a name.

Step 5
Choose an interface type for the zone.

168
 Bootcamp SSFIPS
Step 6
From the Device > Interfaces drop-down list, choose a device that contains interfaces that
you want to add to the zone.

Step 7
Choose one or more interfaces.

Step 8
Click Add to add your chosen interfaces to the zone, grouped by device.

Step 9
Click Save.

The Firepower System can manage traffic differently based on VLAN tags. Each VLAN tag
object that you configure represents a VLAN tag or range of tags.

You can group VLAN tag objects. Note that groups represent multiple objects; using a range
of VLAN tags in a single object is not considered a group in this sense.

You can use VLAN tag objects and groups in various places in the system's web interface,
including access control policies, identity rules, and event searches. For example, you could
write an access control rule that applies only to a specific VLAN.

Creating VLAN Tag Objects

To create VLAN tag objects, follow these steps:

Step 1
Choose Objects > Object Management.

Step 2
Chose VLAN Tag from the list of object types.

Step 3
Choose Add Object from the Add VLAN Tag drop-down list.

Step 4

169
 Bootcamp SSFIPS
Enter a name.

Step 5
Choose a protocol.
Available protocols include TCP. UDP. IP. ICMP. IPv6-ICMP. and any protocol from the
Other drop-down list (which include All).

Step 6
If you want to restrict a TCP or UDP object by port or port range, or if you chose All from the
Other drop-down list, enter a value in the Port field. You can specify any port or port range
from 1 to ©5535. or any to match all ports. Use a hyphen to specify a range of ports.

Step 7
Restrict an ICMP or IPV6-ICMP port object by type and. if applicable, by code.
You can set the type to Any to match any type, or set the code to Any to match any code for
the specify type.

Step 8
Manage overrides for the object.

Step 9
Click Save.

A security zone is a grouping of one or more inline, passive, switched, routed, or ASA
FirePOWER interfaces.

Zones divide the network into segments to help you manage and classify traffic flow in
various policies and configurations.

The interfaces in a single zone may span multiple devices; you can also configure multiple
zones on a single device. An interface can belong to only one zone. All interfaces in a
security zone must be of the same type—that is. all inline, passive, switched, routed, or ASA

170
 Bootcamp SSFIPS
FirePOWER. After you create a security zone, you cannot change the type of interfaces it
contains.

You can use zones in various places in the system's web interface, including access control
policies, network discovery rules, and event searches. For example, you could constrain an
access control rule by zone, so that it matches only traffic flowing through a particular set of
interfaces.

Security zones are created in the following ways:

• The system creates security zones upon device registration, depending on the detection
mode you selected for the device during its initial configuration. For example, the system
creates a Passive zone in passive deployments, while in inline deployments the system
creates External and Internal zones.
• You can create security zones on the fly while configuring interfaces on a managed
device.

• You can create security zones by using the object manager (Objects > Object
Management).

The Security Zones page of the object manager lists the zones configured on your managed
devices. The page also displays the type of interfaces in each zone, and you can expand
each zone to view which interfaces on which devices belong to each zone.
In a multidomain deployment, you can create security zones at any level. A zone created in
an ancestor domain can contain interfaces that reside on devices in different domains. In this
situation, subdomain users viewing the ancestor zone configuration in the object manager
can see only the interfaces in their domain. Unless restricted by role, subdomain users can
view and edit zones created in ancestor domains. Subdomain users can add and delete
interfaces from these zones. They cannot, however, delete or rename the zones. You can
neither view nor edit zones created in descendant domains.

If you modify your ASA FirePOWER security contexts, switching from single context mode to
multicontext mode or vice versa, the system removes all interfaces from your security zone
configurations.

When you update a security zone object, redeploy configuration changes to managed
devices.

Creating Security Zone Objects

If you have not yet configured interfaces on your managed devices, you can create an empty
zone and add interfaces to it later. Follow these steps:

Step 1
Choose Objects > Object Management.

Step 2
Choose Security Zones from the list of object types.

Step 3
Click Add Security Zone.

Step 4
Enter a name.

171
 Bootcamp SSFIPS

Step 5
Choose an interface type for the zone.

Step 6
From the Device > Interfaces drop-down list, choose a device that contains interfaces that
you want to add to the zone.

Step 7
Choose one or more interfaces.

Step 8
Click Add to add your chosen interfaces to the zone, grouped by device.

Step 9
Click Save.

The Firepower System can manage traffic differently based on VLAN tags. Each VLAN tag
object that you configure represents a VLAN tag or range of tags.

You can group VLAN tag objects. Note that groups represent multiple objects; using a range
of VLAN tags in a single object is not considered a group in this sense.

You can use VLAN tag objects and groups in various places in the system's web interface,
including access control policies, identity rules, and event searches. For example, you could
write an access control rule that applies only to a specific VLAN.

Creating VLAN Tag Objects

To create VLAN tag objects, follow these steps:

Step 1
Choose Objects > Object Management.

Step 2
Chose VLAN Tag from the list of object types.

172
 Bootcamp SSFIPS

Step 3
Choose Add Object from the Add VLAN Tag drop-down list.

Step 4
Enter a name.

Step 5
Enter a description.

Step 6
Enter a value in the VLAN Tag field. Use a hyphen to specify a range of VLAN tags.

Step 7
Manage overrides for the object.

Step 8
Click Save.

Each URL object that you configure represents a single URL or IP address. You can use
URL objects and groups in various places in the system's web interface, including access
control polices and event searches. For example, you could write an access control rule that
blocks a specify website.

When creating URL objects, specifically if you do not configure SSL inspection to decrypt or
block encrypted traffic, keep the following points in mind:

• If you plan to use a URL object to match HTTPS traffic in an access control rule,
create the object by using the subject common name in the public key certificate that is used
to encrypt the traffic. Also, the system disregards subdomains within the subject common
name, so do not include subdomain information. For example, use example.com rather than
www.example.com.

173
 Bootcamp SSFIPS
• When matching web traffic by using access control rules with URL conditions, the
system disregards the encryption protocol {HTTP vs HTTPS). In other words, if you block a
website, both HTTP and HTTPS traffic to that website is blocked, unless you use an
application condition to refine the rule. When creating a URL object you do not need to
specify the protocol. For example, use example.com rather than http://example.com/.

• Note that there is always an implicit wild card. For example, if you allow all traffic to
example.com, your users could browse to URLs including:

- http://example.com''
- http: //exam pIe.com/newexampIe
- http:ZAvww.example.com/

This means that when specifying individual URLs in URL conditions, you must carefully
consider other traffic that might be affected. For example, consider a scenario where you
want to explicitly block the URL isc.com. However, substring matching means that blocking
isc.com also blocks isc.com, which might not be your intent.

Creating URL Objects

To create URL objects, follow these steps:

Step 1
Choose Objects > Object Management.

Step 2
Choose URL from the list of object types.

Step 3
Choose Add Object from the Add URL drop-down list.

Step 4
Enter a name.

In a multidomain deployment, object names must be unique within the domain hierarchy.
The system may identify a conflict with the name of an object that you cannot view in your
current domain.

Step 5
Optionally, enter a description.

Step 6
Enter the URL or IP address. You cannot use wildcards f) in this field.

Step 7
Manage overrides for the object.

Step 8
Click Save.

174
 Bootcamp SSFIPS

Each geolocation object that you configure represents one or more countries or continents
that the system has identified as the source or destination of traffic on your monitored
network. You can use geolocation objects in various places in the system's web interface,
including access control policies. SSL policies. and event searches.

For example, you could write an access control rule that blocks traffic to or from certain
countries.

To ensure that you are using up-to-date information to filter your network traffic. Cisco
strongly recommends that you regularly update your Geolocation Database (GeoDB).
Creating Geolocation Objects

To create geolocation objects, follow these steps:

Step 1
Choose Objects > Object Management.

Step 2
Choose Geolocation from the list of object types.

Step 3
Click Add Geolocation.

Step 4
Enter a name.

Step 5
Check the check boxes for the countries and continents that you want to include in your
geolocation object. Checking a continent chooses all countries within that continent, as well
as any countries that GeoDB updates may add under that continent in the future.
Unchecking any country under a continent unchecks the continent. You can choose any
combination of countries and continents.

Step 6
Click Save.

175
 Bootcamp SSFIPS

You can pre-associate a file with a disposition. You label it as good or bad, and in doing so.
any detection of that file skips the default Malware Inspection that should you have a
Malware policy applied to the traffic that saw this file. If you use AMP for Firepower, and the
AMP cloud incorrectly identifies a file's disposition, you can add the file to a file list to better
detect the file in the future. These files are specified using SHA-256 hash values.

Each file list can contain up to 10.000 unique SHA-256 values.

There are two predefined categories of file lists: dean list and custom detection list.

Clean List
If you add a file to the dean list, the system treats it as if the AMP cloud has assigned a dean
disposition.

Custom Detection List

If you add a file to the custom detection list, the system treats it as if the AMP cloud has
assigned a malware disposition.

In a multidomain deployment, a dean list and a custom detection list are present for each
domain. In lower-level domains, you can view but not modify ancestors' lists.

Because you manually specify the blocking behavior for the files included in these lists, the
system does not query the AMP cloud for these files' dispositions. You must configure a rule
in the file policy with either a Malware Cloud Lookup or Block Mal ware action and a
matching file type to calculate a file's SHA value.

176
 Bootcamp SSFIPS
You can add multiple SHA-256 values to a file list by uploading a comma-separated value
(CSV) source file containing a list of SHA-256 values and descriptions. The Firepower
Management Center validates the contents and populates the file list with valid SHA-256
values.

The source file must be a simple text file with a .csv file name extension. Any header must
start with a pound sign {#); it is treated as a comment and is not uploaded. Each entry
should contain a single SHA-256 value, followed by a description, and should end with either
the LF or CR+LF Newline character. The system ignores any additional information in the
entry.

Note the following:

• Deleting a source file from the file list also removes all associated SHA-256 hashes from
the file list.
• You cannot upload multiple files to a file list if the successful source file upload results in
the file list containing more than 10.000 distinct SHA-256 values.
• The system truncates descriptions exceeding 256 characters to the first 256 characters
on upload. If the description contains commas, you must use an escape character (\,). If
no description is include the source filename is used instead.
• All non duplicate SHA-256 values are added to the file list. If a file list contains a SHA-
256 value, and you upload a source file containing that value, the newly uploaded value
does not modify the existing SHA-256 value. When viewing captured files, file events, or
malware events related to the SHA-256 value, any threat name or description is derived
from the individual SHA-256 value.

Uploading Individual Files to File Lists

If you have a copy of the file that you want to add to a file list, you can upload the file to the
Firepower Management Center for analysis. The system calculates the file's SHA-256 value
and adds the file to the list. The system does not enforce a limit on the size of files for SHA-
256 calculation.

In a multidomain deployment, the system displays objects created in the current domain,
which you can edit.

177
 Bootcamp SSFIPS
It also displays objects created in ancestor domains, which in most cases you cannot edit.
To view and edit objects in a descendant domain, switch to that domain.
To upload individual files to file lists, follow these steps:

Uploading Source Files to File Lists

In a multidomain deployment, the system displays objects created in the current domain,
which you can edit.

It also displays objects created in ancestor domains, which in most cases you cannot edit.
To view and edit objects in a descendant domain, switch to that domain. To upload source
files to file lists, follow these steps:

178
 Bootcamp SSFIPS

When the Firepower System analyzes IP traffic, it attempts to identify the commonly used
applications on your network. Application awareness is crucial to performing application-
based access control. The system is delivered with detectors for many applications, and
Cisco frequently updates and adds additional detectors via system and vulnerability
database (VDB) updates. You can also create your own application protocol detectors to
enhance the system's detection capabilities.

Application filters group applications according to criteria associated with the applications'
risk, business relevance, type, categories, and tags. When you create an application
protocol detector, you must characterize the application using those criteria as well. Using
application filters allows you to quickly create application conditions for access control rules,
because you do not have to search for and add applications individually.

Another advantage to using application filters is that you do not have to update access
control rules that use filters when you modify or add new applications. For example, if you
configure your access control policy to block all social networking applications, and a VDB
update includes a new social networking application detector, the policy is updated when
you update the VDB. Although you must redeploy the policy before the system can block the
new application, you do not have to update the access control rule that blocks the
application.

If the system-provided application filters do not group applications according to your needs,
you can create your own filters. User-defined filters can group and combine system-provided
filters. For example, you could create a filter that would allow you to block all very high risk,
low business relevance applications. You can also create a filter by manually specifying
individual applications, although you should keep in mind that those filters are not
automatically updated when you update the system software or the VDB.

179
 Bootcamp SSFIPS
As with system-provided application filters, you can use user-defined application filters in
access control rules.

The Application Filters list contains the system-provided application filters that you can select
to build your own filter. You can constrain the filters that appear by using a search string; this
is especially useful for categories and tags.

The Available Applications list contains the individual applications in the filters that you
select. You can also constrain the applications that appear by using a search string.
The system links multiple filters of the same filter type with an OR operation. Consider a
scenario where the medium-risk filter contains 100 applications and the high-risk filter
contains 50 applications. If you select both filters, the system would display 150 available
applications.

The system links different types of filters with an AND operation.

After you determine the applications that you want to add to the filter, you can add them
either individually or. if you selected an application filter, all apps matching the filter. You can
add multiple filters and multiple applications, in any combination, as long as the total number
of items in the Selected Applications and Filters list does not exceed 50.

After you create the application filter, it is listed on the Application Filters page of the object
manager. The page displays the total number of conditions that comprise each filter.

To add an application filter, follow these steps:

180
 Bootcamp SSFIPS

181
 Bootcamp SSFIPS

A sinkhole object represents either a DNS server that gives non routable addresses for all
domain names within the sinkhole, or an IP address that does not resolve to a server. You
can reference the sinkhole object within a DNS policy rule to redirect matching traffic to the
sinkhole. You must assign the object both an IPv4 address and an IPv6 address.

Creating Sinkhole Objects

To create a sinkhole object, follow these steps:

Step 1
Choose Objects > Object Management.

Step 2
Choose Sinkhole from the list of object types.

Step 3
Click Add Sinkhole.

Step 4
Enter a name.

Step 5
Enter the IPv4 address and IPv6 address of your sinkhole.

Step 6
You have the following options:
• If you want to redirect traffic to a sinkhole server, choose Log Connections to
Sinkhole.
• If you want to redirect traffic to a nonresolving IP address, choose Block and Log
Connections to Sinkhole.

Step 7
If you want to assign an indication of compromise (loC) type to your sinkhole, choose one
from the Type drop-down menu.

182
 Bootcamp SSFIPS

Step 8
Click Save.

183
 Bootcamp SSFIPS
Variables represent values commonly used in intrusion rules to identify source and
destination IP addresses and ports. You can also use variables in intrusion polices to
represent IP addresses in rule suppressions, adaptive profiles, and dynamic rule states.

Preprocessor rules can trigger events regardless of the hosts defined by network variables
used in intrusion rules.

You use variable sets to manage, customize, and group your variables. You can use the
default variable set provided by the system or create your own custom sets. Within any set,
you can modify predefined default variables and add and modify user-defined variables.

Most of the shared object rules and standard text rules that the Firepower System provides
use predefined default variables to define networks and port numbers. For example, most of
the rules use the variable SHOME_NET to specify the protected network and the variable
SEXTERNAL_NET to specify the unprotected (or outside) network. In addition, specialized
rules often use other predefined variables. For example, rules that detect exploits against
web servers use the SHTTP_SERVERS and SHTTP_PORTS variables.

Rules are more effective when variables more accurately reflect your network environment.
At a minimum, you should modify default variables in the default set. By ensuring that a
variable such as SHOME_NET correctly defines your network and SHTTP_SERVERS
includes all web servers on your network, processing is optimized and all relevant systems
are monitored for suspicious activity.

To use your variables, you link variable sets to intrusion polices associated with access
control rules or with the default action of an access control policy. By default, the default
variable set is linked to all intrusion polices used by access control polices.
Adding a variable to any set adds it to all sets; that is, each variable set is a collection of all
variables currently configured on your system. Within any variable set, you can add user-
defined variables and customize the value of any variable.

Initially, the Firepower System provides a single, default variable set comprised of
predefined default values. Each variable in the default set is initially set to its default value,
which for a predefined variable is the value set by the Cisco Talos Security Intelligence and
Research Group and is provided in rule updates.

Although you can leave predefined default variables configured to their default values. Cisco
recommends that you modify a subset of predefined variables.

You could work with variables only in the default set, but in many cases you can benefit most
by adding one or more custom sets, configuring different variable values in different sets,
and perhaps even adding new variables.

When using multiple sets, it is important to remember that the current value of any variable
in the default set determines the default value of the variable in all other sets. When you
select Variable Sets on the Object Manager page, the object manager lists the default
variable set and any custom sets you created.

On a freshly installed system, the default variable set is comprised only of the default
variables predefined by Cisco.

Each variable set includes the default variables provided by the system and all custom
variables you have added from any variable set. Note that you can edit the default set, but
you cannot rename or delete the default set.

184
 Bootcamp SSFIPS
In a multidomain deployment, the system generates a default variable set for each
subdomain.

185
 Bootcamp SSFIPS
Lesson Summary

In this lesson, you learned the following:

• The general object types consist of the most commonly used objects in the Firepower
System that are typically used in access control polices.
• Application awareness in the Firepower System is the built-in awareness of applications
running through the network that is updated regularly by Cisco and that you can
customize.
• The advanced object types include objects used in SSL polices, sinkhole objects, and
Threat Defense objects.
• Variables and variable sets in the Firepower System are used to customize the Snort
rule sets found in your intrusion polices.

186
 Bootcamp SSFIPS

Module Summary for “Access Control Policy Prerequisites”

In this module, you learned the following:

• Access control policy objects are containers that you can build and manage. You can
use them in your ACP for easy management and flexibility.
• Objects are used throughout the Firepower System and can be categorized into general
object types, advanced object types, and variable sets used for your intrusion polices.

187
 Bootcamp SSFIPS

188
 Bootcamp SSFIPS
Module 7: Implementing Access Control Policies

Overview

Description

This module describes access control policies and their relationship to other parts of your
Firepower System.

Objectives

Upon completing this module, you will be able to describe the behavior, usage, and
implementation procedure for access control policies. This ability includes being able to meet
these objectives:

• Identify the components and features of access control polices

• Describe ACP rules and their relation to the default action
• Describe the further inspection capabilities of the Firepower System
• Implement connection event logging in the Firepower System
• Describe the advanced features section of an access control policy
• Describe ACP considerations such as network discovery and ACP inheritance

189
 Bootcamp SSFIPS

Examining Access Control Policies

Description

This lesson examines the fundamentals of access control polices and their role in the
Firepower System.

Objectives

After completing this lesson, you will be able to do the following:

• Examine the role of access control polices in the Firepower System
• Describe access control policy components

You saw the fundamentals of access control policies in the previous module, and how
objects relate to these policies. Recall that certain objects are created and managed to be
used in the access control policy.

Access control is a hierarchical policy-based feature that allows you to specify, inspect, and
log (non-fast-pathed) network traffic. Especially useful in multidomain deployments, you can
nest access control policies, where each policy inherits the rules and settings from an
ancestor (or base) policy. You can enforce this inheritance, or allow lower-level policies to

190
 Bootcamp SSFIPS
override their ancestors. Each managed device can be targeted by one access control
policy.

The data that the policy's target devices collect about your network traffic can be used to
filter and control that traffic, based on the following:

• Simple, easily determined transport and network layer characteristics: source and
destination, port, protocol, and so on
• The latest contextual information on the traffic, including characteristics such as
reputation, risk, business relevance, application used, or URL visited
• Realm, user, or user group
• Characteristics of encrypted traffic; you can also decrypt this traffic for further
analysis
• Whether unencrypted or decrypted traffic contains a prohibited file, detected
malware, or intrusion attempt

Each type of traffic inspection and control occurs where it makes the most sense for
maximum flexibility and performance. For example, reputation-based blacklisting uses
simple source and destination data, so it can block prohibited traffic early in the process. In
contrast, detecting and blocking intrusions and exploits is a last-line defense.

Although you can configure the system without licensing your deployment, many features
require that you enable the appropriate licenses before deployment. Also, some features are
available only on certain device models. Warning icons and confirmation dialog boxes
designate unsupported features.

191
 Bootcamp SSFIPS

Remember that all traffic to be inspected must pass through this access control policy. If you
choose to inspect traffic for malware, for instance, you define that here in the access control
policy. If you choose to inspect traffic for malicious network traffic, you also define that here.
As such, the access control policy acts like a firewall. Unlike a firewall, however, it is
application-aware, so you have flexibility as an administrator to make block, do not inspect,
or inspect decisions more granularly.

As shown in the example in the graphic, you have two rules. These rules are processed top-
down. If neither rule matches, then the traffic matches on what is called the Default Action.

192
 Bootcamp SSFIPS
The access control policy can be divided into the following components:
• Rules—Rules are how you match on traffic conditions. These are matched in a top-
down fashion.
• Default Action—if no rules match the traffic, the traffic matches here.
• Logging—the connection event legging for that traffic match.
• Further Inspection—What Malware & File Policy and/or Intrusion Policy the traffic
goes to next.
Security Intelligence—Prevents traffic from entering the access control policy {covered in
later module).

193
 Bootcamp SSFIPS
Lesson Summary

In this lesson, you learned the following:

• Access control policies are the application-aware firewall in the Firepower System
and are required in all deployments.

• Access control policies include the traffic identification components, such as Rules
and Default Action and allow connection event logging configuration.

194
 Bootcamp SSFIPS
Examining ACP Rules and Default Action

Description

This lesson examines how the access control policy's Rules and Default Action are utilized.

Objectives

After completing this lesson, you will be able to do the following:

• Describe ACP Rules and their role
• Describe ACP Default Action and its role
• Describe the ACP matching action possibilities
• Describe the Block ACP matching option
• Describe the Monitor ACP matching option
• Describe the Trust ACP matching option
• Describe the Allow ACP matching option
• Describe ACP examples

195
 Bootcamp SSFIPS

Access control policies have rules that are processed top-down, like a firewall. You can have
no rules or you can have many rules enabled.

The maximum number of rules is governed by many factors, including the Firepower model,
complexity of the rules, other device settings, and so on. More information is available in the
Firepower Management Center Configuration Guide:

http://www.cisco.com/c/en/us/td/docs/security/firepower/60/configuration/guide/fprno43onfig-
guide-v60.htrnl

Access Control Rule Condition Types

When you build access control rules, each condition type has its own tab in the access
control rule editor.

• Zones—Matches traffic entering or leaving a device via an interface in a specific

security zone. A security zone is a logical grouping of one or more interfaces according to
your deployment and security policies.
Interfaces in a zone can be located across multiple devices.

• Networks—Matches traffic by its source or destination IP address, country, or

continent (geolocation).

• Ports—Matches traffic by its source or destination port. For TCP and UDP, you can
control traffic based on the transport layer protocol. For ICMP and ICMPv6 (IPv6-ICMP), you
can control traffic based on its Internet layer protocol plus an optional type and code. Using
port conditions, you can also control traffic using other protocols that do not use ports.

• VLAN Tags—Matches VLAN-tagged traffic. For access control, the system uses the
innermost VLAN tag.

• Applications—Matches traffic by the application detected in a session. You can

control access to individual applications, or filter access according to basic characteristics:
type, risk, business relevance, categories, and tags.

• URLs—Matches traffic by the URL requested in the session. You can control access
to individual websites, use lists and feeds, or filter access based on a site's general
classification and risk level.

196
 Bootcamp SSFIPS

• Users and Realms—Matches traffic by the user or realm involved in the session.

• ISE Attributes—Matches traffic by ISE attribute.

An access control rule's conditions identify the type of traffic that the rule handles. If you do
not configure a particular condition for a rule, the system does not match traffic based on
that criterion. For example, a rule with a network condition but no application condition
evaluates traffic based on its source or destination, regardless of the application used in the
session.

When adding conditions to access control rules, consider the following:

• You can configure multiple conditions per rule. Traffic must match all the conditions in
the rule for the rule to apply to traffic. For example, you can use a single rule to perform
URL filtering (URL condition) for specific hosts (zone or network condition).
• For each condition in a rule, you can add up to 50 criteria. Traffic that matches any of a
condition's criteria satisfies the condition. For example, you can use a single rule to
perform user control for up to 50 users and groups.
• Although you can configure the system without licensing your deployment, many
features require that you enable the appropriate licenses before the deployment. Also,
some features are available only on certain device models. Warning icons and
confirmation dialog boxes designate unsupported features.

197
 Bootcamp SSFIPS
The default action determines how the system handles and logs traffic that is not handled by
any other access control configuration. The default action can block or trust all traffic without
further inspection, or inspect traffic for intrusions and discovery data.
Although an access control policy can inherit its default action from an ancestor policy, you
cannot enforce this inheritance.

In a simple access control policy, the default action specifies how target devices handle all
traffic. In a more complex policy, the default action handles traffic that:

• Is not trusted by Intelligent Application Bypass

• Is not blacklisted by Security Intelligence
• Is not blocked by SSL inspection {encrypted traffic only)
• Matches none of the rules in the policy {except Monitor rules, which match and log—
but do not handle or inspect— traffic)
The access control policy default action can block or trust traffic without further inspection, or
inspect traffic for intrusions and discovery data.

You cannot perform file or malware inspection on traffic handled by the default action.
Logging for connections handled by the default action is initially disabled, though you can
enable it.

If you are using policy inheritance, the default action for the lowest-level descendant
determines final traffic handling. Although an access control policy can inherit its default
action from its base policy, you cannot enforce this inheritance.

Each rule created, along with the Default Action, must have an action associated with it.
The Block, and Block with Reset, actions deny traffic without further inspection of any kind.
Block with Reset rules also reset the connection. For unencrypted HTTP traffic, when the
system blocks a web request, you can override the default browser or server page with a
custom page that explains that the connection was denied. The system calls this custom
page an HTTP response page.

198
 Bootcamp SSFIPS
The Monitor action does not affect traffic flow: matching traffic is neither immediately
permitted nor denied. Rather, traffic is matched against additional rules to determine whether
to permit or deny it.

The Trust action allows traffic to pass without further inspection of any kind. You can log
trusted network traffic at both the beginning and end of connections. Note that the system
logs TCP connections handled by a Trust rule differently, depending on the model of the
device that detected the connection.

For most devices, the system processes certain Trust rules before an access control
policy's Security Intelligence blacklist, which can allow blacklisted traffic to pass uninspected.
This action is known as a "promoted rule" and will be discussed later in this module.

The Allow action allows matching traffic to pass. But, depending on your license, you can
perform deep inspection to further inspect and block unencrypted or decrypted network
traffic before it reaches its destination.

In the example in the graphic, two rules are added. Access control rules provide a granular
method of handling network traffic. Rules in an access control policy are numbered, starting
at 1, including rules inherited from ancestor polices. The system matches traffic to access
control rules in top-down order by ascending rule number.

Usually, the system handles network traffic according to the first access control rule, where
all the rule's conditions match the traffic. Conditions can be simple or complex, and their use
often depends on certain licenses.

199
 Bootcamp SSFIPS
When using the Block action, you will not be able to inspect this traffic by Intrusion Policy or
Malware & File Policy. Keep in mind the flow of traffic in your system. Regardless of how you
are physically deployed (passive or inline), a block in your access control policy will stop the
system from processing that traffic any further. This can be good for performance but bad for
getting visibility into the traffic by Intrusion Policy and Malware & File Policy.

When you block, you are doing no further inspection and preventing the traffic from leaving
the managed device (if you are inline and not in TAP mode). You can still configure the
access control policy this way in a passive deployment, but the system will be unable to
block. You will not process the traffic any further and will cease further inspection on the
traffic blocked.

The Block, and Block with Reset, actions deny traffic without further inspection of any kind.
Block with Reset rules also reset the connection.

For unencrypted HTTP traffic, when the system blocks a web request, you can override the
default browser or server page with a custom page that explains that the connection was
denied. The system calls this custom page an HTTP response page.

For decrypted and encrypted (HTTPS) traffic. Interactive Block rules block matching
connections without interaction and the system does not display a response page.

You can log blocked network traffic only at the beginning of connections. Note that only
devices deployed inline can block traffic. Because blocked connections are not actually
blocked in passive deployments, the system can report multiple beginning-of-connection
events for each blocked connection.

Logging blocked TCP connections during a denial of service (DoS) attack can affect
system performance and overwhelm the database with multiple similar events. Before you
enable logging for a Block rule, consider whether the rule monitors traffic on an Internet-
facing interface or other interface vulnerable to a DoS attack.

The Block, and Block with Reset, actions deny traffic without further inspection of any kind,
Block with Reset rules also reset the connection.

200
 Bootcamp SSFIPS

For unencrypted HTTP traffic, when the system blocks a web request, you can override the
default browser or server page with a custom page that explains that the connection was
denied. The system calls this custom page an HTTP response page.

For all interactively blocked traffic, the system's handling, inspection, and legging depend on
whether the user bypasses the block:

• If a user does not (or cannot) bypass the block, the rule mimics a Block rule.
Matching traffic is denied without further inspection, and you can log only the beginning of
the connection. These beginning-of-connection events have an Interactive Block or
Interactive Block with Reset action.

• If a user bypasses the block, the rule mimics an Allow rule. Therefore, you can
associate either type of Interactive Block rule with a file and intrusion policy to inspect this
user-allowed traffic. The system can also use network discovery to inspect it, and you can
log both beginning and end-of-connection events. These connection events have an action
of Allow.

The Monitor action does not affect traffic flow: matching traffic is neither immediately
permitted nor denied. Rather, traffic is matched against additional rules to determine whether
to permit or deny it. The first non-Monitor rule matched determines traffic flow and any
further inspection. If there are no additional matching rules, the system uses the default
action.

Because the primary purpose of Monitor rules is to track network traffic, the system
automatically logs end-of connection events for monitored traffic. That is, connections are
legged even if the traffic matches no other rules and you do not enable logging on the
default action.

201
 Bootcamp SSFIPS

The Trust action allows traffic to pass without further inspection of any kind. This means not
sending the traffic to an NGIPS Policy or a File/Malware Policy. One of the criteria you will
want to consider for creating trust rules is if there are any NGIPS rules written for that traffic.
If this is traffic in which you would not look for malicious traffic, you might want to use Trust
to improve performance.

You can log trusted network traffic at both the beginning and end of connections. Note that
the system logs TCP connections handled by a Trust rule differently depending on the model
of the device that detected the connection. A Fast-Path rule, an option on the 8000 Series
Firepower devices, is similar to Trust.

For most devices, the system processes certain Trust rules before an access control
policy's Security Intelligence blacklist, which can allow blacklisted traffic to pass uninspected.
You will see this described when you learn about what the systems calls "promoted rules"
later in this module.

202
 Bootcamp SSFIPS

Trusting at the Default Action will perform the same result as Trust in an access control
policy rule. Using Trust as the default action will allow any traffic not matching on an access
control policy rule to bypass further inspection. This is the same as trusting in an AC rule,
except in a different location.

The Allow action allows matching traffic to pass through the access control policy. But
depending on your license, you can perform deep inspection to further inspect and block
unencrypted or decrypted network traffic before it reaches its destination:

• You can use an intrusion policy to analyze network traffic according to intrusion detection
and prevention configurations, and drop offending packets, depending on the
configuration.

• You can perform file control by using a file policy. File control allows you to detect and
block your users from uploading (sending) or downloading (receiving) files of specific
types over specific application protocols.

• You can perform network-based advanced malware protection (AMP), also by using a
file policy. AMP for Firepower can inspect files for malware, and block detected malware,
depending on the configuration.

203
 Bootcamp SSFIPS

You can set up your access control policy with no rules and just a default action. This is not
common, as you typically will want to do some traffic and log management here.

The graphic shows your access control policy set up this way. with no rules added.
A newly created access control policy directs its target devices to handle all traffic using its
default action.

Blocking by port is fast and efficient, but what about SSH traffic running over other ports’

If you block on an SSH port, you are blocking all traffic running over Port 22. This rule would
not trigger on SSH traffic running on any other port.

Always be sure to distinguish between Application Detection and Port. There are typically
several methods available to you in your access control policy to accomplish what you want
to do, but they might not be the best or the most accurate for performance.

When you deploy an access control policy, the system evaluates all its rules and creates an
expanded set of criteria that targeted devices use to evaluate network traffic. Complex
access control polices (access control polices that have a large number of rules, particularly
application detection rules) and rules can command significant resources. In general, a
complex rule can be seen as a rule that has any rule condition other than security zone.
VLAN tag. IP address, or port.

204
 Bootcamp SSFIPS

Limitations to Application Control

The system cannot perform application control until two conditions occur:

• A monitored connection is established between a client and server.

• The system identifies the application in the session.

This identification should occur within 3 to 5 packets, or after the server certificate exchange
in the SSL handshake if the traffic is encrypted. If one of these first packets matches all other
conditions in an access control rule containing an application condition but the identification
is not complete, the access control policy allows the packet to pass. This behavior allows the
connection to be established so that applications can be identified. For your convenience,
affected rules are marked with an information icon. The allowed packets are inspected by
the access control policy's default intrusion policy (not the default action intrusion policy or
the almost-matched rule's intrusion policy). After the system completes its identification, the
system applies the access control rule action, as well as any associated intrusion and file
policy, to the remaining session traffic that matches its application condition.

It is usually faster and more efficient to detect by port, but both port and application are
available to you if an application detector is written to identify this application. In this
example, with SSH, an application detector is written.

205
 Bootcamp SSFIPS
Lesson Summary

In this lesson, you learned the following:

• ACP Rules are used to identify certain traffic criteria.

• The ACP Default Action sits at the end of the ACP and identifies all traffic not previously
matched on an ACP rule.
• The ACP Rules and Default Action enable you to block, trust, and allow traffic.
• The ACP Block action drops the matching traffic.
• The ACP Monitor action marks the traffic for a connection log, and continues processing
the traffic by the rules.
• The Trust action performs no additional inspection on the matching traffic and passes the
traffic through the system immediately.
• The Allow action sends the traffic for further inspection by an Intrusion Policy or Malware
and File Polices.
• An access control policy with no rules added sends all traffic to the default action, and
application identification rules allow you to identify the traffic by port, application, or both.

206
 Bootcamp SSFIPS
Introducing Further Inspection

Description

This lesson describes the further inspection options Intrusion Policy and Malware & File
Policy, and explains how traffic proceeds to these policies.
Objectives
After completing this lesson, you will be able to do the following:
• Identify the further inspection options
• Describe the role of Intrusion Policies and how to direct traffic to the Intrusion Policy
for further inspection
• Describe the role of Malware & File Policies and how to direct traffic to them for
further inspection

Under the Inspection tab. there are three options:

• Intrusion Policy
• Variable Set (the variables that will be used for that Intrusion Policy)
• Malware & File Policy (If a file is detected in the traffic and matches the conditions in
the File Policy, it is sent here for File and/or Malware processing.)

207
 Bootcamp SSFIPS

In many environments, most traffic is sent to your intrusion policy. The Allow Access Control
Policy rule action, an Interactive Block, or the Default Action can send traffic to this policy.

An intrusion policy uses intrusion and preprocessor rules (sometimes referred to collectively
as intrusion rules) to examine the decoded packets for attacks based on patterns. Intrusion
policies are paired with variable sets, which allow you to use named values to accurately
reflect your network environment.

You can use an unlimited number of unique intrusion policies to inspect traffic access control
policy: you can associate one intrusion policy with each Allow and Interactive Block rule, as
well as with the default action.

Every unique pair of intrusion policy and variable set counts as one policy. However, a
maximum number of access control rules or intrusion policies are supported by a target
device. The maximum depends on a number of factors, including policy complexity, physical
memory, and the number of processors on the device.
If you exceed the maximum supported by your device, you cannot deploy your access
control policy and must reevaluate. You might want to consolidate intrusion policies or
variable sets, so that you can associate a single intrusion policy-variable set pair with
multiple access control rules.

208
 Bootcamp SSFIPS

Malicious software, or malware, can enter your organization's network via multiple routes. To
help you identify and mitigate the effects of malware, the Firepower System's Advanced
Malware Protection for Firepower (AMP for Firepower) features can detect, track, store,
analyze, and optionally block the transmission of malware in network traffic. Malware & File
Policy is where traffic goes when it matches on an Allow rule action in your access control
policy.

209
 Bootcamp SSFIPS

210
 Bootcamp SSFIPS

Lesson Summary

In this lesson, you learned the following:

• Sending traffic for further inspection is managed in the access control polio/ and
allows you to send traffic to the Intrusion Policy and the Malware & File Policy.
• The Intrusion Policy is where traffic is inspected by Snort rules. They can be sent
there by the Allow action in an ACP Rule or by the Default Action
The Malware & File Policy is where files within the traffic are inspected. They can be sent
there by the Allow action in an ACP Rule.

211
 Bootcamp SSFIPS
Examining Connection Events

Description

This lesson examines connection events in the Firepower Management Center, and
describes how they are managed in the access control policy.

Objectives

After completing this lesson, you will be able to do the following:

• Describe connection events and how they are logged
• Explain how to enable connection event legging
• Describe the various types of connection event log options and best practices

As managed devices monitor traffic generated by the hosts on your network, they can
generate logs of the connections that they detect. Various settings in access control and
SSL polices give you granular control over which connections you log, when you log them,
and where you store the data. An access control rules specify logging configuration also
determines whether you log file and malware events associated with the connection. In most
cases, you can log a connection at its beginning or its end, or both. When you log a
connection, the system generates a connection event. You can also log a special kind of
connection event, called a Security Intelligence event, whenever a connection is blacklisted
(blocked) by the reputation-based Security Intelligence feature.

Automatic Connection Logging

In addition to the logging that you configure, the system automatically logs most connections
where the system detects a prohibited file, malware, or intrusion attempt. Unless you disable
connection event storage entirely for the Firepower Management Center, regardless of your
other logging configurations, the system saves these end-of-connection events to the
Firepower Management Center database for further analysis. All connection events reflect
why they were automatically logged.

Connection events contain data about the detected sessions. The information available for
any individual connection event depends on several factors, but in general includes the
following:

212
 Bootcamp SSFIPS

• Basic connection properties: time stamp, source and destination IP address, ingress
and egress zones, the device that handled the connection, and so on
• Additional connection properties discovered or inferred by the system: applications,
requested URLs, or users associated with the connection, and so on
• Metadata about why the connection was logged: which access control rule {or other
configuration) in which policy handled the traffic, whether the connection was allowed or
blocked, details about encrypted and decrypted connections, and so on

To supplement the connection data gathered by your managed devices, you can use
records generated by devices enabled by NetFlow to generate connection events. This is
specifically useful if you have such devices deployed on networks that your Firepower
System managed devices cannot monitor.

Within the access control policy, you will need to determine many aspects of your Firepower
System. There are two types of information.

First, you have logging and data gathering. This includes logs for connection events.
Security Intelligence Events, and so on. In addition, the Network Discovery information that
you learned about also is determined here. In the access control policy you can choose to
not collect this information.

Second are the traffic flow next steps. Are you going to inspect this traffic for malware? For
files? Will this traffic be inspected for malicious behavior? You deeded in the access control
policy.

213
 Bootcamp SSFIPS

You can log connection and Security Intelligence events to the Firepower Management
Center database, as well as to an external syslog or SNMP trap server. The number of
events that a Firepower Management Center can store depends on its model. Before you
can log connection data to an external server, you must configure a connection to that server
called an alert response.

Logging to the Firepower Management Center database allows you to take advantage of
many reporting, analysis, and data correlation features of the Firepower System. Here are
some examples:

• Dashboards and the Context Explorer provide you with graphical, at-a-glance views
of the connections logged by the system.

• Event views present detailed information on the connections logged by the system,
which you can display in a graphical or tabular format or summarize in a report.

• Traffic profiling uses connection data to create a profile of your normal network traffic
that you can then use as a baseline in detecting and tracking anomalous behavior.

• Correlation polices allow you to generate events and trigger responses (such as alerts or
external remediations) to specify types of connections or traffic profile changes.
Here are some examples of Core Log and Flow concepts:

• Traffic flows from the Access Control Policy to Intrusion Policy and/or Malware & File
Policy if you direct it to do so.

• Objects feed the Access Control Policy.

• Most connection events are generated from Access Control Policy logging. You can
choose to enable or disable logging in the Access Control Policy.

• Host Profile discovery information is built for traffic in the Access Control Policy that is
not blocked or trusted.

214
 Bootcamp SSFIPS

215
 Bootcamp SSFIPS
Typically for Allow rules, you would not log at the beginning of a connection unless you
specially need this log at the time that the connection is made. This is typically done if you
plan to tie this connection event to an alert.

Because blocked traffic is immediately denied without further inspection, in most cases you
can log only beginning-of-connection events for blocked or blacklisted traffic; there is no
unique end of connection to log. An exception occurs when you block encrypted traffic.
When you enable connection logging in an SSL policy, the system logs end-of-connection
rather than beginning-of-connection events. This is because the system cannot determine if
a connection is encrypted with the use of the first packet in the session, and thus cannot
immediately block encrypted sessions.

The system always logs the ends of the following connections to the Firepower Management
Center database, regardless of the logging configuration of the rule or default action that
later handles the connection:

• Connections matching a Security Intelligence blacklist set to monitor

• Connections matching an SSL Monitor rule
• Connections matching an access control Monitor rule

In other words, if a packet matches a Monitor rule or Security Intelligence monitored

blacklist, the connection is always logged, even if the packet matches no other rules and you
do not enable logging on the default action. Whenever the system logs a connection event
as the result of Security Intelligence filtering, it also logs a matching Security Intelligence
event, which is a special kind of connection event that you can view and analyze separately.

Because monitored traffic is always later handled by another rule or by the default action, the
Action field for a connection event logged due to a monitor rule is never Monitor. Rather, it
reflects the action of the rule or default action that later handles the connection.

The system does not generate a separate event each time that a single connection matches
an SSL or access control Monitor rule. Because a single connection can match multiple
Monitor rules, each connection event logged to the Firepower Management Center database
can include and display information on the first eight Monitor access control rules that the
connection matches, as well as on the first matching Monitor SSL rule. Similarly, if you send
connection events to an external syslog or SNMP trap server, the system does not send a
separate alert each time that a single connection matches a Monitor rule. Rather, the alert
that the system sends at the end of the connection contains information on the Monitor rules
that the connection matched.

216
 Bootcamp SSFIPS

When the system detects a connection, in most cases you can log it at its beginning or its
end. However, because blocked traffic is immediately denied without further inspection, in
most cases you can log only beginning-of-connection events for blocked or blacklisted traffic;
there is no unique end of connection to log. An exception occurs when you block encrypted
traffic. When you enable connection logging in an SSL policy, the system logs end-of-
connection rather than beginning-of-connection events. This is because the system cannot
determine if a connection is encrypted using the first packet in the session, and thus cannot
immediately block encrypted sessions.
To optimize performance, log either the beginning or the end of any connection, but not both.
You can trigger correlation rules based on either beginning- or end-of-connection events.

Note that monitoring a connection for any reason forces end-of-connection logging. The
table in the graphic details the differences between beginning- and end-of-connection
events, including the advantages of logging each.

217
 Bootcamp SSFIPS
Lesson Summary

In this lesson, you learned the following:

• Connection events contain critical information about the traffic detected passing through
the managed device, and they are generated when legging is enabled for that matching
traffic.

• Connection events can be enabled in both the ACP rule and the default action of the
access control policy.

• You can log at the beginning of connections, at the end of connections (recommended
for most traffic), or both.

218
 Bootcamp SSFIPS
Access Control Policy Advanced Settings

Description

This lesson identifies the critical components of the advanced section of the Access Control
Policy menu.

Objectives

After completing this lesson, you will be able to do the following:

• Identify the Files and Malware settings in the advanced settings of the ACP
• Identify the Latency-Based settings in the advanced settings of the ACP
• Describe the advanced Network Analysis and Intrusion Polices settings
Describe the role of SSL decryption

219
 Bootcamp SSFIPS

Advanced access control policy settings typically require little or no modification. The default
settings are appropriate for most deployments. Note that many of the advanced
preprocessing and performance options in access control polices can be modified by rule
updates.

Modifying these settings is not typical and should be done only with direction by Cisco
Support or an advanced user.

If a view icon appears instead, settings are inherited from an ancestor policy, or you do not
have permission to modify the settings. If the configuration is unlocked, uncheck Inherit from
base policy to enable editing.

You can do further tuning in your Firepower System with the Latency-Based settings. It is
recommended that you keep them at their defaults except under the guide of Cisco Support
or an advanced user.

Packet latency thresholding measures the total elapsed time taken to process a packet by
applicable decoders, preprocessors, and rules, and ceases inspection of the packet if the
processing time exceeds a configurable threshold.

Rule latency thresholding measures the elapsed time that each rule takes to process an
individual packet. It also suspends the violating rule, along with a group of related rules, for a
specified time if the processing time exceeds the rule latency threshold a configurable
consecutive number of times. The rule latency thresholding restores the rules when the
suspension expires.

220
 Bootcamp SSFIPS

Advanced network analysis and intrusion policy settings allow you to do the following:

• Change the access control policy's default intrusion policy and associated variable set,
which are used to initially inspect traffic before the system can determine exactly how to
inspect that traffic

• Change the access control policy's default network analysis policy, which governs many
preprocessing options

• Use custom network analysis rules and network analysis polices to tailor preprocessing
options to specify security zones, networks, and VLANs

By default, the system cannot inspect traffic encrypted with the Secure Socket Layer (SSL)
or Transport Layer Security (TLS) protocols. As part of access control, the SSL inspection
feature allows you to either block encrypted traffic without inspecting it, or inspect encrypted
or decrypted traffic with access control. As the system handles encrypted sessions, it logs
details about the traffic. The combination of inspecting encrypted traffic and analyzing
encrypted session data allows greater awareness and control of the encrypted applications
and traffic in your network.

If the system detects an SSL or TLS handshake over a TCP connection, it determines
whether it can decrypt the detected traffic. If it cannot, it applies a configured action:

221
 Bootcamp SSFIPS

• Block the encrypted traffic

• Block the encrypted traffic and reset the TCP connection

• Do not decrypt the encrypted traffic

Note that access control rules handle encrypted traffic when your SSL inspection
configuration allows it to pass, or if you do not configure SSL inspection. However, some
access control rule conditions require unencrypted traffic, so encrypted traffic may match
fewer rules. Also, by default, the system disables intrusion and file inspection of encrypted
payloads. This helps reduce false positives and improve performance when an encrypted
connection matches an access control rule that has intrusion and file inspection configured.
If the system can decrypt the traffic, it blocks the traffic without further inspection, evaluates
encrypted traffic with access control, or decrypts it by using one of the following methods:

• Decrypt with a known private key. When an external host initiates an SSL handshake
with a server on your network, the system matches the exchanged server certificate with
a server certificate previously uploaded to the appliance. It then uses the uploaded
private key to decrypt the traffic.

• Decrypt by re-signing the server certificate. When a host on your network initiates an
SSL handshake with an external server, the system re-signs the exchanged server
certificate with a previously uploaded certificate authority (CA) certificate. It then uses the
uploaded private key to decrypt the traffic.

Decrypted traffic is subject to the same traffic handling and analysis as originally
unencrypted traffic: network, reputation, and user-based access control; intrusion detection
and prevention; Cisco Advanced Malware Protection (Cisco AMP); and discovery. If the
system does not block the decrypted traffic post-analysis, it re-encrypts the traffic before
passing it to the destination host.

SSL Inspection Requirements

SSL inspection requires a 7000 or 8000 Series device, or an ASA FirePOWER module. How
you deploy the appliances on your network, in addition to your configuration settings and
licenses, influences the actions that you can take to control and decrypt encrypted traffic.
Review your list of mapped actions, existing network deployment, and overall requirements
to determine whether one or the other type of deployment better suits your organization.

Devices configured and deployed with inline, routed, switched, or hybrid interfaces can
modify the flow of traffic. These devices can monitor, block, allow, and decrypt incoming and
outgoing traffic.

Devices configured and deployed with passive or inline (tap mode) interfaces cannot affect
the flow of traffic. They can only monitor, allow, and decrypt incoming traffic. Note that
passive deployments do not support decrypting traffic encrypted with the ephemeral Diffie-
Hellman (DHE) or the elliptic curve Diffie-Hellman (ECDHE) cipher suites.

SSL inspection requires public key certificates and paired private keys for certain features.
You must upload certificates and paired private keys to the Firepower
Management Center to decrypt and control traffic based on encryption session
characteristics.

222
 Bootcamp SSFIPS

223
 Bootcamp SSFIPS
Lesson Summary

In this lesson, you learned the following:

• The Files and Malware settings contain information for the Malware Polices
associated to the ACP Rules.

• The Latency-Based settings are protections built into the access control policy to
ensure that latency is not introduced into the environment.

• Network Analysis Policy management is performed in the access control policy

advanced settings menu.

SSL decryption enables the inspection of encrypted traffic.

224
 Bootcamp SSFIPS
Access Control Policy Considerations

Description

This lesson explains certain access control policy considerations that are critical to proper
implementation and management of the access control policy.

Objectives

After completing this lesson, you will be able to do the following:

• Describe the ACP configuration considerations
• Describe Network Discovery and its relation to the Network Discovery Policy
• Describe ACP Inheritance
• Describe the considerations that are necessary for creating an initial access control
policy

Describe the procedure required for creating and deploying an access control policy

You will want to be careful in correctly distinguishing between a port and an application.
Recall that the Firepower System is application-aware. This means that not only does the
system see the port that the traffic is associated to, but the system also can see the
application that the traffic is part of. This is true as long as there is an application detector
written for it, which is a system-provided means of performing application detection.

In the Firepower System, you have the flexibility to make decision on any of the conditions
that Firepower can detect.

For example, if FTP traffic is detected, you can make a decision on that traffic based on the
port that it is running over, or FTP as an application. You choose to block FTP except over
certain ports, or only on certain ports. Most conditions that can be detected by Firepower can
be used as an access control policy rule.

225
 Bootcamp SSFIPS

Most rule conditions can be added manually with or without objects. Before you can perform
user control (create access control rule conditions based on entire realms, individual users,
user groups, or ISE attributes), however, you must do the following:

• Configure a realm for each Microsoft Active Directory or LDAP server you want to
monitor (including your ISE or User Agent servers). If you enable user download for the
realm, the Firepower Management Center regularly and automatically queries the server
to download metadata for newly or already-reported authoritative users and user groups.

• Create an identity policy to associate the realm with an authentication method.

• Configure one or more user agents or ISE devices, or captive portal. If you want to use
an ISE attribute condition, you must configure ISE.

User agents. ISE, and captive portal collect authoritative user data that can be used for user
control in access control rule conditions. The identity sources monitor specified users as they
log in or out of hosts or as they authenticate by using LDAP or AD credentials.

You can combine realm, user, group, and ISE attribute conditions to create simple or
complex access control rules, matching and inspecting traffic by using multiple conditions.

You can add a maximum of 50 realms, users, and groups to the selected users in a single
user condition.

Conditions with user groups match traffic to or from any of the group's members, including
members of any subgroups, with the exception of individually excluded users and members
of excluded subgroups.

Including a user group automatically includes all of that group's members, including
members of any secondary groups. However, if you want to use the secondary group in
access control rules, you must explicitly include the secondary group.

226
 Bootcamp SSFIPS

On any managed devices except NGIPSv and ASA FirePOWER, the system can promote
access control rules that meet specific criteria. Promoted rules immediately divert or block
traffic that does not require deep packet inspection. Their advantage is the speed at which
they determine the correct path for the traffic. Note that the rule promotion process occurs in
the NIC hardware.

Because this evaluation takes place at a basic level, the system can only use limited
information to quickly handle connections by promoting rules. Supported devices promote
rules that meet all of the following criteria:

• Have the Trust. Block, or Block with Reset action

• Use only simple, network-based conditions: security zone. IP address. VLAN tag, and
port
• Are placed above all other access control rules (regardless of action) that perform deep
packet inspection—that is, that have application. URL, user, or geolocation-based
conditions
• Are also placed above all Monitor rules

Therefore, rules that are promoted to improve performance are most likely simple Trust or
Block rules that are placed either near the top of an access control policy (rules with a low
number) or anywhere in a policy that uses only simple, network-based rules. However, the
performance benefits from rule promotion can cause some unexpected behavior.

Preempting Security Intelligence

The system processes promoted rules before an access control policy's Security Intelligence
blacklist. This means that promoted Trust rules can allow blacklisted traffic to pass
uninspected.

Preventing HTTP Response Page Display

Web traffic blocked by a promoted Block rule does not cause the system to display the
configured HTTP response page to your users, even though the system successfully blocks
the traffic. Instead, users requesting prohibited URLs have their connection either reset or
timed out.

IPv6 Traffic Handling

The system can inspect both IPv4 and IPv6 traffic, IPv6 inspection includes the 4in6. 6in4.
6to4, and 6in6 tunneling schemes, and also includes Teredo tunneling when the UDP

227
 Bootcamp SSFIPS
header specific port 3544. When evaluating traffic using access control rules with IP address
conditions, in most cases devices match the IP address that you specific against the IP
address in the innermost packet header. However, promoted rules use the IP address in the
outermost header to evaluate IPv6 traffic, regardless of whether that traffic is tunneled, and
regardless of where the IPv6 header is: innermost or outermost. In other words, when
promoted rules evaluate tunneled traffic, only 4in4 traffic uses the innermost header to
match against access control rule criteria.

For example, consider a scenario in which you are examining 6in4 tunneled traffic sent over
an IPv4 network. You create a simple, network-based access control rule that blocks traffic
to or from a specific IPv6 address. If the system promotes the rule as a result of its position
in the access control policy, the rule has no effed. This result is because the system matches
the outermost IPv4 header of a tunneled packet to the IPv6 rule condition, which can never
trigger. The system handles the traffic as if the rule did not exist, using either a subsequent
access control rule or the policy's default action

You configure what traffic you will collect Discovery information on in your Network
Discovery Policy and. if you choose to do so, in your access control policy. If you recall, you
saw how Firepower discovers information about your hosts and users based on the traffic
that it detects. You have the option to create an access control policy to do only this task and
not inspect further, as you will see later. The important concept to grasp here is that,
although you have already configured your Network Discovery policy to discover your hosts
and users in your network, your access control policy also can make decision on this.

The reason is that the access control policy is processed before this host profile and user
information is collected, so you can choose not to collect this information even though your
Network Discovery policy is set up to do so.

228
 Bootcamp SSFIPS

Logging discovery and identity data allows you to take advantage of many features in the
Firepower System:

• Viewing the network map, which is a detailed representation of your network assets and
topology that you can view by grouping hosts and network devices, host attributes,
application protocols, or vulnerabilities.

• Viewing host profiles, which are complete views of all the information available for your
detected hosts.

• Viewing dashboards, which (among other capabilities) can provide you with an at-a-
glance view of your network assets and user activity.

• Viewing detailed information on the discovery events and user activity logged by the
system.

• Creating reports based on discovery data.

• Performing application and user control—that is, writing access control rules using
application, realm, user, user group, and ISE attribute conditions.

• Associating hosts and any servers or clients that they are running with the exploits to
which they are susceptible, which allows you to identify and mitigate vulnerabilities,

229
 Bootcamp SSFIPS
evaluate the impact that intrusion events have on your network, and tune intrusion rule
states so that they provide maximum protection for your network assets.

• Alerting you via email. SNMP trap, or syslog when the system generates either an
intrusion event with a specific impact flag, or a specific type of discovery event.
• Monitor your organization's compliance with a whitelist of allowed operating systems,
clients, application protocols, and protocols.

• Creating correlation polices with rules that trigger and generate correlation events when
the system generates discovery events or detects user activity

If you log NetFlow connections, using that connection data.

The system will perform passive operating-system and host data on all traffic detected by the
system.

Passive Detection of Operating System and Host Data

Passive detection is the detection of host operating system, client and application
information through analysis of traffic passively collected by the system. The system uses
information in the VDB to help it identify your network assets.

If the system cannot identify an operating system on a host, you can manually determine it
and then create a custom server or client fingerprint to help the system recognize that
operating system on other hosts with similar operating system characteristics.

The system uses all collected passive fingerprints for a host operating system to create a
derived fingerprint.

The system creates derived fingerprints by applying a formula that calculates the most likely
identity, using the confidence value of each collected fingerprint and the amount of
corroborating fingerprint data between identities. Common elements are identified between
identities. If you use custom applications on your network, you can augment the system's
application detection capabilities by creating custom application detectors that provide the
system with the information that it requires to identify those applications. NetFlow can also
add passively detected application information to the network map.

230
 Bootcamp SSFIPS

Access control uses a hierarchical policy-based implementation that complements

multitenancy. Just as you nest domains, you can nest access control polices. A descendant,
or child, access control policy inherits rules and settings from its direct parent, or base,
policy. That base policy might have its own parent policy from which it inherits rules and
settings, and so on.

An access control policy's rules are nested between its parent policy's Mandatory and
Default rule sections. This implementation enforces mandatory rules from ancestor policies,
but allows the current policy to write rules that preempt default rules from ancestor polices.

You can lock the following settings to enforce them in all descendant polices.

Descendant polices can override unlocked settings:

• Security Intelligence—Blacklisting and whitelisting connections based on the latest

IP address. URL, and domain name reputation intelligence.

• HTTP Response pages—Displaying a custom or system-provided response page

when you block a user's website request.

• Advanced settings—Specifying associated identity and SSL polices, network

analysis settings, performance settings, and other general options.

Although an access control policy can inherit its default action from an ancestor policy, you
cannot enforce this inheritance.

231
 Bootcamp SSFIPS

In a typical multidomain deployment, access control policy nesting corresponds to domain

structure, and you apply the innermost access control policy to managed devices. This
implementation allows selective access control enforcement at a higher domain level, while
lower-level domain administrators tailor deployment-specific settings. (You must use roles,
not policy inheritance and enforcement alone, to restrict administrators in descendant
domains.)

For example, as a Global domain administrator for your organization, you can create an
access control policy at the Global level. You can then require that all your devices, which
are divided into subdomain by function, use that Global-level policy as a base policy.

When subdomain administrators log in to the Firepower Management Center to configure

access control, they can deploy the Global-level policy as it is. As an alternative, they can
create and deploy a descendant access control policy within the boundaries of the Global-
level policy.

When you create a new access control policy, you must choose, at a minimum, a default
action. In most cases, logging of connections handled by a default action is initially disabled.
An exception occurs if you create a subpolicy in a multidomain deployment. In that case, the

232
 Bootcamp SSFIPS
system enables connection logging according to the logging configuration of the inherited
default action.

Initially deploying an access control policy to a managed device restarts the Snort process
and interrupts traffic when you deploy configuration changes. Whether this interruption drops
traffic or passes traffic without inspection depends on the model of the managed device and
how it handles traffic.

To create a new access control policy, follow these steps:

Step 1
Choose Policies > Access Control.

Step 2
Click Mew Policy.

Step 3
Enter s unique name and. optionally, a description.

Step 4
Optionally, choose a base policy from the Select Base Policy drop-down list.
If an access control policy is enforced on your domain, this step is not optional. You must
choose the enforced policy or one of its descendants as the base policy.

Step 5
Specify the initial default action:
• If you chose a base policy, your new policy inherits its default action. You cannot change
it here.
• Block All Traffic creates a policy with the Access Control: Block All Traffic default action.
• Intrusion Prevention creates a policy with the Intrusion Prevention: Balanced Security
and Connectivity default action, associated with the default intrusion variable set.
• Network Discovery creates a policy with the Network Discovery Only default action.
Tip: If you want to trust all traffic by default, or if you chose a base policy and do not want to
inherit the default action, you can change the default action later.

Step 6
Optionally, choose the available devices where you want to deploy the policy, and then dick
Add to Policy {or drag and drop) to add the selected devices. To narrow the list of devices
that appears, type a search string in the Search field. If you want to deploy this policy
immediately, you must perform this step.

Step 7
Click Save.

When creating a new access control policy, you need to define the following:

• Name and Description—Each access control policy must have a unique name. A
description is optional.

• Inheritance Settings—Policy inheritance allows you to create a hierarchy of access

control polices. A parent {or base) policy defines and enforces default settings for its
descendants, which is especially useful in multidomain deployments.

233
 Bootcamp SSFIPS
A policy's inheritance settings allow you to select its base policy. You can also lock settings
in the current policy to force any descendants to inherit them. Descendant polices can
override unlocked settings.

• Policy Assignment—Each access control policy identifies the devices that use it. Each
device can be targeted by only one access control policy. In a multidomain deployment,
you can require that all the devices in a domain use the same base policy.
• Security Intelligence—Security Intelligence is a first line of defense against malicious
Internet content. This feature allows you to blacklist (block) connections based on the
latest IP address. URL, and domain name reputation intelligence. To ensure continual
access to vital resources, you can override blacklists with custom whitelists.

• HTTP Responses—When the system blocks a user's website request, you can display
either a generic system-provided response page or a custom page. You can also display
a page that warns users but also allows them to continue to the originally requested site.

• Advanced Access Control Options—Advanced access control policy settings typically

require little or no modification. Often, the default settings are appropriate. Advanced
settings that you can modify include traffic preprocessing. SSL inspection, identity, and
various performance options.

All access control policies created in your Firepower Management Center will be displayed
under Policies > Access Control Policies.

Only one person should edit an access control policy at a time, using a single browser
window. If multiple users save the same policy, the last saved changes are retained. For
your convenience, the system displays information on who (if anyone) is currently editing
each policy.

To protect the privacy of your session, a warning appears after SO minutes of inactivity on
the policy editor.

After 60 minutes, the system discards your changes.

234
 Bootcamp SSFIPS

You can go to the Deploy tab. to the upper-right corner of the GUI to see if any polices are
out of date. From here, you can deploy the configurations necessary.

Deploying configuration changes might cause a short pause in traffic flow and processing as
the Snort process restarts, and can also cause a few packets to pass uninspected. To
minimize inconvenience, deploy during a change window.

To deploy configuration changes, follow these steps:

Step 1
Click the Deploy button.
The Deploy Polices dialog box appears.

Step 2
Identify the devices where you want to deploy configuration changes:

• Sort—Sort the device list by clicking a column heading.

• Filter—Filter the device list. To do so, click the arrow in the upper-right corner of any
column heading in the display, enter text in the Filter text box, and press Enter.

Step 3
Optionally, expand the device listing to view the configuration changes to be deployed.
The system marks out-of-date polices with an index icon.

Step 4
Choose the devices where you want to deploy configuration changes.

Step 5
Click. Deploy.

Step 6
If the system identifies errors or warnings in the changes to be deployed, you have the
following choices:

• Click Proceed to continue deploying without resolving error or warning conditions. This
button is enabled if the system identifies only warnings for the deployment; it is disabled
if the system identifies an error in the deployment.

• Click Cancel to exit without deploying. Resolve the error and warning conditions, and
attempt to deploy the configuration again.

235
 Bootcamp SSFIPS

Lesson Summary

In this lesson, you learned the following:

• Further access control policy configurations include the promotion of access control
policy rules, and the distinction between matching on an application condition versus a
port condition.

• Network discovery requires an access control policy and can be skipped with Trust and
Block rules regardless of what was configured in your network discovery policy.

• Access control policy inheritance allows you to build an access control policy to use as a
base for future polices.

• Before creating an access control policy, you must consider which traffic you are
inspecting, which traffic you choose to trust, and which traffic you want to prevent from
passing through the Firepower System.

Access control polices must be deployed in order to take effed.

236
 Bootcamp SSFIPS

Module Summary for “Implementing Access Control Policies”

In this module, you learned the following:

• Access control policies act as the application firewall in the Firepower System, with
components for identifying traffic and making logging decisions

• Access control policy rules identify matching criteria for traffic, and can block, trust, or
send the identified traffic for further inspection.

• Access control polices identify traffic designated for further inspection. For example, the
system can inspect files and inspect the traffic by using Snort rules defined in an
Intrusion policy.

• Connection event logging is configured in the access control policy and has the option to
log at the beginning of the connection, the end, or both.

• The advanced features of the access control policy include settings for SSL policy.
Network Analysis policy, and Malware & File policy settings.

• Access control policy considerations include network discovery considerations and the
utilization of access control policy inheritance.

237
 Bootcamp SSFIPS

238
 Bootcamp SSFIPS

239
 Bootcamp SSFIPS
Module 8: Security Intelligence

Overview

Description

Security Intelligence is the part of your Firepower System that identifies known-bad traffic
prior to inspection by any other polices. Firepower is a multilayer security technology, with
Security Intelligence as the first of several layers working together.

Objectives

Upon completing this module, you will be able to describe the concepts and implementation
procedure of Security Intelligence features. This ability includes being able to meet these
objectives:
• Describe the concepts of Security Intelligence, whitelists, and blacklists
• Describe the three Security Intelligence object types
• Describe Security Intelligence implementation procedure and logging options

240
 Bootcamp SSFIPS

Examining Security Intelligence

Description

This lesson describes the fundamentals of Security Intelligence in the Firepower System and
the role of whitelists and blacklists.

Objectives

After completing this lesson, you will be able to do the following:

• Describe the concepts and functionality of Security Intelligence
• Describe the role of whitelists and blacklists
• Describe Security Intelligence use cases

241
 Bootcamp SSFIPS

As a first line of defense against malicious Internet content, the Firepower System includes
the Security Intelligence feature, which allows you to immediately blacklist (block)
connections, based on the latest reputation intelligence, removing the need for a more
resource-intensive, in-depth analysis.

Security Intelligence works by blocking traffic to or from IP addresses. UP.Ls. or domain

names that have a known bad reputation. This traffic filtering takes place before any other
policy-based inspection, analysis, or traffic handling (although it does occur after hard ware-
level handling, such as fast-pathing).

You would set up Security Intelligence differently, based on the deployment type. For
passive deployments because you cannot act on the traffic, you will want to monitor
connections in Security Intelligence, as opposed to block. Otherwise, you will lose additional
visibility by performing further inspection by Intrusion Policy and Malware & File Policy. Keep
in mind your deployment topology, present and planned, to best take advantage of these
security layers.

It is important to be familiar with the layers of security built into the Firepower System. You
have already learned about access control polices and have looked at the fundamentals of
the Intrusion Polices and File & Malware Polices. Security Intelligence is another layer. As
shown in the graphic. Security Intelligence inspects traffic before any of the other polices.

242
 Bootcamp SSFIPS

Note that you could create access control rules that perform a similar function to Security
Intelligence filtering by manually restricting traffic by IP address or URL. However, access
control rules are wider in scope and more complex to configure, and they cannot
automatically update by using dynamic feeds.

A deeper look into how Security Intelligence relates to your object and access control policy
is shown here. Security Intelligence is looking at traffic in either good or bad categories. You
see these as blacklists and whitelists. Blacklist means potentially malicious and whitelist
means not malicious. These Security Intelligence lists are managed in your objects.

Traffic blacklisted by Security Intelligence is immediately blocked and therefore is not subject
to any further inspection— not for intrusions, exploits, malware, and so on but also not for
network discovery. You can override blacklisting with whitelisting to force access control rule
evaluation, and recommended in passive deployments, you can use a "monitor-only’ setting
for Security Intelligence filtering. This allows the system to analyze connections that would
have been blacklisted, but also logs the match to the blacklist and generates an end-of-
connection Security Intelligence event.

243
 Bootcamp SSFIPS

For traffic handled by many devices, the system processes certain trust rules before an
access control policy's Security Intelligence blacklist, which can allow blacklisted traffic to
pass uninspected.

Whitelists serve the purpose of overriding a blacklist.

If a reputable feed improperly blocks your access to vital resources but is overall useful to
your organization, you can whitelist only the improperly classified IP addresses, rather than
removing the whole feed from the blacklist.
A whitelisted address. URL, or domain name is not a free pass for the traffic. It simply allows
the traffic through the Security Intelligence layer. The traffic will still be inspected by the other
layers that you have in place.

244
 Bootcamp SSFIPS
Lesson Summary

In this lesson, you learned the following:

• Security Intelligence, which is the first layer of protection in the Firepower System, blocks
traffic for known bad IPs. URLS, and DNS requests.

• Blacklists hold the individual IP. URL, and DNS entries that are known to be malicious,
and whitelists are used to override any of these blacklist entries.

• Security Intelligence can be used to selectively monitor or block connections based on

networks, security zones, and the individual Security Intelligence categories that are
available.

245
 Bootcamp SSFIPS
Examining Security Intelligence Objects

Description

This lesson explains the Feed objects. List Objects, and Global List Objects used in Security
Intelligence and how they relate to the events in your Firepower Management Center.

Objectives

After completing this lesson, you will be able to do the following:

• Describe the three types of Security Intelligence objects
• Describe Security Intelligence feed objects and how they are implemented in your
Firepower System
• Describe a Security Intelligence list object
• Describe Security Intelligence global list objects and how they work with events in the
Firepower System

246
 Bootcamp SSFIPS

For your convenience, Cisco provides feeds containing IP addresses, domain names, and
URLs with poor reputation, as determined by Talos:

• The Intelligence Feed, which comprises several regularly updated lists of IP

addresses determined by TALOS to have a poor reputation

• The DNS and URL Intelligence Feed, which comprises several regularly updated
lists of domain names and URLs determined by Talos to have a poor reputation

Each list in either Intelligence Feed represents a specific category: open relays, known
attackers, bogus IP addresses (bogon), and so on. In an access control or DNS policy, you
can blacklist any or all of the categories. Because the Intelligence Feeds are regularly
updated, the system can use up-to-date information to filter your network traffic. Malicious IP
addresses, domain names, and URLs that represent security threats, such as malware,
spam, botnets, and phishing, may appear and disappear faster than you can update and
deploy new policies.

Although you cannot delete either Intelligence Feed, editing them allows you to change the
frequency of their updates. By default, each feed is updated every two hours.
Custom Security Intelligence Feeds

Custom, or third-party. Security Intelligence feeds allow you to augment the system-provided
Intelligence Feeds with other regularly updated reputable whitelists and blacklists on the

247
 Bootcamp SSFIPS
Internet. You can also set up an internal feed, which is useful if you want to update multiple
Firepower Management Centers in your deployment by using one source list.

You cannot whitelist or blacklist address blocks by using a /0 netmask in a Security

Intelligence feed. If you want to monitor or block all traffic targeted by a policy, use an
access control rule with the Monitor or Block rule action, respectively, and a default value of
Any for the source networks and destination networks.

When you configure a feed, you specify its location by using a URL; the URL cannot be
Punycode-encoded. By default, the system downloads the entire feed source on the interval
that you configure, and then automatically updates its managed devices.

You also can configure the system to use an md5 checksum to determine whether to
download an updated feed. If the checksum has not changed since the last time the system
downloaded the feed, the system does not need to redownload it. You may want to use md5
checksums for internal feeds, especially if they are large. The md5 checksum must be stored
in a simple text file with only the checksum. Comments are not supported.

Manually updating Security Intelligence feeds updates all feeds, including the Intelligence
Feeds.

To create a feed object, follow these steps:

Step 1
Choose Objects > Object Management.

Step 2
Expand the Security Intelligence node, and then choose a feed type that you want to
add.

Step 3
Click the option appropriate to the feed type that you chose in Step 2:
• Add Network Lists and Feeds
• Add DNS Lists and Feeds
• Add URL Lists and Feeds

Step 4
Enter a name for the feed.

In a multidomain deployment, object names must be unique within the domain hierarchy.
The system may identify a conflict with the name of an object that you cannot view in your
current domain.

Step 5
Choose Feed from the Type drop-down list.

Step 6
Enter a Feed URL.

Step 7
Optionally, enter an MD5 URL.

248
 Bootcamp SSFIPS
Step 8
Choose an update frequency.

Step 9
Click Save.

249
 Bootcamp SSFIPS
Security Intelligence lists are simple static lists of IP addresses and address blocks. URLs,
or domain names that you manually upload to the system. Custom lists are useful if you
want to augment and fine-tune feeds or one of the global lists, for a single Firepower
Management Center's managed devices.

For example, if a reputable feed improperly blocks your access to vital resources but is
useful overall to your organization, you can create a custom whitelist that contains only the
improperly classified IP addresses, rather than remove the IP address feed object from the
access control policy's blacklist.

You cannot whitelist or blacklist address blocks by using a /0 netmask in a Security

Intelligence list. If you want to monitor or block all traffic targeted by a policy, use an access
control rule with the Monitor or Block rule action, respectively, and a default value of Any for
the source networks and destination networks.

Regarding list entries, note the following:

• Netmasks for address blocks can be integers from 0 to 32 or from 0 to 128, for IPv4
and IPv6, respectively.

• Unicode in domain names must be encoded in Punycode format and are not case-
sensitive.

• Characters in domain names are not case-sensitive.

• Unicode in URLs should be encoded in percent-encoding format.

• Characters in URL subdirectories are case-sensitive.

• List entries that start with the pound sign (#) are treated as comments.

All IP addresses. URLs, and DNS addresses that you select to Blacklist Now or Whitelist
Now are automatically populated to your global list objects. You will immediately see these
global lists updated by navigating to Objects > Security Intelligence > Global Blacklist or
Global Whitelist. Global lists are immediately effective without a policy deployment.

250
 Bootcamp SSFIPS
To add IP entries to the global lists, follow these steps:

Step 1
Hover your pointer over an IP address hotspot.
In an event view or dashboard, hover your pointer over an IP address, not the host icon to its
left.

Step 2
Invoke the context menu:
• In an event view or dashboard, right-click.
• In the Context Explorer or packet view, left-click.

Step 3
From the context menu, choose either Whitelist How or Blacklist How.

Step 4
In a multidomain deployment, dick Choose Domains to choose the domains where you want
to whitelist or blacklist the IP address.
The system builds a separate network map for each leaf domain. In a multidomain
deployment, using literal IP addresses to constrain this configuration can have unexpected
results.

Step 5
Confirm that you want to whitelist or blacklist the IP address. After the Firepower
Management Center communicates your addition to its managed devices, your deployment
begins filtering traffic according to your change.

To add domain names and URLs to the global lists by using the Context menu, follow these
steps:

Step 1
In a connection event table view or the Context Explorer, hover your pointer over a URL
hotspot.

Step 2
Invoke the context menu:
• In an event view, right-click.
• In the Context Explorer, left-click.

Step 3
You have the following options:
• Choose Blacklist HTTP/S Connections to URL How to block connections to a
URL.
• Choose Whitelist HTTP/S Connections to URL How to allow connections to a
URL.
• Choose Blacklist HTTP/S Connections to Domain How to block connections to
a domain name.
• Choose Whitelist HTTP/S Connections to Domain How to allow connections to
a domain name.

251
 Bootcamp SSFIPS

Step 4
In a multidomain deployment, click Choose Domains to choose the domains where you want
to whitelist or blacklist the domain name.
The system builds a separate network map for each leaf domain. In a multidomain
deployment, using literal IP addresses to constrain this configuration can have unexpected
results.

Step 5
Confirm that you want to whitelist or blacklist the URL or domain name. After the Firepower
Management Center communicates your addition to its managed devices, your deployment
begins filtering traffic according to your change.

The Whitelist Now and Backlist Now options allow you to immediately take action on IPs.
URLs, or DNS entries by adding them to the global lists. These options are used mostly by
the analyst in response to some event The Firepower GUI allows for immediate blacklisting
and whitelisting with no policy deployment required. Because adding an entry to a Security
Intelligence list affects access control, you must have one of the following:
• A user account with administrator access permissions
• A combination of default roles: Network Admin or Access Admin, plus Security Analyst
and Security Approver
• A custom role with both Modify Access Control Policy and Deploy Configuration to
Devices permissions

252
 Bootcamp SSFIPS

Complete the activity to blacklist the IP address 192.168.10.90 and then confirm the entry
has been added to you Security Intelligence objects. The simulation will provide prompts to
assist you.

Complete the following steps:

Step 1
From the Connection Events view, right-click on any of the 192.168.10.90 IP address entries
in the Initiator IP column.

Step 2
Select Blacklist IP How and confirm when prompted.

Step 3
Navigate to the Objects > Object Management screen.

Step 4
Under the Security Intelligence object select Network Lists and Feeds

Step 5
Edit the Global Blacklist to confirm the presence of your 192.168.10.90 entry.

253
 Bootcamp SSFIPS

Lesson Summary

In this lesson, you learned the following:

• There are three basic types of Security Intelligence objects: feeds, lists, and global
lists.

• Security Intelligence feed objects are category feeds maintained by Talos. They are
fed directly into the Firepower System and are updated without user intervention after they
are configured.

• A Security Intelligence list object is a manually created list of blacklisted IPs. URLs,
or DNS entries.

• Global list objects are initially blank objects for both whitelists and blacklists that you
populate by selecting Whitelist Mow or Blacklist How in the events viewer.

254
 Bootcamp SSFIPS
Security Intelligence Deployment and Logging

Description

This lesson describes the procedures required for deploying and configuring Security
Intelligence. In this lesson, you will also explore the available logging options.

Objectives

After completing this lesson, you will be able to do the following:

• Describe the Security Intelligence deployment options
• Describe the Security Intelligence implementation procedure
• Describe the Security Intelligence actions
• Describe the procedure for enabling logging

Now that you understand the various types of Security Intelligence objects, you can see how
these objects become tied into your access control policy. All Security Intelligence feeds
categories. Global Security Intelligence lists, and Security Intelligence lists that you have
created are available for use here. You select the objects that you want to use, and add
them to the appropriate whitelist or blacklist column to the right. Any combination of URLs,
network objects, security zones, and Security Intelligence objects can be selected and
added to either a blacklist or a whitelist.

255
 Bootcamp SSFIPS

DNS blacklisting is similar to URL and IP-based Security Intelligence, with the added ability
to:

• Send a NXDOMAIN response to black-hole DNS requests.

• Forward requests to a sinkhole server, used to obtain Security Intelligence events.

256
 Bootcamp SSFIPS
Both IPv4 and IPv6 are supported.

DNS-based Security Intelligence allows you to whitelist or blacklist traffic, based on the
domain name requested by a client. Cisco provides domain name intelligence that you can
use to filter your traffic; you can also configure custom lists and feeds of domain names
tailored to your deployment. DNS-based Security Intelligence filtering occurs after hardware-
level handling (such as fast-path) and traffic decryption, and before most other policy-based
inspection, analysis, or traffic handling.

Traffic blacklisted by a DNS policy is immediately blocked and therefore is not subject to any
further inspection—not for intrusions, exploits, malware, and so on, but also not for network
discovery. You can override blacklisting with whitelisting to force access control rule
evaluation, and recommended in passive deployments, you can use a "monitor-only" setting
for Security Intelligence filtering. This action allows the system to analyze connections that
would have been blacklisted, but also logs the match to the blacklist and generates an end-
of-connection Security Intelligence event.

In order to utilize DNS Security Intelligence, you must first create a DNS policy.

Procedure

Step 1
In the access control policy editor, click the Security Intelligence tab.
If the controls are dimmed, either the settings are inherited from an ancestor policy or you do
not have permission to modify the configuration. If the configuration is unlocked, uncheck
Inherit from Base Policy to enable editing.

Step 2
You have the following options:
• Click the Networks tab to add network objects.
Click the URLs tab to add URL objects.

Step 3
Find the available objects that you want to add to the whitelist or blacklist. You have the
following options:

257
 Bootcamp SSFIPS
• Search the available objects by typing the name or value in the Search by
Name or Value field. Clear the search string by clicking Reload or Clear.

• If no existing list or feed meets your needs, dick the Add icon, and choose New
Network List or New URL List.

• If no existing object meets your needs, click the add icon, select New Network
Object or New URL Object

Security Intelligence ignores IP address blocks by using a .0 netmask.

Step 4
Select one or more available objects to add.

Step 5
Optionally, constrain the selected objects by zone by selecting an available zone.
You cannot constrain system-provided Security Intelligence lists by zone.

Step 6
Click Add to Whitelist or Add to Blacklist, or dick and drag the select objects to either list.
To remove an object from a whitelist or blacklist, dick its Delete icon. To remove multiple
objects, select them, right-click and choose Delete Selected.

Step 7
Optionally, set blacklisted objects to monitor-only by right-clicking the object under
Blacklist and then selecting Monitor-only (do not block). You cannot set system-provided
Security Intelligence lists to monitor-only.

Step 8
Choose a DNS policy from the DNS Policy drop-down list.

Associating a custom DNS policy with Security Intelligence restarts the Snort process, which
interrupts traffic inspection when you deploy configuration changes. Whether traffic drops
during this interruption or passes without further inspection depends on the model of the
managed device and how it handles traffic.

Step 9
Click Save.

258
 Bootcamp SSFIPS

Keep in mind that the objects represent either URLs or IPs. The actual number of objects
you use is not important (other than for management purposes). What is important is the
total number of IPs and URLs being written into the blacklist. Remember that the whitelist is
nothing more than the administrative way of removing entries from the blacklist.

For example, the size of the URL database, if it contains 10 million URLs, is approximately
97 M. One thousand URLs would only be 20K. In addition, the average match time URL with
10 million is 1 to 1.5 seconds, whereas with 1.000 entries only, it is .6 seconds. This is not
typically a concern for most environments but must be considered.

259
 Bootcamp SSFIPS

In your access control policy, you have three Security Intelligence logging decision to make,
as shown in the graphic. If Security Intelligence IP. UP.L. or DNS traffic is detected as
indicated by your access control policy, it will generate a Security Intelligence event.

A Security Intelligence event is a connection event that is generated whenever a session is

blacklisted (blocked) or monitored by the reputation-based Security
Intelligence feature.

However, for every Security Intelligence event, there is an identical connection event. You
can view and analyze Security Intelligence events independently. The system also stores
and prunes Security Intelligence events separately.

If you are not logging, no event is generated, regardless of whether that traffic was dropped.

If you choose not to log under a certain category, click the logging icon and deselect logging.
Note that any Firepower versions prior to 6.0 require you to enable logging if you choose to
log the dropped connections or use the Monitor-only setting. In version 6.0, logging became
the default.

260
 Bootcamp SSFIPS

261
 Bootcamp SSFIPS
Lesson Summary

In this lesson, you learned the following:

• The Security Intelligence options include IP-based, UP.L-based, and DNS-based, and
the ability to couple any of these with a security zone.
• To deploy Security Intelligence, you click the Security Intelligence tab in your ACP and
assign the objects that you want to use to either the blacklist or the whitelist.
• The two available actions for Security Intelligence are bloc and monitor.
• Security Intelligence logging is turned on by default in version 6.0 and will create a
connection event and a Security Intelligence event if the appropriate conditions are
matched.

262
 Bootcamp SSFIPS

Module Summary for “Security Intelligence”

In this module, you learned the following:

• Security Intelligence is the Firepower feature that lets you inspect and potentially drop
traffic for known bad IPs. UP.Ls. and DNS prior to entering the ACP portion of the
administrative flow.

• The three Security Intelligence object types are feeds, lists, and global lists.
• When deploying Security Intelligence, you select the appropriate categories and choose
whether the traffic is dropped or only monitored.

263
 Bootcamp SSFIPS

264
 Bootcamp SSFIPS
Module 9: File Control and Advanced Malware Protection

Overview

Description

This module examines the malware and file policy component of the Firepower System,
which allows you to gain visibility into and block potentially unwanted and malicious files
traversing your protected network.

Objectives

Upon completing this module, you will be able to describe the concepts and implementation
procedure of file control and advanced mal ware protection. This ability includes being able
to meet these objectives:

 Describe the concepts of file visibility and control, malware and file policies, and the
recommendations and considerations associated with malware and file policies.

Describe the principles of AMP for Firepower and the advanced options that are
available.

SecureBank Scenario—File Control and Advanced Malware Protection

Requirements

 SecureBank needs to make every effort to ensure known and unknown malicious
files are not traversing the network.

 SecureBank would rather risk blocking a potentially good file rather than letting a
potentially malicious file traverse the network.

 MP3 files must be blocked across the network.

This module will describe the malware and file policy features that can be used to address
the scenario in the graphic.

265
 Bootcamp SSFIPS

You will now learn about the Firepower System's File Control and Malware Protection
component. Recall that in order to inspect files and malware in your network, you need to
specify the "allow' action in an access control policy (ACP) rule specifying a malware and file
policy. You will now learn the fundamentals of this technology and how to set up a malware
and file policy.

266
 Bootcamp SSFIPS
Examining the Malware and File Policy

Description

This lesson examines the malware and file policy in the Firepower System, describing the
architecture of file and malware control, the malware and file policy, and its associated rules.

Objectives

After completing this lesson, you will be able to do the following:

 Identify the principals and architecture of file visibility and control.

 Describe the malware and file policy and its relationship with file rules.

 Describe the file rule configuration options.

 Identify the advanced configuration considerations of malware and file policies.

Current networks are designed to be highly flexible and to promote information sharing and
collaboration between users and entities that must consume the data that a typical
enterprise generates. This flexibility can also be the source of substantial risk if traffic is
allowed to flow freely without some form of monitoring or means of enforcing organizational
usage policies. For example, file sharing can be a convenient way of sharing information, but
it can also be used to leak sensitive information. In addition, the delivery vector for many
types of malware is often through file downloads.

To mitigate these risks. Firepower gives you a means to detect the movement of files in your
networks and to take appropriate action. For example, office documents that are exchanged
between users in internal network segments may be part of normal collaboration between
co-workers, but documents that are sent to outsiders can indicate sensitive data leakage.
With the file detection feature, you can choose to simply be alerted, or you can block the file
and prevent it from leaving the enterprise.

Also, consider that mal ware is often transmitted through downloads of infected files. With
the network-based mal ware detection capability, you can select file types that you want to
monitor over commonly used protocols and send SHA-256 hashes, metadata from the files,
or even copies of the files themselves to the Cisco Collective Security Intelligence Cloud for
analysis. The Cisco cloud returns a disposition of Clean for file hashes that it has detected

267
 Bootcamp SSFIPS
before or if no threats are associated with the file. Conversely, a file is given a disposition of
Mal ware if the checks that are performed in the Cisco cloud indicate that the file is in some
way malicious.

You also have the ability to inspect .zip and .rar encoded compressed files. Files with
multiple levels of compression can also be inspected up to three levels deep. As an added
precaution, you can choose to reject files that are compressed beyond the supported levels
of compression, or compressed files that are encrypted and cannot be inspected any further.

You can also choose which action to take if malware is detected. You can opt to simply be
alerted, or you can block malware that is transmitted over the monitored protocols and
prevent it from reaching its destination.

A malware and file policy is a set of configurations that the system uses to perform AMP for
Firepower and file control, as part of your overall access control configuration. This
association ensures that before the system passes a file in traffic that matches an access
control rule's conditions, it first inspects the file.

The configuration settings that determine the files and the protocols to inspect are
maintained in the malware and file policy. You can access the malware and file policy by
choosing Files from the Policies menu. This takes you to the malware and file policy list
page.

To create a new policy, you can click the New File Policy button in the upper-right portion of
the screen. If you want to modify an existing policy, click the Edit button in the row that lists
the policy.

268
 Bootcamp SSFIPS
File Policy Basics

You can associate a single malware and file policy with an access control rule whose action
is Allow. Interactive Block. or Interactive Block with Reset. The system then uses that
malware and file policy to inspect network traffic that meets the conditions of the access
control rule. By associating different malware and file policies with different access control
rules, you have granular control over how you identify and block files transmitted on your
network. Note, however, that you cannot use a malware and file policy to inspect traffic
handled by the access control default action.

File Policy Rules

A malware and file policy, like its parent access control policy, contains rules that determine
how the system handles files that match the conditions of each rule. You can configure
separate file rules to take different actions for different file types, application protocols, or
directions of transfer.

269
 Bootcamp SSFIPS
When a file matches a rule, the rule perform these actions:

 Allow or block files based on simple file-type matching.


Block files based on disposition.

Store captured files to the device.

 Submit captured files for local malware. Spero. or dynamic analysis

In addition, the malware and file policy can perform other actions:

 Automatically treat a file as if it is dean or as if it is malware, based on entries in the

dean list or the custom detection list.

 Treat a file as if it is malware if the file's threat score exceeds a configurable

threshold.

 Inspect the contents of archive files {such as .zip or .rar).

 Block archive files whose contents are encrypted, are nested beyond a specified
maximum archive depth, or are otherwise uninspectable.

To be effective, a malware and file policy must contain one or more rules. File rules give you
granular control over which file types you want to log. Block, or scan for malware.

Each file rule has an associated action that determines how the system handles traffic that
matches the conditions of the rule. You can set separate rules within a malware and file
policy to take different actions for different file types, application protocols, or directions of
transfer. Simple blocking takes precedence over malware inspection and blocking, which
take precedence over simple detection and logging.

The rule actions are as follows, in rule-action order:

270
 Bootcamp SSFIPS
 Block Files rules allow you to block specific file types. You can configure options to
reset the connection when a file transfer is blocked, and store captured files to the
managed device.

 Block Malware rules allow you to calculate the SHA-256 hash value of specific file
types, query the AMP Cloud to determine if files traversing your network contain
malware, and then block files that represent threats.

 Malware Cloud Lookup rules allow you to obtain and log the disposition of files
traversing your network, while still allowing their transmission.

Detect Files rules allow you to log the detection of specific file types to the database,
while still allowing their transmission.

Depending on the file rule action, you can configure options to reset the connection when a
file transfer is blocked, store captured files to the managed device, locally analyze files for
malware, submit captured files to the AMP Cloud for dynamic and Spero analysis, and store
files that cannot be currently submitted to the cloud for later submission.

Shown in the graphic is a file rule example. This topic explains each available configuration
option.

271
 Bootcamp SSFIPS
The system can detect and inspect files transmitted through FTP. HTTP. SMTP. IMAP.
POPS, and NetBIOS-ssn (SMB). Any. the default option, detects files in HTTP.
SMTP. IMAP. POPS. FTP. and NetBIOS-ssn (SMB) traffic. To improve performance, you
can restrict file detection to only one of those application protocols on a per-file rule basis.

You can inspect incoming FTP. HTTP. IMAP. POPS, and NetBIOS-ssn (SMB) traffic for
downloaded files. You can inspect outgoing FTP. HTTP. SMTP, and NetBIOS-ssn (SMB)
traffic for uploaded files.

Use the Any option to detect files over multiple application protocols, regardless of whether
users are sending or receiving.

A file rule's action determines how the system handles traffic that matches the conditions of
the rule.

Depending on the selected action, you can configure whether the system stores the file or
performs a Spero, local malware, or dynamic analysis on a file. If you select a Block action,
you can also configure whether the system also resets the blocked connection.

File rules are evaluated in rule-action. not numerical, order.

272
 Bootcamp SSFIPS

The system can detect various types of files. These file types are grouped into basic
categories, including multimedia (swf. mp3), executables (exe. torrent), and PDFs.You can
configure file rules that detect individual file types, or on entire categories of file types.

For example, you could block all multimedia files, or only Shockwave Flash (swf) files.
Another option is to configure the system to alert you when a user downloads a BitTorrent
(torrent) file.

Frequently triggered file rules can affect system performance. For example, detecting
multimedia files in HTTP traffic (YouTube, for example, transmits significant Flash content)
could generate an overwhelming number of events.

File Policy Advanced Options

The Advanced tab in the malware and file policy editor has the following general options:

• First Time File Analysis—Submit a file for file analysis that the system detects for the first
time. The file must match a rule configured to perform a malware cloud lookup and
Spero, local malware, or dynamic analysis. If you disable this option, files detected for
the first time are marked with an Unknown disposition.

• Enable Custom Detection List—Block files on the custom detection list.

• Enable Clean List—Allow files on the dean list.

273
 Bootcamp SSFIPS

• Mark files as malware based on dynamic analysis threat score—Set a threshold threat
score; files with scores equal or worse than the threshold are considered malware.

If you select lower threshold values, you increase the number of files treated as malware.
Depending on the adion seleded in your malware and file policy, this can result in an
increase of blocked files.

The Advanced tab in the malware and file policy editor has the following archive file
inspection options:

• Inspect Archives—Allows you to inspect the contents of archive files.

Block Encrypted Archives—Allows you to block archive files that have encrypted contents.

Block Uninspectable Archives—Allows you to block archive files with contents that the
system is unable to inspect for reasons other than encryption; this usually applies to
corrupted files, or those that exceed your specified maximum archive depth.

Max Archive Depth—Allows you to block nested archive files that exceed the specified
depth; the top-level archive file is not considered in this count; depth begins at 1 with the first
nested file.

In a malware and file policy, you can configure advanced options to block files on the custom
detection list, allow files on the dean list, and set a threshold threat score above which files
are considered malware.

You can also configure your malware and file policy to inspect the contents of archive files,
allowing you to analyze and block archive files according to your organization's needs. All
features applicable to uncompressed files (such as dynamic analysis and file storage) are
available for nested files inside archive files.

Archive File Inspection Notes

Some archive files contain additional archive files (and so on). The level at which a file is
nested is its archive file depth. Note that the top-level archive file is not considered in the
depth count; depth begins at 1 with the first nested file.

Although the system can inspect only up to three levels of nested archive files, you can
configure your malware and file policy to block archive files that exceed that depth (or a
lower maximum depth that you specify). If you want to restrict nested archives further, you
have the option to configure a lower maximum file depth of 2 or 1.
If you choose not to block files that exceed the maximum archive file depth of 3, when
archive files that contain some extractable contents and some contents nested at a depth of

274
 Bootcamp SSFIPS
3 or greater appear in monitored traffic, the system examines and reports data only for the
files that it was able to inspect.

If traffic that contains an archive file is blacklisted or whitelisted by Security Intelligence, or if

the top-level archive file's SHA-256 value is on the custom detection list, the system does
not inspect the contents of the archive file. If a nested file is blacklisted, the entire archive is
blocked; however, if a nested file is whitelisted, the archive is not automatically passed
(depending on any other nested files and characteristics).

All file contents of the archive are listed in table form, with a short summary of their relevant
information: name, SHA-256 hash value, type, category, and archive depth, network file
trajectory icon appears next to each file. Click the icon to view further information about that
specific file.

There are best practices and lesser-known behaviors to consider when configuring and
deploying a malware and file policy. Here are the most critical:

 A rule configured to block files in a passive deployment does not block matching files.
Because the connection continues to transmit the file, if you configure the rule to log
the beginning of the connection, you may see multiple events legged for this
connection.

 If a file rule is configured with a Malware Cloud Lookup or Block Malware action and
the Firepower Management Center cannot establish connectivity with the AMP
Cloud, the system cannot perform any configured rule action options until
connectivity is restored.

 Cisco recommends that you enable Reset Connection for the Block Files and Block
Malware actions to prevent blocked application sessions from remaining open until
the TCP connection is reset. If you do not reset connections, the client session will
remain open until the TCP connection resets itself.

275
 Bootcamp SSFIPS
 If you are monitoring high volumes of traffic, do not store all captured files or submit
all captured files for dynamic analysis. Doing so can negatively impact system
performance.

 You cannot perform malware analysis on all file types detected by the system. After
you select values from the Application Protocol. Direction of Transfer, and Action
drop-down lists, the system constrains the list of file types.

File Detection Notes and Limitations

If 3 file matches a rule with an application protocol condition, file event generation occurs
after the system successfully identifies a file's application protocol. Unidentified files do not
generate file events.

FTP transfers commands and data over different channels. In a passive or inline tap mode
deployment, the traffic from an FTP data session and its control session may not be load-
balanced to the same Snort.

If the total number of bytes for all filenames for files in a POP3, POP, SMTP, or IMAP
session exceeds 1024, file events from the session may
not reflect the correct filenames for files that were detected after the filename buffer was
filled.

When transmitting text-based files over SMTP, some mail clients convert newlines to the
CRLF newline character standard. Because Mao-based hosts use the carriage return (CR)
character and Unix-based and Linux-based hosts use the line feed (LF) character, newline
conversion
by the mail client can modify the size of the file. Note that some mail clients default to
newline conversion when processing an unrecognizable file type.

Malware Storage Pack

Based on your file policy configuration, your device may store a substantial amount of file
data to the hard drive. You can install a malware storage pack in the device; the system
stores files to the malware storage pack, allowing more room on the primary hard drive to
store events and configuration files. The system periodically deletes older files. If the
device's primary hard drive does not have enough available space, and does not have an
installed malware storage pack, you cannot store files.

Lesson Summary

In this lesson, you learned the following:

276
 Bootcamp SSFIPS
 File visibility and control within the Firepower System is the capability of detecting
files in traffic and taking actionon these
files.

 File rules are the components of malware and file policies in which you make
decisions about file visibility and control, including whether or not you are blocking
certain files.

 File rules have configuration options, such as the direction of transfer to look for, to
fine-tune your file inspection.

 The malware and file policy's advanced settings allow you to choose global settings
for your file rules.

Examining Advanced Malware Protection

Description

This lesson examines the principles and architecture of AMP for Firepower, including file
dispositions, advanced options for detection, and AMP for Endpoints integration.

Objectives

After completing this lesson, you will be able to do the following:

• Identify the principles of AMP for Firepower.

• Describe file dispositions and how they are established and updated.

• Describe the AMP for Firepower architecture.

• Describe the AMP for Firepower advanced options.

• Describe AMP integration options

277
 Bootcamp SSFIPS
The graphic shows the four malware and file policy actions that are available. In this lesson,
you will be learning about the two specific malware options by using what is referred to as
Advanced Malware Protection (AMP) for Firepower.

To enable malware inspection in your enterprise, you have two options: Block the malware
that you see before the files end up on your host, or simply gain visibility into what malicious
traffic is traversing your network.

There are many factors to consider when looking at malware inspection capabilities in
Firepower. You will want to factor in performance and licensing considerations first.

AMP for Firepower allows you to detect, store, track, analyze, and block malware on your
network by using managed devices that are deployed inline. AMP for Firepower can block
many types of malware files, including PDFs and Microsoft Office documents.

File Dispositions

278
 Bootcamp SSFIPS

The Cisco Collective Security Intelligence Cloud continuously processes file samples that
are received from various sources. It runs the samples through a series of checks to
determine which disposition should be assigned to the files that it has detected. Cisco
customers who deploy Advanced Malware Protection (AMP) on their managed devices use
the intelligence gathered by the cloud to check on the disposition of the files that they find
are traversing monitored network segments.

Managed devices performing hash-based malware detection do not send files to the cloud.
Rather, they send SHA-256 hashes of files. Thus, no customer data is sent during this
process and the resources required for performing network-based malware detection are
reduced, because the actual work of analyzing files is performed in the cloud.

The system determines file dispositions based on the disposition returned by the AMP
Cloud. To improve performance, if the system already knows the disposition for a file based
on its SHA-256 value, the Firepower Management Center uses the cached disposition rather
than queries the AMP Cloud. Based on its disposition, the system can block the file. If any
nested file inside an archive file is blocked, the system blocks the entire archive file.

A file can have one of the following file dispositions as a result of addition to a file list, or due
to a threat score:

 Malware indicates that the AMP Cloud has categorized the file as malware, local
malware analysis has identified malware, or the file's threat score has exceeded the
malware threshold defined in the malware and file policy.
 “Clean” indicates that the AMP Cloud has categorized the file as dean, or that a user
has added the file to the clean list.

 “Unknown” indicates that the system queried the AMP Cloud, but the file has not
been assigned a disposition; in other words, the AMP Cloud has not categorized the
file.

 “Custom Detection” indicates that a user has added the file to the custom detection
list.

 “Unavailable" indicates that the system could not query the AMP Cloud. You may see
a small percentage of events with this disposition; this is expected behavior.

Archive files have dispositions based on the dispositions assigned to the files inside the
archive. All archives that contain identified malware files receive a disposition of Malware.

279
 Bootcamp SSFIPS
Archives without identified malware files receive a disposition of Unknown if they contain any
unknown files, and a disposition of Clean if they contain only dean files.

Dispositions returned from an AMP Cloud query, associated threat scores, and dispositions
assigned by local malware analysis have a time-to-live (TTL) value. After a disposition has
been held for the duration specified in the TTL value without an update, the system purges
the cached information. Dispositions and associated threat scores have the following TTL
values:

 Clean—4 hours

 Unknown—1 hour

 Malware—1 hour

If 3 query against the cache identifies a cached disposition that has timed out, the system
requeries the AMP Cloud for a new disposition.

The AMP Cloud is Cisco's central point of intelligence and research for files. When SHA-256
values are sent to the cloud infrastructure, they are compared with the AMP Cloud database.
The AMP Cloud is updated in real time, and any threats detected anywhere in the world
where Cisco has visibility are detected here in the AMP Cloud.

If a threat is detected by the AMP Cloud, and your network queries the cloud for a file
disposition, your network will get immediate protection from these threats.

All dispositions are maintained and updated in the AMP Cloud.

280
 Bootcamp SSFIPS

Retrospective Visibility and Events

For malware detected in network traffic, dispositions can change. For example, the AMP
Cloud can determine that a file that was previously thought to be clean is now identified as
malware, or the reverse—that a malware-identified file is actually dean. When the disposition
changes for a file you queried in the last week, the AMP Cloud notifies the system. Then two
actions occur:

• The Firepower Management Center generates a new retrospective malware event.

This new retrospective malware event represents a disposition change for all files detected
in the last week that have the same SHA-256 hash value. For that reason, these events
contain limited information: the date and time the Firepower Management Center was
notified of the disposition change, the new disposition, the SHA-256 hash value of the file,
and the threat name. They do not contain IP addresses or other contextual information.

• The Firepower Management Center changes the file disposition for previously detected
files with the retrospective event's associated SHA-256 hash value.

If 3 file's disposition changes to Malware, the Firepower Management Center logs a

new malware event to its database. Except for the new disposition, the information in
this new malware event is identical to that in the file event generated when the file
was initially detected.

If 3 file's disposition changes to Clean, the Firepower Management Center does not delete
the malware event. Instead, the event reflects the change indisposition. As a result, files with
dean dispositions can appear in the malware table, but only if they were originally thought to
be malware. Files that were never identified as malware appear only in the files table.

281
 Bootcamp SSFIPS

Upon installation of the Malware license, the Firepower Manager communicates to the cloud
service over TCP port 443 or 32137. This is an outbound connection from the Firepower
Management Center to the Cisco Collective Security Intelligence cloud.

Important Network-Based Malware Detection Concepts

With respect to network-based malware detection, there are a few important points to
remember:

 Network-based malware detection occurs on files that are traversing the network.
This is an important distinction, because it is different to endpoint malware detection,
which is the more traditional type of detection, in which endpoints (hosts) run
detection software locally.

 With network-based detection, the managed device detects a file in a data stream
and calculates a SHA-256 hash for the file. The hash is sent to the Cisco cloud for a
check of its disposition. The cloud gets intelligence from the millions of files that it
detects throughout the community of endpoint agents that regularly report to it. When
the checks for each file are complete, a disposition for the file (Clean or Malware) is
associated with the file hash. When a managed device sends a file hash, the
associated disposition is sent back to the managed device and is reported as an
event in the user interface.
 If a file hash that has never been detected by the cloud is sent, a disposition of
Unknown is returned.

 For malware blocking, a variation of the process just outlined is used. As a file is
detected in a data stream, the managed device extracts the file from the data stream
and delivers the packets that contain the pieces of the file to the destination.
However, when the last piece of the file is received, the managed device keeps it.
With the entire file now on the managed device, it can calculate the SHA-256 hash
for the file and send it to the cloud for a check of its disposition. If the disposition
returned is Clean, the last piece of the file is released by the managed device and
allowed to go to its destination. If the disposition is Malware, the last piece is dropped
and the endpoint for which it was destined never receives it. Thus, the malicious file
is neutralized on the endpoint because it is incomplete and cannot be executed.

282
 Bootcamp SSFIPS

For unknown files, which are typically a large percentage of networks, you can enable
advanced options, and also rely on the AMP Cloud to keep up-to-date with unknown files,
based on new up-to-the-minute information that the cloud receives and analyzes.

File Detection and Storage

When a device detects an eligible file, it sends the file's SHA-256 hash value to the
Firepower Management Center. The Firepower Management Center performs a malware
cloud lookup, querying the AMP Cloud for the file's disposition. The device can also store an
eligible file to its hard drive or malware storage pack by using the file storage feature. You
can view captured file information in the event viewer, and download a copy for offline
analysis.

The system applies several methods of file inspection and analysis to determine whether a
file contains malware.

283
 Bootcamp SSFIPS

Based on whether you enable the option in a file rule, the system inspects files in the
following order:

 Spero Analysis—If the file is an eligible executable file, the device can analyze the
file's structure and submit the resulting Spero signature to the AMP Cloud. The cloud
uses this signature to determine if the file contains malware.

 Local Malware Analysis—Using a local malware inspection engine, the device

examines an eligible file, blocks it if the file contains malware and the file rule
configured to do so, and generates malware events. The device also generates a file
composition report detailing a file's properties, embedded objects, and possible
malware

 Dynamic Analysis—If the device preclassifies files as possible malware, it submits

these files to the AMP Threat Grid cloud or to an AMP Threat Grid on-premises
appliance for dynamic analysis, regardless of whether the device stores the file. The
AMP Threat Grid cloud or on-premises AMP Threat Grid appliance runs the file in a
sandbox environment to determine whether the file is malicious, and returns a threat
score that describes the likelihood that the file contains malware. From the threat
score, you can view a dynamic analysis summary report that details why the cloud
assigned the threat score.
.

You can configure your malware and file policy to automatically submit a file preclassified as
malware for dynamic analysis. To supplement dynamic analysis, you can automatically
submit queried files for Spero analysis. Spero analysis supplements analysis of SHA-256
hash values, allowing for more complete identification of malware in executable files.

Spero analysis involves examining file structural characteristics such as metadata and
header information.

284
 Bootcamp SSFIPS
After generating a Spero signature based on this information, the device submits it to the
Spero heuristic engine in the AMP Cloud. Based on the Spero signature, the Spero engine
determines whether the file is malware.

If the file also currently has an Unknown file disposition, the system assigns a Malware file
disposition.

Local malware analysis allows a managed device to locally inspect executables. PDFs,
office documents, and other types of files for the most common types of malware, using a
detection rule set provided by the Cisco Talos Security Intelligence and P.esearch Group
(Talos). Because it does not require submitting a file to the AMP Cloud and does not run the
file, local malware analysis saves time and system resources.

If the system identifies malware through local malware analysis, it updates the existing file
disposition from Unknown to Malware. The system then generates a new malware event. If
the system does not identify malware, it does not update the file disposition from Unknown to
Clean. After the system runs a local malware analysis, it caches file information such as
SHA-256 hash value, time stamp, and disposition, so that, if the file is detected again within
a certain period of time, the system can identify malware without additional analysis.

From the event viewer, you can manually submit for local malware analysis one file at a time
by using the context menu, or up to 25 captured files at a time. The system runs a local
analysis and then submits these files to the cloud for dynamic analysis.

Local malware analysis does not require establishing communications with the AMP Threat
Grid cloud. However, you must configure communications with the cloud to submit files
preclassified as malware for dynamic analysis, and to download updates to the local
malware analysis rule set.

File Composition

If you configure local malware analysis or dynamic analysis, the system generates a file
composition report after analyzing a file. This report allows you to further analyze files and
determine whether they may carry embedded malware.

285
 Bootcamp SSFIPS
The file composition report lists file properties, any objects embedded in the file, and any
detected viruses.

The file composition report may also list additional information specific to that file type. When
the system prunes stored files, it also prunes the associated file composition report.

If you want to improve the accuracy of the AMP Cloud and provide additional malware
analysis and threat identification, you can submit eligible captured files to the AMP Threat
Grid cloud or an on-premises AMP Threat Grid appliance for dynamic analysis. The AMP
Cloud runs files in a sandbox environment to determine if a file contains malware.

Whether you can submit a file for dynamic analysis depends on the following:

• File type

• File size

• File rule's action

• System's preclassification of a file as malware for automatic submission

If 3 rule is configured to block files or to perform a malware cloud lookup, the system submits
only matching files with an Unknown or Unavailable disposition.

The AMP Threat Grid cloud queues files for dynamic analysis, running each file in a sandbox
environment. The cloud returns a threat score, which details the likelihood that a file contains
malware. You can automatically block files whose threat score falls above a defined
threshold.

From the event viewer, captured files view, or a network file trajectory, you can determine
whether a file has been submitted for dynamic analysis. You can also manually submit a file
for local malware and dynamic analysis, or view a summary of why the cloud assigned a
certain threat score. In addition, you can retrieve a dynamic analysis summary report, which
describes the various ratings that make up the overall threat score, as well as other
processes started when the cloud attempted to run the file.

286
 Bootcamp SSFIPS
Manual Dynamic Analysis

You can manually submit a stored file for dynamic analysis from the event viewer, context
menu, or network file trajectory. From the captured files view, you can manually submit up to
25 stored files at once.

In addition to executable files, you can also submit file types that are not eligible for
automatic submission, such as .swf, .jar, and others. This action allows you to more quickly
analyze a broad range of files, regardless of disposition, and to pinpoint the exact causes of
an incident.

AMP Integration

AMP for Endpoints is Cisco's enterprise-class Advanced Malware Protection (AMP) solution
that discovers, interprets, and blocks advanced malware outbreaks, advanced persistent
threats, and targeted attacks.

If your organization uses AMP for Endpoints, individual users install lightweight connectors
on endpoints: computers and mobile devices. Connectors can inspect files upon upload,
download, execution, open, copy, move, and so on. These connectors communicate with the
AMP Cloud to determine if inspected files contain malware.

When a file is positively identified as malware, the AMP Cloud sends the threat identification
to the Firepower Management Center, The AMP Cloud can also send other kinds of
information to the Firepower Management Center, including data on scans, quarantines,
blocked executions, and cloud recalls. The Firepower Management Center logs this
information as malware events.

AMP for Endpoints can generate an indication of compromise (IOC) when a host's security
may be compromised. The Firepower System can display this IOC information for its
monitored hosts. Cisco occasionally develops new IOC types for endpoint-based malware
events, which the system automatically downloads. With AMP for Endpoints, you can
configure not only Management Center-initiated remediations and alerts based on malware
events, but you can also use the AMP for Endpoints management console to help you
mitigate the effect of malware. The management console provides a robust, flexible web
interface where you control all aspects of your AMP for Endpoints deployment and manage
all phases of an outbreak. You can do the following:

287
 Bootcamp SSFIPS
 Configure custom malware detection policies and profiles for your entire organization,
as well as perform flash and full scans on all your users' files.

 Perform malware analysis, including view heat maps, detailed file information,
network file trajectory, and threat root causes.

 Configure multiple aspects of outbreak control, including automatic quarantines,

application blocking to stop nonquarantined executables from running, and exclusion
lists.

 Create custom protections, block execution of certain applications based on group

policy, and create custom whitelists.

You can use the Firepower System to work with data from both AMP for Firepower and AMP
for Endpoints. Because AMP for Endpoints malware detection is performed at the endpoint
at download or execution time, while managed devices detect malware in network traffic, the
information in the two types of malware events is different. For example, endpoint-based
malware events contain information about the file path, invoking client application, and so
on, while malware detections in network traffic contain port, application protocol, and
originating IP address information about the connection used for transmitting the file.

As another example, for network-based malware events, user information represents the
user who most recently logged in to the host where the malware was destined, as
determined by network discovery. However, AMP for Endpoints-reported users represent the
user currently legged in to the endpoint where the malware was detected.

288
 Bootcamp SSFIPS
Lesson Summary

In this lesson, you learned the following:

• AMP for Firepower utilizes the malware and file policy to perform malicious-file inspection
and potential blocking on files traversing the managed device.

• File dispositions are assigned to every file that is inspected for malware. These dispositions
can change over time.

• There is an order of operations for detecting malicious files in the Firepower System that
includes checking both the managed device's and the Firepower Management Center's
cache before sending the file SHA-256 hash to the AMP Cloud for a disposition check.

• Advanced options include the capability to also enable file metadata visibility, file
sandboxing, local malware analysis, and integration with AMP for Endpoints.

• AMP for Endpoints, the AMP product available for endpoints in an organization, can be
integrated into the Firepower System allowing event data to augment the existing host
profiles.

289
 Bootcamp SSFIPS
SecureBank Scenario-File Control and Advanced Malware Protection

The graphic shows the solutions to the requirements outlined for SecureBank at the
beginning of this module.

290
 Bootcamp SSFIPS
Module Summary for “File Control and Advanced Malware Protection”

In this module, you learned the following:

• Malware and file policy and its associated rules enables you to inspect and block both for
file types, and for Malware.

• Malware detection checks detected files for malware, based on the SHA, with advanced
options that allow you to look deeper into previously undetected files.

291
 Bootcamp SSFIPS
Knowledge Check

Q1) Malware Cloud Lookup is the file action that allows you to block files that have been
identified as malicious. (Source: Examining Malware and File Policy)

Q2) Spero analysis is an advanced option for disposition checking that involves sending the
file to be sandboxed in the AMP Cloud. {Source: Examining Advanced Malware Protection)

292
 Bootcamp SSFIPS
Module 10: Next-Generation Intrusion Prevention Systems

Overview

Description

This module describes intrusion policies in the Firepower System, what these policies
manage, how they are created and maintained, and usage best practices.

Objectives
Upon completing this module, you will be able to implement and manage intrusion policies.
This ability includes being able to meet these objectives:

• Describe the Snort rule components, who manages Snort rules, and how these rules are
used in the Firepower System.
• Describe how variables and variable sets are used with intrusion policies.

• Describe intrusion policies and how base policies work with policy layers.

• Explain how to create a new intrusion policy and describe the configuration options.

• Describe how to manage intrusion policies by identifying the rule states, options, and
automated features.

293
 Bootcamp SSFIPS

The intrusion prevention and detection features of the Firepower System that are described
in this module can be used to address the scenario described in the graphic.

You will now examine your intrusion policy in detail. This is also known as the detection
engine, or rules engine. This is where the Snort rules are managed and processed. This
component of your Firepower System is best known as the IPS section.

294
 Bootcamp SSFIPS

Examining Intrusion Prevention and Snort Rules

Description

This lesson introduces how intrusion prevention in the Firepower System is performed
through the use of Snort. Snort rules, and variables.

Objectives

After completing this lesson, you will be able to do the following:

• Identify the principles of Firepower intrusion detection and prevention and their relationship
with Snort rules.

• Describe Snort and how it is used in the Firepower System.

• Describe the Talos group and its role in Firepower administration.

Your intrusion prevention's primary function is to look for potentially malicious traffic
traversing the managed device.

Snort is free, open-source software that acts as a network intrusion detection system.
Firepower technology is based on this software. An intrusion rule, also known as a Snort
rule, is a specified set of keywords and arguments that the system uses to detect attempts to
exploit vulnerabilities in your network. As the system analyzes network traffic, it compares

295
 Bootcamp SSFIPS
packets against the conditions specified in each rule, and triggers the rule if the data packet
meets all the conditions specified in the rule.

An intrusion policy contains the following:

• Intrusion rules, which are subdivided into shared object rules and standard text rules.

• Preprocessor rules, which are associated with a detection option of the packet decoder or
with one of the preprocessors included with the Firepower System.

These rules are the core components of the intrusion policy and of Snort.

For more information, visit www.snort.org.

The graphic shows an example of a Snort (Intrusion) rule. You will see these in your events,
so it is best to become familiar with these rules and how they are written.

Snort rules can be created by anyone. Snort is a free, open-source system. You have the
option to create your own Snort rules and import them into the Firepower Management
Center. It is not advisable to experiment with Snort rules without testing them, because
uploading Snort rules into the Firepower Management Center and applying them to an active
intrusion policy can cause performance or detection issues if those rules are not written
correctly.

296
 Bootcamp SSFIPS

Not all customers use custom rules, but some organizations have unique traffic and custom
applications in their environment and therefore must write custom rules.

All available Snort rules are stored in the Firepower Management Centers database. Rule
updates are required for keeping rules up-to-date. These rules are available for use in your
intrusion policies.

The Firepower System works with Cisco Talos. Talos is your "security front" that ensures
that new and upcoming threats are addressed. You as the administrator also have a part in
this process. You need to both decide how you want to utilize the rules that Talos supplies
you. and update the system when those rules become available.

297
 Bootcamp SSFIPS
Because Talos is the security front that you depend on for protecting your network and
managing the Snort rules, it is advisable to regularly visit their various resources on the
Internet. The graphic lists the various links to the Talos online resources.

298
 Bootcamp SSFIPS

Lesson Summary

In this lesson, you learned the following:

• Intrusion detection and prevention in the Firepower System is performed by Snort, which
comprises the network analysis policy and the intrusion policy.

• Snort rules are how Snort analyzes the traffic in the Firepower System for potentially
malicious behavior.

• Talos is the primary component of the Collective Security Intelligence ecosystem in Cisco,
and is the team that writes and manages Snort rules.

299
 Bootcamp SSFIPS
Examining Variables and Variable Sets

Description

This lesson introduces the variables used in the Firepower System, and how to define and
manage them to match the associated intrusion policy.

Objectives

After completing this lesson, you will be able to do the following:

• Describe the role and types of variable.

• Describe the role of variable sets.

• Define variable values.

• Describe how variable sets are associated with intrusion policies.

Variables are what specify the traffic the enabled rules run against. Variables are used in the
rule header to identify traffic conditions.

Variables represent values commonly used in intrusion rules to identify source and
destination IP addresses and ports. You can also use variables in intrusion policies to
represent IP addresses in rule suppressions, adaptive profiles, and dynamic rule states.

The use of variables allows you to select a group of objects by using a single variable. Also,
you can update the variables without the need to revisit each rule.

300
 Bootcamp SSFIPS

Network variables represent IP addresses that you can use in intrusion rules that you enable
in an intrusion policy and in intrusion policy rule suppressions, dynamic rule states, and
adaptive profiles. Network variables differ from network objects and network object groups in
that network variables are specific to intrusion policies and intrusion rules, whereas you can
use network objects and groups to represent IP addresses in various places in the system's
web interface. These places include access control policies, network variables, intrusion
rules, network discovery rules, event searches, reports, and so on.

You can use network variables in the following configurations to specify the IP addresses of
hosts on your network:

 Intrusion Rules—Intrusion rule Source IPs and Destination IPs header fields allow
you to restrict packet inspection to the packets originating from or destined to specific
IP addresses.

 Suppressions—The Network field in source or destination intrusion rule

suppressions allows you to suppress intrusion event notifications when a specific IP
address or range of IP addresses triggers an intrusion rule or preprocessor.

 Dynamic Rule States—The Network field in a source or destination dynamic rule

states allows you to detect when too many matches for an intrusion rule or
preprocessor rule occur in a given time period.

 Adaptive Profiles—The adaptive profiles Networks field identifies hosts in the

network map where you want to improve reassembly of packet fragments and TCP
streams in passive deployments.

When you use variables in the fields identified in this section, the variable set that you link to
an intrusion policy determines the variable values in the network traffic handled by an access
control policy that uses the intrusion policy.

You can add to a variable any combination of the following network configurations:

• Any combination of network variables, network objects, and network object groups that you
select from the list of available networks.

• You can list multiple literal IP addresses and address blocks by adding them individually.
You can list IPv4 and IPv6 addresses and address Blocks alone or in any combination.

301
 Bootcamp SSFIPS
When specifying IPv6 addresses, you can use any addressing convention defined in RFC
4291.

The default value for included networks in any variable that you add is the word Any, which
indicates any IPv4 or IPv6 address. The default value for excluded networks is None, which
indicates no network. You can also specify the address in a literal value to indicate any IPv6
address in the list of included networks, or no IPv6 addresses in the list of exclusions.

Adding networks to the excluded list negates the specified addresses and address blocks.
That is. you can match any IP address with the exception of the excluded IP address or
address blocks.

For example, excluding the literal address 192.168.1.1 specifies any IP address other than
192.168.1.1, and excluding 2001 :db8:ca2e::fa4c specifies any IP address other than
2001:db8:ca2e::fa4c.

You can exclude any combination of networks by using literal or available networks. For
example, excluding the literal values 192.168.1.1 and 192.168.1.5 includes any IP address
other than 192.168.1.1 or 192.168.1.5. That is, the system interprets this as "not 192.168.1.1
and not 192.168.1.5." which matches any IP address other than those listed between
brackets.

Note the following points when adding or editing network variables:

• You cannot logically exclude the value Any, which, if excluded, would indicate no address.
For example, you cannot add a variable with the value Any to the list of excluded
networks.

• Network variables identify traffic for the specified intrusion rule and intrusion policy
features. Note that preprocessor rules can trigger events regardless of the hosts defined
by network variables used in intrusion rules.
• Excluded values must resolve to a subset of included values. For example, you cannot
include the address block 192.168.5.0/24 and exclude 192.168.6.0/24.

Port Variables

Port variables represent TCP and UDP ports that you can use in the Source Port and
Destination Port header fields in intrusion rules that you enable in an intrusion policy. Port
variables differ from port objects and port object groups in that port variables are specific to
intrusion rules. You can create port objects for protocols other than TCP and UDP, and you
can use port objects in various places in the system's web interface, including port variables,
access control policies, network discovery rules, and event searches.

You can use port variables in the intrusion rule Source Port and Destination Port header
fields to restrict packet inspection to packets originating from or destined to specific TCP or
UDP ports.

When you use variables in these fields, the variable set that you link to the intrusion policy
associated with an access control rule or policy determines the values for those variables in
the network traffic where you deploy the access control policy.

302
 Bootcamp SSFIPS

You use variable sets to manage, customize, and group your variables. You can use the
default variable set provided by the system or create your own custom sets. Within any set,
you can modify predefined default variables and add and modify user-defined variables.

Adding a variable to any set adds it to all sets; that is, each variable set is a collection of all
variables currently configured on your system. Within any variable set, you can add user-
defined variables and customize the value of any variable.

Most of the shared object rules and standard text rules that the Firepower System provides
use predefined default variables to define networks and port numbers. For example, the
majority of the rules use the variable SHOME_NET to specify the protected network and the
variable SEXTERNAL_NET to specify the unprotected (or outside) network. In addition,
specialized rules often use other predefined variables. For example, rules that detect
exploits against web servers use the SHTTP_SERVERS and SHTTP PORTS variables.

By default, the Firepower System provides a single default variable set, which
comprises predefined default variables. The Cisco Talos Security Intelligence and
Research Group (Talos) uses rule updates to provide new and updated intrusion
rules and other intrusion policy elements, including default variables. On a newly
installed system, the default variable set comprises only the default variables
predefined by Cisco.

Because many intrusion rules provided by the system use predefined default variables, you
should set appropriate values for these variables. Depending on how you use variable sets

303
 Bootcamp SSFIPS
to identify traffic on your network, you can modify the values for these default variables in
any or all variable sets.

In a multidomain deployment, the system generates a default variable set for each
subdomain.

When you modify a custom variable set used by an intrusion policy in an access control
policy, the system reflects the status for that policy as out-of-date on the Access Control
Policy page. You must redeploy the access control policy to implement changes in your
variable set. When you modify the default set. the system reflects the status of all access
control policies that use intrusion policies as out-of-date, and you must redeploy all access
control policies to implement your changes.

By default, the Firepower System links the default variable set to all intrusion policies used in
an access control policy. When you deploy an access control policy that uses an intrusion
policy, intrusion rules that you have enabled in the intrusion policy use the variable values in
the linked variable set.

Variable sets allow you to define different variable values for different variables within
different sets. You can, for example, define SHOME_NET with a 10.x IP range in Variable
Set X and define SHOME_NET with a 192.168.x range in another. This allows you to tune
your traffic, increasing performance and potentially reducing false positives. You can use
different variable sets in different ACP rules and yet send all the traffic to the same intrusion
policy.

Rules are more effective when variables more accurately reflect your network environment.
At a minimum, you should modify default variables in the default set. By ensuring that a
variable such as SHOME_NET correctly defines your network and SHTTP_SERVERS

304
 Bootcamp SSFIPS
includes all web servers on your network, processing is optimized and all relevant systems
are monitored for suspicious activity.

To use your variables, you link variable sets to intrusion policies associated with access
control rules or with the default action of an access control policy. By default, the default
variable set is linked to all intrusion policies used by access control policies.

Variables belong to one of the following categories:

 Default variables—Variables provided by the Firepower System. You cannot

rename or delete a default variable, and you cannot change its default value.
However, you can create a customized version of a default variable.

 Customized variables—Variables that you create, such as the following:

 Customized default variables—When you edit the value for a default

variable, the system moves the variable from the Default Variables area to the
Customized Variables area. Because variable values in the default set
determine the default values of variables in custom sets, customizing a
default variable in the default set modifies the default value of the variable in
all other sets.

 User-defined variables—You can add and delete your own variables,

customize their values within different variable sets, and reset customized
variables to their default values. When you reset a user-defined variable, it
remains in the Customized Variables area.

User-defined variables can be one of the following types:

 Network variables specify the IP addresses of hosts in your network traffic.

305
 Bootcamp SSFIPS
 Port variables specify TCP or UDP ports in network traffic, including the value any for
either type.

For example, if you create custom standard text rules, you might also want to add your own
user-defined variables to more accurately reflect your traffic, or as shortcuts to simplify the
rule creation process.

Alternatively, if you create a rule that you want to inspect traffic in the "demilitarized zone" (or
DMZ) only, you can create a variable named SDMZ whose value lists the server IP
addresses that are exposed.

You can then use the SDMZ variable in any rule written for this zone.

Advanced Variables—Variables provided by the Firepower System under specific

conditions. These variables have a very limited deployment.

You must correctly define your variables in your Firepower System. Remember that Snort
rules use these variables to determine which rules are run against what traffic. If networks
are missing in the variables but exist in your environment, the rules in place will not be run.
There is no warning for this mistake. It is up to you as the administrator of your enterprise to
correctly assign these variables.

The traffic flow is from an ACP rule to the intrusion policy. In the ACP rule, you specify which
variable set to use. You can also do this in the default action if the default action sends traffic
to an intrusion policy.

306
 Bootcamp SSFIPS

When you choose Variable Set on the Object Management page, the object manager lists
the default variable set and any custom sets that you created. To add a new variable set,
click Add Variable Set.

Name the new variable set and define any custom variables that you require. After it is
created, you can use this variable set in an ACP rule or in the Default Action of the ACP.

307
 Bootcamp SSFIPS
To use your variables, you link variable sets to intrusion policies associated with access
control rules or with the default action of an access control policy. By default, the default
variable set is linked to all intrusion policies used by access control policies.

Welcome to the Intrusion Policy Variable Set Simulation

The execution of the Demo will be guided by the trainer

Complete the activity to perform the task in the graphic. The simulation will provide prompts
to assist you.
Complete the following steps:

Complete the activity to perform the task in the graphic. The simulation will provide
prompts to assist you.

Complete the following steps:

Step 1
Navigate to the Access Control Policies list and edit the "base policy."

Step 2
Create a new rule, accept all defaults and navigate to the Inspection tab. (Note
that the policy rule has been named for you in this simulation.

Step 3
Select the Security Over Connectivity intrusion policy.

Step 4
Select the variable set Variable_Set_1.

Step 5
Save the Rule.

Step 6

308
 Bootcamp SSFIPS
Save the access control policy. (Note that for theses policy changes to take effect
the policy would need to be redeployed.)

309
 Bootcamp SSFIPS

Lesson Summary

In this lesson, you learned the following:

 Variables are used in Snort rule headers to identify traffic to be inspected by

associated Snort rules.

 Variable sets are a collection of variables to be tied to an intrusion policy and

are managed in the Objects section of the Firepower Management Center.

 The value of the variables within a variable set can be modified.

 To define a variable set, you add a new set, assign the appropriate variables
to that set, and then associate that set to the ACP rule or to the Default Action
of the ACP, or to both.

310
 Bootcamp SSFIPS

Examining Intrusion Policies

Description

This lesson will show you how intrusion policies manage the intrusion prevention
components, and how you can use base policies and layers to manage and fine-tune your
Firepower System.

Objectives

After completing this lesson, you will be able to do the following:

Identify intrusion policies in the Firepower System and the responsibilities of the Talos group
and the system administrator.

 Describe the components of an intrusion policy.

 Describe the base intrusion policies used in the Firepower System.

 Describe how policy layers are used in intrusion policies.

 Describe the behavior of multiple layers and the use of shared policy layers.

311
 Bootcamp SSFIPS

Intrusion policies are defined sets of intrusion detection and prevention configurations that
inspect traffic for security violations and, in inline deployments, can block or alter malicious
traffic. Intrusion policies are invoked by your access control policy and are the system's last
line of defense before traffic is allowed to proceed to its destination.

At the core of each intrusion policy are the intrusion rules. An enabled rule causes the
system to generate intrusion events for {and optionally block) traffic matching the rule.
Disabling a rule stops the processing of the rule.

The Firepower System delivers several base intrusion policies, which enable you to take
advantage of the experience of the Cisco Talos Security Intelligence and Research Group
(Talos). For these policies. Talos sets intrusion and preprocessor rule states {enabled or
disabled), as well as provides the initial configurations for other advanced settings.

Intrusion and network analysis policies are required for intrusion detection and prevention,
but the intrusion policy is typically what you will manage and configure. In fact, few
administrators will spend much, if any, time configuring network analysis policies.

Network analysis and intrusion policies work together as part of the Firepower System's
intrusion detection and prevention feature. The term intrusion detection generally refers to
the process of passively analyzing network traffic for potential intrusions and storing attack

312
 Bootcamp SSFIPS
data for security analysis. The term intrusion prevention includes the concept of intrusion
detection, but adds the ability to block or alter malicious traffic as it travels across your
network.

In an intrusion prevention deployment, when the system examines packets, the following
occurs:

 A network analysis policy governs how traffic is decoded and preprocessed so that it
can be further evaluated, especially for anomalous traffic that might signal an
intrusion attempt.

 An intrusion policy uses intrusion and preprocessor rules (sometimes referred to

collectively as intrusion rules) to examine the decoded packets for attacks based on
patterns. Intrusion policies are paired with variable sets, which allow you to use
named values to accurately reflect your network environment.

Both network analysis and intrusion policies are invoked by a parent access control policy,
but at different times. As the system analyzes traffic, the network analysis (decoding and
preprocessing) phase occurs before, and separately from, the intrusion prevention
(additional preprocessing and intrusion rules) phase. Together, network analysis and
intrusion policies provide broad and deep packet inspection. They can help you detect, alert
on, and protect against network traffic that could threaten the availability, integrity, and
confidentiality of hosts and their data.

The Firepower System is delivered with several similarly named network analysis and
intrusion policies (for example. Balanced Security and Connectivity) that complement and
work with each other. By using system-provided policies, you can take advantage of the
experience of the Cisco Talos Security Intelligence and Research Group (Talos). For these
policies. Talos sets intrusion and preprocessor rule states, as well as provides the initial
configurations for preprocessors and other advanced settings.

You can also create custom network analysis and intrusion policies. You can tune the
settings in custom policies to inspect traffic in the way that matters most to you. So that you
can improve both the performance of your managed devices and your ability to respond
effectively to the events that they generate.

You create, edit, save, and manage network analysis and intrusion policies by using similar
policy editors in the web interface. When you are editing either type of policy, a navigation
panel appears on the left side of the web interface; the right side displays various
configuration pages.

313
 Bootcamp SSFIPS

Traffic enters the intrusion policy only after it has passed through Security Intelligence and
your access control policy. When you assign an Allow rule in the access control policy that
identifies traffic, you can send that traffic to your intrusion policy. You can also send traffic to
the intrusion policy from the Default Action of your access control policy.

Intrusion policies contain available Snort rules. To manage these rules, they also contain
base policies, policy layers, and Firepower recommendations. These topics are discussed
later in this module.

314
 Bootcamp SSFIPS
Intrusion policies require ongoing administration. Cisco Talos manages the available Snort
rules and decides which rule states are assigned to each rule according to the base policy.
As the administrator of the system, you will need to update these rules regularly, run
Firepower recommendations (if they are being used), tune rules, and redeploy policies after
any changes are made.

Cisco delivers several pairs of network analysis and intrusion policies with the Firepower
System. By using system-provided network analysis and intrusion policies, you can take
advantage of the experience of the Cisco Talos Security Intelligence and Research Group
(Talos). You can use system-provided policies as they are, or you can use them as the base
for custom policies.

As new vulnerabilities become known. Talos releases intrusion rule updates. These rule
updates can modify any system-provided network analysis or intrusion policy, and can
provide new and updated intrusion rules and preprocessor rules, modified states for existing
rules, and modified default policy settings. Rule updates may also delete rules from system-
provided policies and provide new rule categories, as well as modify the default variable set.

If a rule update affects your deployment, the web interface marks affected intrusion and
network analysis policies as out of date, as well as their parent access control policies. You
must redeploy an updated policy for its changes to take effect.

When you use these base policies, and perform regular updates, you are bringing into your
environment the skill and experience that Talos brings to security.

The remainder of this topic discusses the base policy options.

315
 Bootcamp SSFIPS

Security Over Connectivity policies are built for organizations where network infrastructure
security takes precedence over user convenience. The intrusion policy enables numerous
network anomaly intrusion rules that could alert on or drop legitimate traffic.

Security Over Connectivity policies are where you send your most important traffic, to protect
it from malicious traffic. This policy will err on the side of No in response to potential threats.
Typically, this policy is not what you use for your user segment, because you will drop good
traffic at times. You must be careful with this base policy, because performance degradation
will be apparent to the system administrator. In a typical network, you would use this policy
for some, but probably not all, of your traffic.

316
 Bootcamp SSFIPS

Larger organizations with many managed devices may have many intrusion policies and
network analysis policies to support the unique needs of various departments, business
units, or in some instances different companies. Configurations in both policy types are
contained in building blocks called layers, which you can use to efficiently manage multiple
policies.

Layers in intrusion and network analysis policies work in essentially the same way. You can
create and edit either policy type without consciously using layers. You can modify your
policy configurations, and if you have not added user layers to your policy, the system
automatically includes your changes in a single configurable layer that
is initially named My Changes. You can also add up to 200 layers where you can configure
any combination of settings. You can copy, merge, move, and delete user layers and. most
important, share individual user layers with other policies of the same type.

You may find that the preprocessor options, intrusion rules, and other advanced settings
configured in the system-provided network analysis and intrusion policies do not fully
address the security needs of your organization.

Building custom policies can improve the performance of the system in your environment
and can provide a focused view of the malicious traffic and policy violations occurring on
your network. By creating and tuning custom policies, you can configure, at a very granular
level, how the system processes and inspects the traffic on your network for intrusions.

All custom policies have a base policy, also called a base layer, which defines the default
settings for all configurations in the policy. A layer is a building block that you can use to
efficiently manage multiple network analysis or intrusion policies.

317
 Bootcamp SSFIPS

The graphic illustrates the layer concept. You might recall that the principle of the layer
concept is to have Talos managing your Snort rules and system settings while you make
more granular decisions on individual rules and settings.

The graphic represents how the GUI displays a layered intrusion policy.

Policy Layer Facts

 Upper layers override lower layers for the same rule or setting.
 If you had three layers with different rule states for the same Snort rule, the
uppermost layer state would be the final state.
 You can have multiple layers.
 It is typical to have a layer for making changes and another layer for
nonchangeable states.

 You can have up to 200 layers in any intrusion or network analysis policy (not
common).

 You can share layers.

 You can have an enterprisewide layer that decides on certain Snort rules or
settings, and another layer for changes to only certain network segments.

Layer stacks are composed of the following:

318
 Bootcamp SSFIPS
 User layers—User-configurable layers. You can copy, merge, move, or delete
any user-configurable layer and set any user-configurable layer to be shared by
other policies of the same type. This layer includes the automatically generated
layer initially named My Changes.
 Built-in layers—The read-only base policy layer. The policy in this layer can be
either a system-provided policy or a custom policy that you created. By default, a
network analysis or intrusion policy includes a base policy layer and a My
Changes layer. You can add user layers as necessary. Each policy layer contains
complete configurations for either all preprocessors in a network analysis policy
or all intrusion rules and advanced settings in an intrusion policy. The lowest
base-
policy layer includes all the settings from the base policy that you selected when
you created the policy. A setting in a higher layer takes precedence over the
same setting in a lower layer. Features not explicitly set in a layer inherit their
settings from the next-highest layer where they are explicitly set. The system
flattens the layers—that is, it applies only the cumulative effed of all settings—
when it handles network traffic.

Layer Management

The Policy Layers page provides a single-page summary of the complete layer stack for your
network analysis or intrusion policy. On this page, you can add shared and unshared layers,
copy, merge, move, and delete layers, access the summary page for each layer, and access
configuration pages for enabled, disabled, and overridden configurations within each layer.

For each layer, you can view the following information:

• Whether the layer is a built-in. shared-user, or unshared-user layer.

• Which layers contain the highest—that is, the effective—preprocessor or advanced setting
configurations, by feature name

• In an intrusion policy, the number of intrusion rules whose states are set in the layer, and
the number of rules set to each rule state.

The Policy Layers page also provides a summary of the net effect of all enabled
preprocessors (network analysis) or advanced settings (intrusion) and. for intrusion policies,
intrusion rules.

You can add up to 200 layers to a network analysis or intrusion policy. When you add a
layer, it appears as the highest layer in your policy. The initial state is Inherit for all features,
and in an intrusion policy, no event filtering, dynamic state, or alerting rule actions are set.

You give a user-configurable layer a unique name when you add the layer to your policy.
Later, you can change the name and. optionally, add or modify a description that is visible
when you edit the layer.

You can copy a layer, move a layer up or down within the User Layers page area, or delete
a user layer, including the initial My Changes layer. Note the following considerations:

• When you copy a layer, the copy appears as the highest layer.

• Copying a shared layer creates a layer that is initially unshared and which you can then
share if you choose.

319
 Bootcamp SSFIPS

• You cannot delete a shared layer; a layer with sharing enabled that you have not shared
with another policy is not a shared layer.

You can merge a user-configurable layer with another user-configurable layer immediately
beneath it. A merged layer retains all settings that
were unique to either layer, and accepts the settings from the higher layer if both layers
included settings for the same preprocessor, intrusion rule, or advanced setting. The merged
layer retains the name of the lower layer. In the policy where you create a sharable layer that
you can add to other policies, you can merge an unshared layer immediately above the
sharable layer with the sharable layer, but you cannot merge the sharable layer with an
unshared layer beneath it. In a policy in which you add a shared layer that you created in
another policy, you can merge the shared layer into an unshared layer immediately beneath
it and the resulting layer is no longer shared; you cannot merge an unshared layer into a
shared layer beneath it.

Regardless of whether you allow rule updates to modify your policy, changes in a rule
update never override changes that you make in a layer. The reason is that changes in a
rule update are made in the base policy, which determines the default settings in your base
policy layer. Your changes are always made in a higher layer, so they override any changes
that a rule update makes to your base policy.

For example, if you add a layer to rule 1:1232 and change its state {perhaps to Disabled)
and Talos changes the rule state to Drop months later in the base policy you are using, that
new rule state will not take effect.

320
 Bootcamp SSFIPS
A shared layer is a layer that you add to your policy after creating the layer in another policy
in which you allow it to be shared. A sharable layer is a layer that you allow to be shared.

A shared layer is typically used to enforce certain rules and settings across your entire
enterprise, but it still allows more-granular site-specific changes.

The graphic short's an example of a master policy in which you create the companywide
layer and site-specific layers for sites A and B and allow them to be shared. You then add
these layers as shared layers to the policies for sites A and B.

The companywide layer in the master policy includes settings that are applicable to sites A
and B. The site-specific layers include settings that are specific to each site. For example, in
the case of a network analysis policy, site A might not have web servers on the monitored
network. Site A would not require the protection or processing overhead of the HTTP Inspect
preprocessor, but both sites would likely require TCP stream preprocessing. You could
enable TCP stream processing in the companywide layer that you share with both sites,
disable the HTTP Inspect preprocessor in the site-specific layer that you share with site A.
and enable the HTTP Inspect preprocessor
in the site-specific layer that you share with site B. By editing configurations in a higher layer
in the site-specific policies, you could also further tune the policy for each site, if necessary,
with any configuration adjustments.

It is unlikely that the flattened net settings in the master policy example would be useful for
monitoring traffic, but the time saved in configuring and updating the site-specific policies
makes this application of policy layers useful.

Many other layer configurations are possible. For example, you could define policy layers by
company, by department, by network, or even by user. In the case of an intrusion policy, you
could also include advanced settings in one layer and rule settings in another.

You can allow a user-configurable layer to be shared with other policies of the same type
(intrusion or network analysis). When you modify a configuration within a sharable layer and
then commit your changes, the system updates all policies that share the layer and provides
you with a list of all affected policies. You can change feature configurations only in the
policy in which you created the layer.

You cannot disable sharing for a layer that you have added to another policy; you must first
delete the layer from the other policy or delete the other policy.

You cannot add a shared layer to a policy when your base policy is a custom policy in which
the layer you want to share was created. To do so would give the policy a circular
dependency. In a multidomain deployment, you can add shared layers from ancestor
policies to policies in descendant domains.

321
 Bootcamp SSFIPS

From the information in the table shown in the graphic, complete the policy field for each of
the rules.

322
 Bootcamp SSFIPS
Lesson Summary

In this lesson, you learned the following:

• Intrusion policies in the Firepower System are used to manage Snort rules, and require
both the expertise of Talos and input from the Firepower System administrator for up-to-
date management.

• Intrusion policy components consist of a base policy layer. Firepower recommendations

layer, user-created layers, rule actions, and variable sets.

• Three fundamental base intrusion policies are available that provide prebuilt and Talos-
maintained rule configurations for the various environments in your network.

• Policy layers in the Firepower System allow the administrator to make changes to rule
states and configurations without affecting the read-only base policies.

• Policy layers can be collectively used and shared, with the layer decisions in the upper
layers overriding any lower layers.

323
 Bootcamp SSFIPS
Creating Intrusion Policies

Description

This lesson describes the creation of an intrusion policy, the Drop When Inline feature, and
the rules pane that you can use to manage all the available Snort rules.

Objectives

After completing this lesson, you will be able to do the following:

• Describe the process of creating a new intrusion policy in the Firepower System.

• Describe the Drop When Inline feature and explain how it is used.

• Identify the intrusion policy's rules pane.

324
 Bootcamp SSFIPS

It is typical to have more than one intrusion policy, with each one meeting the conditions that
you intended for the traffic that you sent it from the access control policy. From the GUI,
navigate to Policies>Intrusion to see all your policies.

With access control policies, you can have only one policy per managed device. However,
you can (and likely will) have multiple intrusion policies per managed device. Various areas
of your network have various priorities, various users, various servers, and so on. The
intrusion policy is where inspection for malicious traffic is performed, so with a variety of
traffic, you tune your traffic to match various intrusion policies. The more tuning you do, the
fewer false positives you will have, along with better security and better performance.

Notice the Status component highlighted in green in the graphic. This status indicates that
the policy is up-to-date. Remember that a policy deployment is required for any change you
make to this policy.

325
 Bootcamp SSFIPS

If you create a custom intrusion policy, you can do the following:

• Tune detection by enabling and disabling rules, as well as by writing and adding your own
rules.

• Use Firepower recommendations to associate the operating systems, servers, and client
application protocols detected on your network with rules written specifically to protect
those assets.

• Configure various advanced settings, such as external alerting, sensitive data

preprocessing, and global rule thresholding.

• Use layers as building blocks to efficiently manage multiple intrusion policies.

In an inline deployment, an intrusion policy can block and modify traffic

• Drop rules can drop matching packets and generate intrusion events. To configure an
intrusion or preprocessor drop rule, set its state to Drop and Generate Events.

• Intrusion rules can use the replace keyword to replace malicious content.

For intrusion rules to affect traffic, you must correctly configure drop rules and rules that
replace content, as well as correctly deploy managed devices inline—that is, with inline
interface sets. Finally, you must enable the intrusion policy's drop behavior, or Drop When
Inline setting.

When tailoring your intrusion policy, especially when enabling and adding rules, keep in
mind that some intrusion rules require that traffic first be decoded or preprocessed in a
certain way. Before an intrusion policy examines a packet, the packet is preprocessed
according to configurations in a network analysis policy. If you disable a required
preprocessor, the system automatically uses it with its current settings, although the
preprocessor remains disabled in the network analysis policy web interface.

326
 Bootcamp SSFIPS

For intrusion rules to affect traffic, you must correctly configure drop rules and rules that
replace content, as well as correctly deploy managed devices inline—that is. With inline
interface sets. Finally, you must enable the intrusion policy's drop behavior, or Drop When
Inline setting.

This check box is on an individual intrusion policy, and because you can have multiple
intrusion policies, you can have some policies set to drop and others not set to drop. For
example, you could be dropping in the access control policy, dropping in Security
Intelligence, and not dropping in your intrusion policy.

The Firepower System has many opportunities and layers of protection, and as such, it gives
you many opportunities to make drop decisions. The choices illustrated in the graphic are
the most common and manageable, but there are others also (as in an SSL policy).

327
 Bootcamp SSFIPS

Each intrusion policy can have only one base policy. You create multiple intrusion policies to
address the various types of decisions that you must make for the various types of traffic in
your enterprise.

Example: If you use a base policy in policy X. and you change the base policy, policy X will
be affected and must be deployed with those changes.

The main page of your intrusion policy contains general information.

328
 Bootcamp SSFIPS

You can filter the rules that you display on the rules page by a single criteria or by a
combination of one or more criteria.

Rule filter keywords help you find the rules for which you want to apply rule settings, such as
rule states or event filters. You can filter by a keyword and simultaneously select the
argument for the keyword by selecting the argument that you want from the rules page filter
panel.

Intrusion Policy Rule Filters Construction Guidelines

In most cases, when you are building a filter, you can use the filter panel to the left of the
rules page in the intrusion policy to choose the keywords or arguments that you want to use.
Rule filters are grouped into rule filter groups in the filter panel. Many rule filter groups
contain subcriteria, so that you can more easily find the specific rules you are looking for.
Some rule filters have multiple levels that you can expand to drill down to individual rules.

Items in the filter panel sometimes represent filter type groups, sometimes represent
keywords, and sometimes represent the argument to a keyword. Note the following:

• When you choose a filter type group heading that is not a keyword (Rule Configuration.
Rule Content. Platform Specific, and Priority), it expands to list the available keywords.

• When you choose a keyword by clicking a node in the criteria list, a pop-up window
appears, where you supply the argument that you want to filter by. If that keyword is
already used in the filter, the argument that you supply replaces the existing argument
for that keyword.

For example, if you dick Drop and Generate Events under Rule Configuration >
Recommendation in the filter panel. Recommendation: "Drop and Generate Events" is
added to the filter text box. If you then click Generate Events under Rule Configuration >
Recommendation, the filter changes to Recommendation: "Generate Events."

When you choose a filter type group heading that is a keyword (Category. Classifications.
Microsoft Vulnerabilities. Microsoft Worms. Priority, and Rule Update), it lists the available
arguments.

329
 Bootcamp SSFIPS
When you choose an item from this type of group, the argument and the keyword that it
applies to are immediately added to the filter. If the keyword is already in the filter, it replaces
the existing argument for the keyword that corresponds to that group.

For example, if you dick os-linux under Category in the filter panel. Category: "os-linux" is
added to the filter text box. If you then dick os-windows under Category, the filter changes to
Category: "os-windows."

Note the following:

 Reference under Rule Content is a keyword, and so are the specific reference ID
types listed below it.

When you choose any of the reference keywords, a pop-up window appears, where you
supply an argument and the keyword is added to the existing filter. If the keyword is already
in use in the filter, the new argument that you supply replaces the existing argument.

For example, if you dick Rule Content > Reference > CVE ID in the filter panel, a pop-up
window prompts you to supply the CVE ID, If you enter 2007. Then CVE: "2007" is added to
the filter text box. In another example, if you dick Rule Content > Reference in the filter
panel, a pop-up window prompts you to supply the reference, If you enter 2007, then
Reference: "2007* is added to the filter text box.

 When you choose rule filter keywords from separate groups, each filter keyword is
added to the filter and any existing keywords are maintained (unless they are
overridden by a new value for the same keyword).

For example, if you click os-linux under Category in the filter panel. Category: "os-linux" is
added to the filter text box. If you then click MS00-006 under Microsoft Vulnerabilities, the
filter changes to Category: "os-linux" MicrosoftVulnerabilities: "MSOO-0O6."

 When you choose multiple keywords, the system combines them by using AND logic
to create a compound search filter. For example, if you choose preprocessor under
Category and then choose Rule Content > GID and enter 116, you get a filter of
Category: "preprocessor" GID: "116", which retrieves all rules that are preprocessor
rules and that have a GID of 116.

 The Category. Microsoft Vulnerabilities. Microsoft Worms. Platform Specific, and

Priority filter groups allow you to submit more than one argument for a keyword,
separated by commas. For example, you can choose os-linux and os-windows from
Category to produce the filter Category: "os-windows.app-detect". Which retrieves
any rules in the os-linux category or in the os-windows category.

Intrusion Rule Categories

330
 Bootcamp SSFIPS

The Firepower System places rules in categories based on the type of traffic that the rule
detects. On the rules page, you can filter by rule category, so you can set a rule attribute for
all rules in a category. For example, if you do not have Linux hosts on your network, you
could filter by the os-linux category, and then disable all the rules listed to disable the entire
os-linux category.

You can hover your pointer over a category name to display the number of rules in that
category.

Intrusion Rule Filter Usage

You can select predefined filter keywords from the filter panel on the left side of the rules
page in the intrusion policy. When you select a filter, the page displays all matching rules, or
indicates when no rules match.

You can add keywords to a filter to further constrain it. Any filter you enter searches the
entire rules database and returns all matching rules. When you enter a filter while the page
still displays the result of a previous filter, the page dears and returns the result of the new
filter instead.

You can also type a filter by using the same keyword and argument syntax supplied when
you select a filter, or you can modify argument values in a filter after you select it. When you
type search terms without a keyword, without initial capitalization of the keyword, or without
quotation marks around the argument, the search is treated as a string search and the
category, message, and SID fields are searched for the specified terms.

331
 Bootcamp SSFIPS

Lesson Summary

In this lesson, you learned the following:

• To create a new intrusion policy in the Firepower System, you first choose a base policy
and then select any additional information as needed.

• Uncheck the Drop When Inline check box when you want to create and deploy an intrusion
policy without dropping any traffic that matches the policy's rules.

• The intrusion policy rules pane includes all available rules. You can search these rules by
using the filter bar.

332
 Bootcamp SSFIPS

Managing Intrusion Policies

Description

This lesson describes the Snort rule states and options, and how to use Firepower
recommendations to automatically tune the available rules.

Objectives

After completing this lesson, you will be able to do the following:

• Identify the three Snort rule states

• Describe the intrusion policy rule options and how they are typically used

• Describe the details provided for each Snort rule

• Describe Firepower recommendations and how they are managed in the system

• Identify the steps necessary to implement changes made to an intrusion policy

333
 Bootcamp SSFIPS

Intrusion rule states allow you to enable or disable the rule within an individual intrusion
policy, as well as specify which action the system takes if monitored conditions trigger the
rule.

The Cisco Talos Security Intelligence and Research Group (Talos) sets the default state of
each intrusion and preprocessor rule in each default policy. For example, a rule may be
enabled in the Security Over Connectivity default policy and disabled in the Connectivity
Over Security default policy. Talos sometimes uses a rule update to change the default state
of one or more rules in a default policy. If you allow rule updates to update your base policy,
you also allow the rule update to change the default state of a rule in your policy when the
default state changes in the default policy that you used to create your policy (or in the
default policy that it is based on). Note, however, that if you have changed the rule state, the
rule update does not override your change.

When you create an intrusion rule, it inherits the default states of the rules in the default
policy that you use to create your policy.

Intrusion Rule State Options

In an intrusion policy, you can set a rule's state to the following values:

• Generate Events—You want the system to detect a specific intrusion attempt and
generate an intrusion event when it finds matching traffic. When a malicious packet
crosses your network and triggers the rule, the packet is sent to its destination and the
system generates an intrusion event. The malicious packet reaches its target, but you
are notified by means of the event logging.

• Drop and Generate Events—You want the system to detect a specific intrusion attempt,
drop the packet containing the attack, and generate an intrusion event when it finds
matching traffic. The malicious packet never reaches its target, and you are notified by
means of the event logging.

Rules that are set to this rule state generate events but do not drop packets in a passive
deployment, including deployments where a 7000 or 8000 Series device inline interface set
is in tap mode. For the system to drop packets, you must also enable the Drop When Inline
option in your intrusion policy and deploy your device inline.

334
 Bootcamp SSFIPS

• Disable—You do not want the system to evaluate matching traffic.

To modify a rule state, complete the following procedure:

Step 1
Choose Policies > Access Control > Intrusion.

Step 2
Click the edit icon next to the policy that you want to edit.

Step 3
Click Rules immediately under Policy Information in the navigation panel.

Step 4
Choose the rule or rules where you want to set the rule state.

Step 5

Choose one of the following:

• Rule State > Generate Events

• Rule State > Drop and Generate Events

• Rule State > Disable

Step 6

To save the changes you made in this policy since the last policy commit, dick Policy
Information in the navigation panel and then dick Commit Changes. If you leave the policy
without committing your changes, any changes since the last commit are discarded if you
edit a different policy.

335
 Bootcamp SSFIPS
Rule State Best Practices

 The Firepower System contains all the available Snort rules.

 More than half of the Snort rules are disabled by default in all base policies.

 The rules may be outdated, may be only for certain environments, or may no
longer be needed.

 Talos does not recommend that you turn on all the rules.

 Doing so causes significant performance issues and false positives.

 More rules that are engaged means more performance impact on the managed
device.

 There are reasons that Talos disables rules, so it is best to research any rule that
you want to turn on that is off by default.

 Base policies define a rule state for every rule.

Over half of the available Snort rules are intentionally disabled (turned off) in all the base
policies. Talos does not delete rules. Rules that they do not want turned on in any policy by
default are disabled but not deleted. Talos will disable a rule for a variety of reasons.

For example, there might be a rule that was written to address an operating system that is
no longer widely used in networks. Talos may decide at a certain time (in a rule update) to
disable that rule by default, leaving you with the option to turn the rule on if you are using
that operating system in your network.

There are reasons for the rule states that are in each base policy. If a rule is disabled, it is
not wise to enable it without researching the rule first.

336
 Bootcamp SSFIPS
The importance of an intrusion event can be based on frequency of occurrence or on source
or destination IP address. In some cases, you may not care about an event until it has
occurred a certain number of times.

For example, you may not be concerned if someone attempts to log in to a server until they
fail a certain number of times. In other cases, you may need to see only a few occurrences
to know that there is a widespread problem.

For example, if a DoS attack is launched against your web server, you may need to see only
a few occurrences of an intrusion event to know that you need to address the situation.
Seeing hundreds of the same event overwhelms your system.

Intrusion Event Thresholds

You can set thresholds for individual rules, for each intrusion policy, to limit the number of
times that the system logs and displays an intrusion event, based on how many times the
event is generated within a specified time period. This action can prevent you from having to
respond to too many identical events. You can set thresholds for each shared object rule,
standard text rule, or preprocessor rule.

Threshold filtering has the following configuration options:

 Limit—Logs and displays events for the specified number of packets (specified by
the Count argument) that trigger the rule during the specified time period. For
example, if you set the type to Limit, the count to 10, and the seconds to 60, and 14
packets trigger the rule, the system stops logging events for the rule after displaying
the first 10 that occur within the same minute.

 Threshold—Logs and displays a single event when the specified number of packets
(specified by the Count argument) trigger the rule during the specified time period.
Note that the counter for the time restarts after the threshold count of events is
reached and the system logs that event. For example, you set the type to Threshold,
the count to 10, and the seconds to 60, and the rule triggers 10 times by second 33.
The system generates one event and then resets the Seconds and Count counters to
0. The rule then triggers another 10 times in the next 25 seconds. Because the
counters are reset to 0 at second 33. the system logs another event.

 Both—Logs and displays an event once per specified time period, after the specified
number (count) of packets triggers the rule. For example, if you set the type to Both,
the count to two, and the seconds to 10, the following event counts result:

- If the rule is triggered once in 10 seconds, the system does not generate any
events (the threshold is not met.)

- If the rule is triggered twice in 10 seconds, the system generates one event.
(The threshold is met when the rule is triggered the second time.)

- If the rule is triggered four times in 10 seconds, the system generates one
event. (The threshold is met when the rule is triggered the second time, and events
that follow are ignored.)

337
 Bootcamp SSFIPS

You can suppress intrusion event notification when a specific IP address or range of IP
addresses triggers a specific rule or preprocessor. This action is useful for eliminating false
positives. For example, if you have a mail server that transmits packets that look like a
specific exploit, you might suppress event notification for that event when it is triggered by
your mail server. The rule is triggered for all packets, but you see events only for legitimate
attacks.

Intrusion Policy Suppression Types

You can use intrusion event suppression alone or in any combination with rate-based attack
prevention, the detection filter keyword, and intrusion event thresholding.

Rate-based attacks attempt to overwhelm a network or host by sending excessive traffic

toward the network or host, causing it to slow down or deny legitimate requests. You can use
rate-based prevention to change the action of a rule in response to excessive rule matches
for specific rules.

338
 Bootcamp SSFIPS
You can configure your intrusion policies to include a rate-based filter that detects when too
many matches for a rule occur in a given time period. You can use this feature on managed
devices deployed inline to block rate-based attacks for a specified time, and then revert to a
rule state in which rule matches only generate events and do not drop traffic.

Rate-based attack prevention identifies abnormal traffic patterns and attempts to minimize
the impact of that traffic on legitimate requests. You can identify excessive rule matches in
traffic going to a particular destination IP address or addresses or coming from a particular
source IP address or addresses. You can also respond to excessive matches for a particular
rule across all detected traffic.

In some cases, you may not want to set a rule to the Drop and Generate Events state,
because you do not want to drop every packet that matches the rule but you do want to drop
packets matching the rule if a particular rate of matches occurs in a specified time. Dynamic
rule states let you configure the rate that should trigger a change in the action for a rule,
what the action should change to when the rate is met. and how long the new action should
persist.

Dynamic Intrusion Rule State Configuration

In the intrusion policy, you can configure a rate-based filter for any intrusion or preprocessor
rule. The rate-based filter contains three components:

 The rule-matching rate, which you configure as a count of rule matches within a
specific number of seconds.

 A new action to be taken when the rate is exceeded, with three available actions:
Generate Events. Drop and Generate Events, and Disable.

 The duration of the action, which you configure as a timeout value.

When started, the new action occurs until the timeout is reached, even if the rate falls below
the configured rate during that time period. When the timeout is reached, if the rate has
fallen below the threshold, the action for the rule reverts to the action initially
configured for the rule.

You can configure rate-based attack prevention in an inline deployment to block attacks,
either temporarily or permanently. Without rate-based configuration, rules that are set to
Generate Events do generate events, but the system does not drop packets for those rules.
However, if the attack traffic matches rules that have rate-based criteria configured, the rate
action may cause packet dropping to occur for the period of time that the rate action is
active, even if those rules are not initially set to Drop and Generate Events.

You can define multiple rate-based filters on the same rule. The first filter listed in the
intrusion policy has the highest priority. When two rate-based filter actions conflict, the action
of the first rate-based filter is carried out.

339
 Bootcamp SSFIPS

Intrusion policy rule options also include rule comments and SNMP alerts. Further detail is
provided below.

Rule Comments

You can add comments to rules in your intrusion policy. Comments that are added in this
way are policy-specific; that is, comments that you add to a rule in one intrusion policy are
not visible in other intrusion policies. Any comments that you add are displayed in the Rule
Details view on the Rules page for the intrusion policy.
After you commit the intrusion policy changes containing the comment, you can also view
the comment by clicking Rule Comment on the rule Edit page.

SNMP Alerts

If you configure SNMP alerting for your Firepower System, you can configure specific rules
to provide an SNMP alert when the rule generates an event.

The execution of the Demo will be guided by the trainer

340
 Bootcamp SSFIPS
Complete the activity described in the graphic. The simulation will guide you through the
steps required.

All rules have varying degrees of information about them. Depending on the rule and when it
was written {and how potentially impactful it can be), you will see quite a bit of information.
Keep in mind that these details are subject to change, because Talos manages not only the
new rules but the existing ones as well.

These rule options, as you may recall, are for you to add to intrusion policies if you so
choose. By default, none of these are applied. They are for you to use. The rule as it is
written in Snort longhand is displayed here. If you are fluent in the Snort rule language, this
can be helpful to see.

341
 Bootcamp SSFIPS

Summary and Detailed Information vary from rule to rule. Typically, the rules that are written
to address a more severe threat are populated with this information. Affected Systems is
typically the first place that the analyst will look. From here, the analyst can see whether that
host that received or almost received the attack is actually vulnerable to the attack.

Although they are not the majority, there are Snort rules that are known to generate a false
positive or false negative. Sometimes the rule writer in Talos has no other option. Typically,
the false positive-prone rules are set to simply generate events, because it is critical for the
analyst to research these rules. Impact can also be contextual, because often the rule
provides insight into what the potential impact on the affected host will likely be.

342
 Bootcamp SSFIPS

Talos typically provides at least two references, and these are updated if the web addresses
change. The SRU is useful in certain scenarios, such as when a rule is firing often and has
just started to do so. If the rule was just imported into the system and turned on, it is likely
addressing a new threat (as happens often) or it is simply not functioning properly {as with a
system in your environment that is incorrectly firing on the new rule).

Now that you have seen how to create intrusion policies and manage the various base
policies and their rule states, you will see how you can use Firepower recommendations to
automatically do this for you.

Firepower Recommended Rule Basics

You can use Firepower intrusion rule recommendations to associate the operating systems,
servers, and client application protocols detected on your network with rules written
specifically to protect those assets. This way. you can tailor your intrusion policy to the
specific needs of your monitored network.

The system makes an individual set of recommendations for each intrusion policy. It typically
recommends rule state changes for standard text rules and shared object rules. However, it
can also recommend changes for preprocessor and decoder rules.

343
 Bootcamp SSFIPS

When you generate rule state recommendations, you can use the default settings or
configure advanced settings.

With advanced settings, you can do the following:

 Redefine which hosts on your network the system monitors for vulnerabilities.

 Influence which rules the system recommends, based on rule overhead.

 Specify whether to generate recommendations to disable rules.

You can also choose either to use the recommendations immediately or to review the
recommendations (and affected rules) before accepting them.

Choosing to use recommended rule states adds a read-only Firepower Recommendations

layer to your intrusion policy, and subsequently choosing not to use recommended rule
states removes the layer.

You can schedule a task to generate recommendations automatically, based on the most
recently saved configuration settings in your intrusion policy.

The system does not change rule states that you set manually:

 Manually setting the states of specified rules before you generate recommendations
prevents the system from modifying the states of those rules in the future.

 Manually setting the states of specified rules after you generate recommendations
overrides the recommended states of those rules.

344
 Bootcamp SSFIPS
When you generate Firepower recommendations, the system searches your base policy for
rules that protect against vulnerabilities associated with your network assets, and identifies
the current state of rules in your base policy. The system then recommends rule states and.
if you choose the recommendations, sets the rules to the recommended states.

When you generate recommendations without changing the advanced settings for Firepower
recommended rules, the system recommends rule state changes for all hosts in your entire
discovered network.

By default, the system generates recommendations only for rules with low or medium
overhead, and generates recommendations to disable rules.

The system does not recommend a rule state for an intrusion rule that is based on a
vulnerability that you disable using the Impact Qualification feature.

The system always recommends that you enable a local rule associated with a third-party
vulnerability mapped to a host.

The system does not make state recommendations for unmapped local rules.

Advanced settings for Firepower recommendations include the following:

• Networks to Examine—Specifies the monitored networks or individual hosts to examine

for recommendations. You can specify a single IP address or address block, or a
comma-separated list consisting of either or both. Lists of addresses within the hosts that
you specify are linked with an OR operation except for negations, which are linked with
an AND operation after all OR operations are calculated. If you want to dynamically
adapt active rule processing for specific packets based on host information, you can also
enable adaptive profiles.

• Recommendation Threshold {by Rule Overhead)—Configures the system to make rule

state recommendations based on all rules up to and including the specified overhead
rating. For example, when you generate recommendations for rules with medium
overhead, the system makes recommendations based on all rules with an overhead
rating of none, low, or medium, and does not make any recommendations for rules with
high overhead.

345
 Bootcamp SSFIPS

Cisco rates the overhead of each intrusion rule as none, low, medium, or high, based on the
rule's potential impact on system performance and the likelihood that
the rule may generate false positives. You can view the overhead rating for a rule in the rule
detail view on the Rules page.

The system factors the rule overhead into recommendations to generate events or to drop
and generate events. The system does not factor the rule overhead into
recommendations to disable rules. Local rules have no overhead unless they are mapped to
a third-party vulnerability.

Generating recommendations for rules with the overhead rating at a particular setting does
not preclude you from generating recommendations with different
overhead and then generating recommendations again for the original overhead setting. You
get the same rule state recommendations for each overhead setting
each time that you generate recommendations for the same rule set. regardless of the
number of times that you generate recommendations or how many
different overhead settings you generate with. For example, you can generate
recommendations with overhead set to medium, then to high, and finally, to
medium again; if the hosts and applications on your network have not changed, both sets of
recommendations with overhead set to medium are then the same
for that rule set.

 Accept Recommendations to Disable Rules—Specifies whether or not the system

disables rules based on Firepower recommendations.

Accepting recommendations to disable rules restricts your rule coverage. Omitting

recommendations to disable rules augments your rule coverage.

The first time that you run Firepower recommendations, you should be very aware of the
changes that it is recommending. Keep in mind that as these changes tie directly
to your host profiles, these states rely on accurate host profile data to be the most beneficial.
Use this occasion as an opportunity to look at your host profiles to see if they

346
 Bootcamp SSFIPS
are being populated accurately. If they are not. you may want to consider typing third-party
vulnerability data and manually editing these hosts. Remember that the rules
are tied to vulnerabilities, and the vulnerabilities in your hosts are tied to what the
applications, services, and operating system's Firepower detects in your protected
network.

After the first run. it is expected in most environments that changes will be minimal unless
atypical changes occur in your network discovery. If you modify Network
Discovery or you are managing a network with frequently changing hosts, you may want to
manually run these more often.

Keep in mind that any changes to the intrusion policy, such as changing the state of a rule,
will require the deployment of those changes to your managed device.

When you generate rule state recommendations in an intrusion policy, you can choose
whether to automatically modify rule states based on the recommendations.

As shown in the graphic, using recommended rule states inserts a read-only, built-in
Firepower recommendations layer immediately above the base layer.

If you subsequently choose not to use recommended rule states, the system removes the
Firepower recommendations layer. You cannot manually delete this layer, but you
can add and remove it by choosing to use or not use recommended rule states.

Adding the Firepower Recommendations layer adds a Firepower Recommendations link

under Policy Layers in the navigation panel. This link leads you to a read-only
view of the Firepower Recommendations layer page, where you can access a
recommendation-filtered view of the Rules page in read-only mode.

Using recommended rule states also adds a Rules sublink beneath the Firepower
Recommendations link in the navigation panel. The Rules sublink provides access to a

347
 Bootcamp SSFIPS
read-only display of the Rules page in the Firepower Recommendations layer. Note the
following in this view:

 When there is no rule state icon in the state column, the state is inherited from the
base policy.

 When there is no rule state icon in the Firepower Recommendation column in this or
other Rules page views, there is no recommendation for this rule.

From the information in the table, complete the policy field for each of the rules.

348
 Bootcamp SSFIPS

In the intrusion policy, saving any edits is called committing changes. The system caches
one intrusion policy for each user. While editing an intrusion policy, if you
choose any menu or other path to another page, your changes stay in the system cache
even if you leave the page. Be careful not to accidentally discard your changes by
attempting to edit another intrusion policy. The system will warn you if you attempt to do so.

Deployment is the act of sending the configuration to the managed device. There are two
steps for most policies (intrusion and access control policy, for the most part).
The first step is to commit changes, which is the equivalent of saving. The second step is to
deploy the configuration, in which the Firepower Management Center
communicates with the managed device to make and apply those changes. Keep in mind
that deploying certain changes can influence traffic, depending on the device,
the deployment, and the action.

349
 Bootcamp SSFIPS
Lesson Summary

In this lesson, you learned the following:

 Intrusion rule states allow you to enable or disable the rule within an individual
intrusion policy, and specify which action to take if the rule is triggered.

 Snort rule options include the ability to suppress events and threshold events sent to
the Firepower Management Center, and to enable the rule to the change state based
on how frequently the rule is triggered.

 Snort rule details provide descriptive information about the rule that can be used to
make rule state and option decisions, and can be used by the analyst to
understand the rule that was triggered in the analysis.

 Firepower recommendations utilize host profile information to configure the Snort

rules to best protect the hosts in your environment.

 Changes to an intrusion policy must first be committed, and then can be deployed to
the relevant managed devices.

350
 Bootcamp SSFIPS
SecureBank Scenario—Intrusion Policies

Solutions

 SecureBank’s intrusion policy will be set to “drop when inline."

SecureBank will configure user segments to be inspected less aggressively, and will use
“Connectivity Over Security" for the intrusion policy for the user
traffic.

 SecureBank will configure critical server segments to be inspected more

aggressively, and will use "Security Over Connectivity" as the intrusion
policy for critical server segments.

 SecureBank will use Firepower recommendations.

 SecureBank's administrators are planning to update these as the new Snort rules are
released. They will perform this task during the same maintenance windows as their
Snort Rules updates twice a week.

The graphic shows the solutions to the requirements outlined for SecureBank at the
beginning of this module.

351
 Bootcamp SSFIPS
Module Summary for “Next-Generation Intrusion Prevention Systems”

In this module, you learned the following:

 Snort rules are written and managed by Talos and are used at the core of the
intrusion detection and prevention component of the Firepower System.

 Variable sets are a collection of variables to be tied to an intrusion policy. The value
of the variables within a variable set can be modified.

 The Firepower System uses intrusion policies to incorporate the Snort detection
engine into the system.

 When creating a new intrusion policy, you select a base policy and you have the
option to override all drop decisions in the system with the Drop When Inline check
box.

 Snort rule options include the ability to suppress events and threshold events. The
system has an automated feature, known as Firepower recommendations that can
tune the rule states automatically, based on host profile information.

352
 Bootcamp SSFIPS

Knowledge Check

Q1) The Firepower System contains all Snort rules stored in the Firepower Management
Center, and the administrator of the Firepower System must regularly update
those rules. (Source: Examining Intrusion Prevention and Snort Rules).

Q2) There can be only one network definition of the variable SHOME_NET. (Source:
Examining Variables and Variable Sets).

Q3) If you use the base policy Security Over Connectivity, you will have fewer rules set to
drop traffic than if you had Balanced Security and Connectivity as your base
policy. (Source: Examining Intrusion Policies).

Q4) When the Talos group provides updates to the Snort rules and the updates are applied
to your system, the base policies are not affected. (Source: Examining
Intrusion Policies).

Q5) New intrusion policies have all the imported Snort rules available for use. (Source:
Examining Intrusion Policies).

Q6) The Drop When Inline option allows you to drop traffic in any environment, regardless of
how the Firepower System is physically deployed. (Source: Creating
Intrusion Policies).

Q7) The best practice for most environments is to use a Talos-managed base policy, such
as Connectivity Over Security. (Source: Creating Intrusion Policies).

Q8) Event filtering allows you to drop only a set amount of the matching traffic, based on the
threshold setting configuration. (Source: Managing Intrusion Policies).

353
 Bootcamp SSFIPS

Q9) Firepower recommendations are used to automatically enable and disable the most
important rules as determined by Cisco Talos. (Source: Managing Intrusion
Policies).

354
 Bootcamp SSFIPS

Module 11: Network Analysis Policies

Overview

Description

This module describes the function of Snort in the managed device, and its relationship to
network analysis policies.

Objectives

Upon completing this module, you will be able to explain the use of network analysis policies
and the role of preprocessor technology in processing network traffic for Next-
Generation IPS (NGIPS) inspection. This ability includes being able to meet these
objectives:

 Describe the role of preprocessor technology in processing network traffic.

 Describe the role of network analysis policies in managing preprocessor technology

and where these policies are managed.

 Describe and configure adaptive profiles.

355
 Bootcamp SSFIPS

SecureBank Scenario—Network Analysis Polices

Requirements:

 SecureBank's system administrators are careful not to interfere with any

advanced settings unless they have a specific need, in which case they will
call TAC for support.

 They want to take advantage of any automated ways to use their host
profile information to enhance the effectiveness of the Firepower System.

This module will describe the network analysis policy features that can be used to address
the scenario in the graphic.

In this stage of implementation, you will learn about the network analysis policy that
manages Snort and the traffic flow through the Firepower System. Network analysis
policies are not typically modified, and are engaged by default. You will however, need to
understand their function and location within the Firepower Management
Center GUI.

356
 Bootcamp SSFIPS

Examining Preprocessor Technologies

Description

This lesson describes the operation of Snort within the managed device.

Objectives

After completing this lesson, you will be able to do the following:

• Identify the role of Snort in the administrative flow.

• Describe the Snort components.

• Identify the three primary functions of Snort.

• Identify the Snort preprocessor sequence of operations.

• Describe the Snort preprocessor rules and where they are managed

357
 Bootcamp SSFIPS

Snort preprocessor technologies process the traffic in your managed device. When
the system analyzes traffic as part of your access control deployment, the network
analysis (decoding and preprocessing) phase occurs before and separately from the
intrusion prevention (intrusion rules and advanced settings) phase.

Initially, the system decodes packets through the first three TCP/IP layers, and then
continues with normalizing, preprocessing, and detecting protocol anomalies as
performed by the preprocessors.

Snort has several components:

 First is the packet sniffer. Packets are read using the Data Acquisition library (DAQ).
This is the act of pulling data off the wire and into the Snort Engine.

 Second is the packet decoder. This component decodes datalink. network, and
transport protocols.

358
 Bootcamp SSFIPS
 Third are the preprocessors, which detect anomalies, normalize traffic, and perform
reassembly.

 Fourth is the detection engine. This component uses Snort rules to create signatures
for threats. These are the rules that you manage in your NGIPS policy.

 Finally, you see the output module. This component handles the task of writing and
displaying events. As a result, you have alert and log files from what occurred
throughout this entire process.

In order for Snort to know what is in a packet, it must be presented in such a way that each
field of the packet is correctly parsed, starting from the Layer 2 (Data Link)
protocols (Ethernet, Token Ring, and so on) and on through to the application layer payload.
Snort is focused on TCP/IP, so it is decoded in its entirety. Other networking
protocols are decoded only up to Layer 2, so they can be identified, but no further action is
taken on them. Snort stores the decoded packet information in data structures
held in memory that are then passed on to the other elements of the Snort architecture—the
preprocessors, detection engine, and output processors, respectively.

The packet decoder converts packet headers and payloads into a format that can be easily
used by the preprocessors and. later, intrusion rules. Each layer of the TCP/IP
stack is decoded in turn, beginning with the data link layer and continuing through the
network and transport layers. The packet decoder also detects various anomalous
behaviors in packet headers.

359
 Bootcamp SSFIPS

In order for packets to be inspected in a contextually relevant way. some further processing
must be performed on them to reveal the context in which the packets are
intended to be used. For example:

 Are the packets part of a TCP communication, and if so, what protocol is being
utilized?

 Are the packets fragmented, and if so, can they be correctly reassembled prior to
inspection?

 Are packets that are identified as belonging to a particular protocol being used
correctly within the parameters of that protocol?

This is a sampling of actions that are necessary so that packets are presented in a
contextually relevant way. Snort preprocessors handle this task. They are specially
designed to put network traffic into context for presentation to the other elements of the
Snort architecture, mainly the rules engine.

Application layer protocols can represent the same data in a variety of ways. The Firepower
System provides application layer protocol decoders that normalize specific
types of packet data into formats that the intrusion rules engine can analyze. Normalizing
application-layer protocol encodings allows the rules engine to effectively apply
the same content-related rules to packets whose data is represented differently and obtain
meaningful results.

When an intrusion rule or rule argument requires a disabled preprocessor, the system
automatically uses it with its current configuration even though it remains disabled in
the network analysis policy's web interface.

360
 Bootcamp SSFIPS

The detection engine is the final stop for packets in the Firepower System. The rule
management of the Snort rules that you learned about in the NGIPS module occurs
here.

This topic discusses the three Snort preprocessor functions:

• Normalization

• Anomaly detection

• Reassembly

361
 Bootcamp SSFIPS

To minimize the risk of IPS evasion, the preprocessors will perform normalization. This is
taking the various different encodings that reach the system and "normalizing"
them. The rules in the detection engine can then be written to only that normalized traffic.
Application layer protocols can represent the same data in a variety of ways.
The Firepower System provides application layer protocol decoders that normalize specific
types of packet data into formats that the intrusion rules engine can analyze.
Normalizing application-layer protocol encodings allows the rules engine to effectively apply
the same content-related rules to packets whose data is represented
differently and obtain meaningful results.

Network anomalies are common but can be indicators of an attack or a compromised host.
Snort preprocessors will detect anomalies and allow you to trigger an alert if
you want to be notified. The graphic shows two examples of the frag3 preprocessor's ability
to detect two well-known network anomalies. (In your system, the frag3
preprocessor is called IP defragmentation.)

362
 Bootcamp SSFIPS

Dealing with fragmentation is a critical part of your IPS, In general. Snort performs IP and
TCP reassembly. Attacks can and do manifest themselves across IP packet
fragments, as well as across TCP streams. Reassembling helps prevent this type of evasion.

The IP defragmentation preprocessor handles IP reassembly. Various operating systems

reassemble fragmented packets in various ways. Attackers who can determine
which operating systems your hosts are running can also fragment malicious packets so that
a target host reassembles them in a specific manner. Because the system does
not recognize which operating systems the hosts on your monitored network are running, the
preprocessor might reassemble and inspect the packets incorrectly, thus
allowing an exploit to pass through undetected. To mitigate this kind of attack, you can
configure the defragmentation preprocessor to use the appropriate method of
defragmenting packets for each host on your network.

The stream (Called TCP Stream Configuration) preprocessor collects and reassembles all
the packets that are part of a TCP session's server-to-client communication
stream, client-to-server communication stream, or both. This allows the rules engine to
inspect the stream as a single, reassembled entity, rather than inspect only the
individual packets that are part of a given stream.

Stream reassembly allows the rules engine to identify stream-based attacks that it might not
detect when inspecting individual packets. You can specify which
communication streams the rules engine reassembles based on your network needs. For
example, when monitoring traffic on your web servers, you might want to inspect
only client traffic, because you are much less likely to receive malicious traffic from your own
web server.

363
 Bootcamp SSFIPS

As shown in the graphic, a Snort preprocessor works in a particular order:

1. It defragments IP packets.

2. It tracks sessions and reassembles TCP streams.

3. The application layer preprocessors normalize the traffic and detect anomalies.

4. The processed traffic is inspected by the detection engine, also known as the rules
engine.

Most preprocessors have rules associated with them, just as Snort rules do, although these
are typically turned off, by default. Because they are part of the rules menu
accordion that you learned about in the module on intrusion policy, you have the same
options. For example, you can choose to drop and generate an event on a certain
network anomaly if required.

364
 Bootcamp SSFIPS
Lesson Summary

In this lesson, you learned the following:

 Snort processes traffic in the managed device at various stages along the
administrative flow.

 The Snort components consist of the packet decoder, the preprocessors, and the
detection engine.

 Snort performs three primary functions; normalization, anomaly detection, and

reassembly.

 Snort preprocessors function in the following sequence: reassembly, session-tracking

operations, application layer preprocessing, forwarding to the detection engine.

 Most Snort preprocessors have rules associated with them that are turned off by
default.

365
 Bootcamp SSFIPS
Examining Network Analysis Policies

Description

This lesson describes the role of network analysis policies in the managed device.

Objectives

After completing this lesson, you will be able to do the following:

 Describe network analysis policies and their purpose in the Firepower System.

 Explain when network analysis policies process traffic.

 Identify the network analysis policy default settings.

 Describe where network analysis policies are managed.

366
 Bootcamp SSFIPS

Network analysis and intrusion policies work together as part of the Firepower System's
intrusion detection and prevention feature. The term intrusion detection generally
refers to the process of passively analyzing network traffic for potential intrusions and storing
attack data for security analysis. The term intrusion prevention includes the
concept of intrusion detection, but adds the ability to block or alter malicious traffic as it
travels across your network.

In an intrusion prevention deployment, when the system examines packets, the following
occurs:

 A network analysis policy governs how traffic is decoded and preprocessed so that it
can be further evaluated, especially for anomalous traffic that might signal
intrusion attempt.

 An intrusion policy uses intrusion and preprocessor rules {sometimes referred to

collectively as intrusion rules) to examine the decoded packets for attacks based
on patterns. Intrusion policies are paired with variable sets that allow you to use
named values to accurately reflect your network environment.

Both network analysis and intrusion policies are invoked by a parent access control policy,
but at different times. As the system analyzes traffic, the network analysis
{decoding and preprocessing) phase occurs before and separately from the intrusion
prevention {additional preprocessing and intrusion rules) phase. Together, network
analysis and intrusion policies provide broad and deep packet inspection. They can help you
detect, alert on, and protect against network traffic that could threaten the
availability, integrity, and confidentiality of hosts and their data.

Network analysis policies govern many traffic-preprocessing options and are invoked by
advanced settings in your access control policy. Network analysis-related
preprocessing occurs after Security Intelligence blacklisting and SSL decryption, but before
intrusion or file inspection begins.

367
 Bootcamp SSFIPS

When the system analyzes traffic as part of your access control deployment, the network
analysis (decoding and preprocessing) phase occurs before and separately from
the intrusion prevention (intrusion rules and advanced settings) phase.

The graphic shows, in a simplified fashion, the order of traffic analysis in an inline, intrusion
prevention and AMP for Firepower deployment. It illustrates how the access
control policy invokes other policies to examine traffic, and in which order those policies are
invoked. The network analysis and intrusion policy selection phases are
highlighted.

In an inline deployment (that is. where relevant configurations are deployed to devices using
routed, switched, or transparent interfaces, or inline interface pairs), the
system can block traffic with out further inspection at almost any step in the illustrated
process. Security Intelligence, the SSL policy, network analysis policies, file policies,
and intrusion policies can either drop or modify traffic. Only the network discovery policy,
which passively inspects packets, cannot affect the flow of traffic.

Similarly, at each step of the process, a packet could cause the system to generate an
event. Intrusion and preprocessor events {sometimes referred to collectively as
intrusion events) are indications that a packet or its contents might represent a security risk.

Snort Traffic Flow—Access Control Policy

 Why do Security Intelligence and the SSL policy operate first?

Security Intelligence does not require preprocessing, so it occurs first.

Traffic must be decrypted in order to preprocess, so the SSL policy is processed
first.
 The access control policy is where you manage this traffic.
 ACP manages:

368
 Bootcamp SSFIPS
How traffic is handled prior to reaching the ACP (SSL policy and
Security Intelligence).
Traffic during (ACP rules and default action).
Traffic after (NGIPS policy and malware policy).

Without decoding and preprocessing, the system could not appropriately evaluate traffic for
intrusions, because protocol differences would make pattern matching
impossible. Network analysis policies govern these traffic-handling tasks:

• After traffic is filtered by Security Intelligence.

• After encrypted traffic is decrypted by an optional SSL policy.

• Before traffic can be inspected by file or intrusion policies.

Network analysis policies manage IP defragmentation and TCP stream data, along with
application layer preprocessors. The intrusion policy manages the Snort rules that
are active.

369
 Bootcamp SSFIPS
Network analysis policies are part of every managed device and typically are not modified
unless you are required to do so in your environment.

Network Analysis Policy—Base Policy

 By default, the system uses Balanced Security and Connectivity.

 If you do not configure any network analysis policies, this is in use by default.
 Unless you are fine-tuning Snort preprocessors or decoders, you will not typically
make changes here.

 As with the intrusion policy, the network analysis policy has three base
policies:

 Connectivity Over Security

 Balanced Security and Connectivity
 Security Over Connectivity
 Base policies are created and tuned by Talos and are suitable for most
environments.

Network analysis policies govern how traffic is decoded and preprocessed, so that it can be
further evaluated, especially for anomalous traffic that might signal an intrusion
attempt. This traffic preprocessing occurs after Security Intelligence blacklisting and traffic
decryption, but before intrusion policies inspect packets in detail.

By default, the system-provided Balanced Security and Connectivity network analysis policy
is the default network analysis policy.

Configure network analysis policies from the menus in the Advanced tab of Access Control
Policy.

370
 Bootcamp SSFIPS
Network Analysis Policy Rules

A simple way to tune preprocessing is to create and use a custom network analysis policy as
the default. For advanced users with complex deployments, you can create
multiple network analysis policies, each tailored to preprocess traffic differently. Then you
can configure the system to use those policies to govern the preprocessing of
traffic with various security zones, networks, or VLANs.

To accomplish this, you add custom network analysis rules to your access control policy. A
network analysis rule is simply a set of configurations and conditions that
specifies how you preprocess traffic that matches those qualifications. You create and edit
network analysis rules in the Advanced options in an existing access control
policy. Each rule belongs to only one policy.

Each rule has two items:

 A set of rule conditions that identifies the specific traffic that you want to preprocess.

 An associated network analysis policy that you want to use to preprocess traffic that
meets all the rules' conditions.

When it is time for the system to preprocess traffic, it matches packets to network
analysis rules in top-down order by rule number. Traffic that does not match any
network analysis rules is preprocessed by the default network analysis policy.

371
 Bootcamp SSFIPS

The execution of the Demo will be guided by the trainer

372
 Bootcamp SSFIPS
Complete the activity to modify the access control policy called "TrainingExample." The
simulation will provide prompts to assist you.

Complete the following steps:

Step 1
Navigate to the Access Control Policy list.

Step 2
Edit the policy called "TrainingExample"

Step 3

From the Advanced tab edit the default network analysis policy to be Security Over
connectivity.

Step 4

Save your changes

373
 Bootcamp SSFIPS
Lesson Summary

In this lesson, you learned the following:

 Network analysis policies maintain the configuration of the Snort preprocessors in the
managed device.

 Network analysis policies process traffic after Security Intelligence and SSL policy,
and before the access control policy.

 Network analysis policies use the ' Balanced Security and Connectivity" base policy
by default. Other policies are available within the system.

 You manage network analysis policies in the Advanced tab of the Access Control
Policy.

374
 Bootcamp SSFIPS
Examining Adaptive Profiles

Description

This lesson explains adaptive profiles and how they are used to augment your detection
capabilities.

Objectives

After completing this lesson, you will be able to do the following:

 Describe the purpose of adaptive profiles.

 Describe where to configure adaptive profiles.

 Describe the differences between adaptive profiles and Firepower recommendations.

375
 Bootcamp SSFIPS

In an earlier module, you learned how Firepower discovery collects information about your
hosts and builds host profiles. These host profiles can be used to automatically
tune Snort by using adaptive profiles.

Typically, the system uses the static settings in your network analysis policy to preprocess
and analyze traffic. With adaptive profiles, the system can adapt processing
behavior by using host information either detected by network discovery or imported from a
third party.

Adaptive profiles, like the target-based profiles that you can configure manually in a network
analysis policy, help to defragment IP packets and reassemble streams in the
same way as the operating system on the target host. The intrusion rules engine then
analyzes the data in the same format as that used by the destination host.

Manually configured target-based profiles apply either the default operating system profile
that you select, or profiles that you bind to specific hosts. Adaptive profiles,
however, switch to the appropriate operating system profile based on the operating system
in the host profile for the target host.

The example in the graphic demonstrates how adaptive profiles can be used to identify the
operating system of a host, allowing the managed device to reassemble the
traffic to the specific operating system type rather than the default. This process allows for
more accurate Snort processing.

376
 Bootcamp SSFIPS

The following adaptive profile configuration options are available:

Adaptive Profiles - Enabled—Enable or disable adaptive profiles.

Adaptive Profiles - Attribute Update Interval—You can control how frequently, in minutes,
network map data is synced from the Firepower Management Center
to its managed devices. The system uses the data to determine what profiles should be
used when processing traffic. Increasing the value for this option can
improve performance in a large network.

Adaptive Profiles - Networks—Optionally, you can improve performance by constraining

adaptive profiling to a comma-separated list of IP addresses, address
blocks, and network variables. If you use a network variable, the system uses the
variable's value in the variable set linked to the default intrusion policy for your
access control policy.

For example, you could enter 192.168.1.101, 192.168.4.0/24, $HOME_NET.

377
 Bootcamp SSFIPS
Like Firepower recommended rules, adaptive profiles compare metadata in a rule to host
information to determine whether a rule should apply for a particular host.
However, while Firepower recommended rules provide recommendations for enabling or
disabling rules using that information, adaptive profiles use the information to
apply specific rules to specific traffic.

Firepower recommended rules require your interaction to implement suggested changes to

rule states. Adaptive profiles, however, do not modify intrusion policies.
Adaptive treatment of rules happens on a packet-by-packet basis.

Additionally. Firepower recommended rules can result in enabling disabled rules. Adaptive
profiles, in contrast, affect only the application of rules that are already
enabled in intrusion policies. Adaptive profiles never change the rule state.

You can use adaptive profiles and Firepower recommended rules in combination. Adaptive
profiles use the rule state for a rule when your intrusion policy is deployed, to
determine whether to include it as a candidate for applying, and your choices to accept or
decline recommendations are reflected in that rule state. You can use both
features to ensure that you have enabled or disabled the most appropriate rules for each
network that you monitor, and then to apply enabled rules most efficiently for
specific traffic.

378
 Bootcamp SSFIPS
Lesson Summary

In this lesson, you learned the following:

 Adaptive profiles are used to automatically tune Snort, based on the host profiles
stored in the Firepower Management Center.

 Adaptive profiles are configured in the Access Control Policy Advanced section, and
allow you to customize the update interval and which network map host profiles
are used.

 Adaptive profiles and Firepower recommendations are similar in purpose, but

adaptive profiles take effect on traffic as it is processed through the device, whereas
Firepower recommendations are used to change rule states in the intrusion policy.

SecureBank Scenario—Network Analysis Polices

Solutions

 SecureBank will not be changing the default network analysis policy in the
access control policy, which is "Balanced Security and Connectivity." This
default policy fits most environments and is generally left at the default
value.

 SecureBank will enable Adaptive Profiles to allow their host profile

information to enhance the effectiveness of the Snort processing.

The graphic shows the solutions to the requirements outlined for SecureBank at the
beginning of this module.

379
 Bootcamp SSFIPS
Module Summary for “Network Analysis Policies”

In this module, you learned the following:

 Preprocessor technology is used to detect anomalies and to reassemble and

normalize traffic prior to inspecting that traffic by the Snort rules engaged in your
intrusion policy.

 Network analysis policies manage the preprocessor settings and can be managed in
the Advanced tab of the access control policy.

 Adaptive profiles are used to tie host profile data into the processing of traffic in the
managed device to assist in the detection capabilities of the Firepower System.

380
 Bootcamp SSFIPS
Knowledge Check

Q1) The detection engine is the component of Snort that processes Snort rules after the
traffic is decoded and preprocessed. (Source: Examining Preprocessor
Technologies).

Q2) You can manage Snort rules in both the network analysis policy and the intrusion policy.
(Source: Examining Network Analysis Policies).

Q3) Adaptive profiles are used to turn on disabled rules in the intrusion policy for traffic that
matches an appropriate host. (Source: Examining Adaptive Profiles).

381
 Bootcamp SSFIPS
Module 12: Detailed Analysis Techniques

Overview

Description

This module explores the detailed analysis techniques that are available in the Firepower
System. The module discusses the most common event types, workflows of the
event data, tools used for analyzing the data, contextual analysis data available within the
system, and the external alerting capabilities of the Firepower Management
Center.

Objectives

Upon completing this module, you will be able to describe and demonstrate the detailed
analysis techniques and reporting features provided by the Firepower Management
Center. This ability includes being able to meet these objectives:

 Describe the operational components of event analysis.

 Define the most common event types in the Firepower System.

 Describe the contextual information that Firepower provides the analyst.

 Identify the analysis tools available in the Firepower System.

 Describe the intrusion event tuning options.

 Describe the external alerting options

382
 Bootcamp SSFIPS
SecureBank Scenario—Detailed Analysis

Requirements

 SecureBank’s Security analysts need to be able to view intrusion events

with the associated packet data from multiple perspectives, and try to gain
insight into if the event is a false positive or a real event.

 SecureBank’s Security analysts must have an easy way to identify and

analyze high priority events.

This module will describe the event analysis features that can be used to address the
scenario in the graphic.

You have now reached a point in the Firepower System implementation in which all the
policies have been initially configured. It is time to start looking at the events that
are being created by these policies.

383
 Bootcamp SSFIPS
Overview of Event Analysis

Description

This lesson examines the types of event data in the Firepower System, and how this data is
retrieved, stored, and viewed.

Objectives

After completing this lesson, you will be able to do the following:

 Describe the fundamentals of Firepower inspection capabilities and their associated

events.

 Identify the Firepower Management Center database that holds event data.

 Describe workflows within the Firepower Management Center.

384
 Bootcamp SSFIPS

The relationship between the Firepower Management Center and the managed device is
detailed here again for you.

The managed device does the following:

 Sees the traffic, whether deployed inline or passively

 Sends:

Event data to the Firepower Management Center if configured to do so

Discovery data to the Firepower Management Center if configured to do so
Device statistics to the Firepower Management Center

The graphic illustrates the policies and what they are responsible for. Examples are as
follows:

 Security Intelligence—Block blacklisted IP addresses that are known to be

malicious. An example would be a known CnC server. These IPs are managed and
updated by Talos and are fed into the system regularly.

 SSL policy—Decrypt traffic between your web server and Internet IPs. After the
traffic is decrypted, you can inspect it with the other policies.

385
 Bootcamp SSFIPS
 Access control policy—Prevent certain users from accessing certain URLs.
Choose not to inspect SIP traffic by any further policies. Block certain application
traffic.

 Intrusion policy—Send all traffic for inspection by Snort rules. Detect on attempts to
compromise vulnerable applications on your host. Mal ware policy: Inspect
files between your user segment and the Internet for malware. If a file is identified as
malware, block the file.

In the graphic, you again see in the Firepower Management Center where the analyst sees
most of the event data that is discussed in this module. Keep in mind that if
logging was not enabled for certain events, there will be no data to analyze.

The Firepower System generates information that is stored as events in database tables.
Events contain multiple fields that describe the activity that caused the appliance
to generate the event.

386
 Bootcamp SSFIPS
External Database Access Settings

You can configure the Firepower Management Center to allow read-only access to its
database by a third-party client. With this configuration, you can query the database
by using any of the following SQL tools:

 Industry-standard reporting tools, such as Actuate BIRT, JasperSoft ¡Report, or

Crystal Reports.

 Any other reporting application (including a custom application) that supports JDBC
SSL connections.

 The command-line Java application called RunQuery, which is provided by Cisco.

You can either run the application interactively or use it to obtain comma-
separated results for a single query.

Use the Firepower Management Center's system configuration to enable database access
and to create an access list that allows selected hosts to query the database.
Note that this access list does not also control appliance access.

You can also download a package that contains the following:

 RunQuery. the database query tool provided by Cisco

 InstallCert. a tool that you can use to retrieve and accept the SSL certificate from the
Firepower Management Center that you want to access.
 The JDBC driver that you must use to connect to the database.

See the Firepower System Database Access Guide for information on using the tools in the
package that you downloaded to configure database access. Navigate to the
following page:

387
 Bootcamp SSFIPS

The Event Streamer (eStreamer) allows you to stream several kinds of event data from a
Firepower Management Center or 7000 or 8000 Series device to a custom-
developed dient application. For more information, see Firepower eStreamer Integration
Guide.

Before the appliance you want to use as an eStreamer server can begin streaming
eStreamer events to an external client, you must configure the eStreamer server to
send events to clients, provide information about the client, and generate a set of
authentication credentials to use when establishing communication. You can perform
all of these tasks from the appliance's user interface. Once your settings are saved, the
events you selected will be forwarded to eStreamer dients when requested.

The eStreamer Event Configuration check boxes control which events the eStreamer server
can transmit. Your client must still specifically request the types of events you
want it to receive in the request message it sends to the eStreamer server.

Before eStreamer can send eStreamer events to a client, you must add the client to the
eStreamer server's peers database from the eStreamer page. You must also copy
the authentication certificate generated by the eStreamer server to the client. After
completing these steps you do not need to restart the eStreamer service to enable the
client to connect to the eStreamer server.

You can create and save searches customized for your environment for any of the various
event types and save them to reuse later.

When you save a search, you give it a name and specify whether the search will be
available to you alone or to all users of the appliance.

If you want to use the search as a data restriction for a custom user role, you must save it as
a private search. If you previously saved a search, you can load it, make any necessary
modifications, and then start the search. Custom analysis dashboard widgets, report
templates, and custom roles can also use saved searches. If you have saved searches, you
can delete them from the Search page.

388
 Bootcamp SSFIPS

For some event types, the Firepower System provides predefined searches that serve as
examples and can provide quick access to important information about your
network. You can modify fields within the predefined searches for your network environment
and then save the searches to reuse later.

The search criteria that you can use depends on the type of search, but the mechanics are
the same. Searches return only records that match the search criteria specified for all fields.

A workflow is a tailored series of data pages on the Firepower Management Center web
interface that analysts can use to evaluate events generated by the system. The
data displayed in a workflow often depends on such factors as how you license and deploy
your managed devices, and whether you configure features that provide the
data. Analysts can view workflows to perform deep and contextual event data analysis to
gain insight into the events.

After the analysts become familiar with the type of data that they both have and want to
analyze in their environment, they can create workflows to suit these inquiries.
The following types of workflows are available on the Firepower Management Center:

389
 Bootcamp SSFIPS
 Predefined workflows—Preset workflows delivered with the system. You cannot
edit or delete a predefined workflow. You can. however, copy a predefined
workflow and use it as the basis for a custom workflow.
 Saved custom workflows—Custom workflows based on saved custom tables
delivered with the Firepower Management Center. You can edit, delete, and copy
these workflows.

 Custom workflows—Workflows that you create and customize for your specific
needs, or that the system generates automatically when you create custom tables.
You can edit, delete, and copy these workflows.

390
 Bootcamp SSFIPS

Lesson Summary

In this lesson, you learned the following:

 The Firepower managed device sends event data to the Firepower Management
Center, based on the configuration of each of the policies.

 The Firepower Management Center contains a database that holds event data that
can be queried within the GUI and by third-party applications.

 Event workflows are used to view event data contextually and can be either
predefined workflows or custom workflows.

Examining Event Types

Description

This lesson examines the most common event types of connection events, malware and file
events, intrusion events, and Security Intelligence events.

Objectives

After completing this lesson, you will be able to do the following:

 Define the most common event types

 Define connection events and their workflows

 Describe Security Intelligence events

 Describe intrusion events and their workflows

 Describe malware and file events and file trajectory

391
 Bootcamp SSFIPS

The graphic shows the same managed device policies and where they are managed. You
can also see where to manage logging decisions, and what events are
generated for each given policy.

The most commonly used events are as follows:

 Connection events—Source: access control policy.

 Security Intelligence events— Source: AC policy Security Intelligence Blacklists.

 Malware and file events— Source: malware and file policy

Intrusion events— Source: intrusion policy

392
 Bootcamp SSFIPS
Connection logs, called connection events, contain data about the traffic on your network.
The system gives you granular control over which connections you log. when
you log them, and where you store the data. You can log any connection except those that
are fast-pathed at the device level before they reach access control, in
particular the following:

 When a connection is blacklisted (blocked) or monitored by the reputation-based

Security Intelligence feature.
 When an encrypted session is handled by an SSL policy.

 When a connection is handled by an access control rule or the access control default
action.

In addition to the logging that you configure, the system automatically logs most connections
where the system detects a prohibited file, mal ware, or intrusion attempt.
Unless you disable connection event storage entirely for the Firepower Management Center,
regardless of your other logging configurations, the system saves these end-
of-connection events to the Firepower Management Center database for further analysis.

The graphic shows a small sample of the connection event workflows and their usage.

393
 Bootcamp SSFIPS
A Security Intelligence event is a connection event that is generated whenever a session is
blacklisted (blocked) or monitored by the reputation-based Security
Intelligence feature.
However, for every Security Intelligence event, there is an identical connection event you
can view and analyze Security Intelligence events independently. The system
also stores and prunes Security Intelligence events separately.

To see these events, you must enable logging, as shown in the graphic. You might recall
that this action was discussed in the module about access control policies.

As with all events, the fields shown in the search component of the Firepower Management
Center are only what are potentially displayed. If that data is not available,
that field is blank. An example is Initiator User, which is displayed only if user data is
integrated with the Firepower Management Center, through an integration with an
active identity source. This is not turned on by default, as you learned in the Firepower
module.

The Firepower System can help you monitor your network for traffic that could affect the
availability, integrity, and confidentiality of a host and its data. By placing
managed devices on key network segments, you can examine the packets that traverse your
network for malicious activity. The system has several mechanisms that it uses
to look for the broad range of exploits that attackers have developed.

394
 Bootcamp SSFIPS

When the system identifies a possible intrusion, it generates an intrusion event, which is a
record of the date, time, the type of exploit, and contextual information about
the source of the attack and its target. For packet-based events, a copy of the packet or
packets that triggered the event is also recorded. Managed devices transmit their
events to the Firepower Management Center, where you can view the aggregated data and
gain a greater understanding of the attacks against your network assets.

You can also deploy a managed device as an inline, switched, or routed intrusion system,
which allows you to configure the device to drop or replace packets that you
know to be harmful.

The system examines the packets that traverse your network for malicious activity that could
affect the availability, integrity, and confidentiality of a host and its data.
When the system identifies a possible intrusion, it generates an intrusion event, which is a
record of the date, time, the type of exploit, and contextual information about
the source of the attack and its target. For packet-based events, a copy of the packet or
packets that triggered the event is also recorded.

When searching this data, keep in mind that your results depend on the available data in the
events you are searching. In other words, depending on the available data,
your search constraints may not apply. For example, only intrusion events triggered on
decrypted traffic contain SSL information.

The following items are important intrusion event fields:

 Inline Result—In workflow and table views, this field displays one of the following:

-A black down arrow, indicating that the system dropped the packet that triggered the rule.

-A gray down arrow, indicating that IPS would have dropped the packet if you had enabled
the Drop When Inline intrusion policy option (in an inline deployment) or if a Drop and
Generate rule had generated the event while the system was pruning.

- Blank, indicating that the triggered rule was not set to Drop and Generate Events.

395
 Bootcamp SSFIPS
The system does not drop packets in a passive deployment, including when an inline
interface is in tap mode, regardless of the rule state or the inline drop
behavior of the intrusion policy.

When searching this field, enter either of the following:

- Dropped to specify whether the packet is dropped in an inline deployment.

- Would have dropped to specify whether the packet would have dropped if the
intrusion policy had been set to drop packets in an inline deployment.

Device—The managed device where the access control policy was deployed.

Snort ID—Specify the Snort ID (SID) of the rule that generated the event or. optionally,
specify the combination Generator ID (GID) and SID of the rule, where the
GID and SID are separated with a colon {:) in the format GID:SID. The SID of the events you
are viewing is listed in the Message column.

The graphic shows a small sample of the intrusion event workflows and their usage. Several
to note are as follows:

 Event-Specific—This workflow provides two useful features. Events that occur

frequently may indicate the following:

- False positives
- A worm
- A badly misconfigured network

Events that occur infrequently are most likely evidence of a targeted attack and warrant
special attention.

 IP-Specific—This workflow shows which host IP addresses are generating the most
alerts. Hosts with the greatest number of events either are public-facing and are
receiving wormlike traffic {indicating a good place to look for tuning) or require further

396
 Bootcamp SSFIPS
investigation to determine the cause of the alerts. Hosts with the lowest
counts also warrant investigation, because they could be the subject of a targeted
attack. Low counts may also indicate that a host may not belong on the
network.

To help you identify and mitigate the effects of malware, the Firepower System's file control,
network file trajectory, and AMP for Firepower components can detect, track,
capture, analyze, log, and optionally block the transmission of files, including mal ware files
and nested files inside archive files.

You can also integrate the system with your organization's AMP for Endpoints deployment to
import records of scans, mal ware detections, and quarantines, as well as
indications of compromise.

The Context Explorer, dashboards, and reporting features can also give you a deeper
understanding of the files and malware detected, captured, and blocked. You can
also use events to trigger correlation policy violations, or alert you by means of email, SMTP,
or syslog.

File Events

The system logs the file events generated when a managed device detects or blocks a file in
network traffic, according to the rules in currently deployed file policies.

397
 Bootcamp SSFIPS
When the system generates a file event, the system also logs the end of the associated
connection to the Firepower Management Center database, regardless of the
logging configuration of the invoking access control rule.

Network-Based Malware Events (AMP for Firepower)

The system can detect malware in network traffic as part of your overall access control
configuration. AMP for Firepower can generate a malware event containing the
disposition of the resulting event, and contextual data about how, where, and when the
malware was detected.

Endpoint-Based Malware Events (AMP for Endpoints)

If your organization uses AMP for Endpoints, individual users install lightweight connectors
on endpoints: computers and mobile devices. Connectors can inspect files
upon upload, download, execution, open, copy, move, and so on. These connectors
communicate with the AMP cloud to determine if inspected files contain malware.

When a file is positively identified as malware, the AMP cloud sends the threat identification
to the Firepower Management Center. The AMP cloud can also send other
kinds of information to the Firepower Management Center, including data on scans,
quarantines, blocked executions, and cloud recalls. The Firepower Management
Center logs this information as malware events.

Retrospective Malware Events (AMP for Firepower)

For malware detected in network traffic, dispositions can change. For example, the AMP
cloud can determine that a file that was previously thought to be dean is now
identified as mal ware, or the reverse—that a malware-identified file is actually dean. When
the disposition changes for a file you queried in the last week, the AMP cloud
notifies the system.

Then two actions occur:

1. The Firepower Management Center generates a new retrospective malware event.

This new retrospective malware event represents a disposition change for all files
detected in the last week that have the same SHA-256 hash value. For that
reason, these events contain limited information: the date and time that the Firepower
Management Center was notified of the disposition change, the new
disposition, the SHA-256 hash value of the file, and the threat name. The events do not
contain IP addresses or other contextual information.

2. The Firepower Management Center changes the file disposition for previously
detected files with the retrospective event's associated SHA-256 hash value.

If a file's disposition changes to Malware, the Firepower Management Center logs a new
malware event to its database. Except for the new disposition, the
information in this new malware event is identical to that in the file event generated when
the file was initially detected.

If a file's disposition changes to Clean, the Firepower Management Center does not
delete the malware event. Instead, the event reflects the change in

398
 Bootcamp SSFIPS
disposition. This means that files with dean dispositions can appear in the mal ware
table, but only if they were originally thought to be malware. Files that were
never identified as malware appear only in the files table.

Clicking the malware and file event displays both a file event and a malware event.

Notice how both events show the event but from different perspectives. Remember that a
malware event is accompanied by a file event.

The network file trajectory feature maps how hosts have transferred files, including malware
files, across your network. A trajectory charts file transfer data, the disposition
of the file, and whether a file transfer was blocked or the file was quarantined. You can
determine which hosts may have transferred malware and which hosts are at risk,
and you can observe file transfer trends.

You can track the transmission of any file with an AMP cloud-assigned disposition. The
system can use information related to detecting and blocking malware from both AMP for
Firepower and AMP for Endpoints to build the trajectory.

399
 Bootcamp SSFIPS
The Network File Trajectory List page displays the mal ware most recently detected on your
network, as well as the files whose trajectory maps you have most recently
viewed. From these lists, you can view when each file was most recently seen on the
network, the file's SHA-256 hash value, name, type, current file disposition, contents
{for archive files), and the number of events associated with the file.

The page also contains a search box that you can use to locate files, based on either the
SHA-256 hash value or the filename, or on the IP address of the host that
transferred or received a file. After you locate a file, you can dick the File SHA256 value to
view the detailed trajectory map.

400
 Bootcamp SSFIPS

Lesson Summary

In this lesson, you learned the following:

 Common event types include connection events, Security Intelligence events,

intrusion events, and malware and file events.

 Connection events contain traffic data on your network.

 Security Intelligence events, which are part of connection events, are from the
Security Intelligence section of Firepower.

 Intrusion events are generated when a Snort rule is triggered on traffic.

 Malware and file events are generated when a file rule is triggered within a malware
and file policy.

401
 Bootcamp SSFIPS

Examining Contextual Data

Description

This lesson explores how the Firepower Management Center provides contextual data to the
analyst by using priority and classification hard-coded into the Snort rules. This
lesson also describes the automatic generation of impact flags.

Objectives

After completing this lesson, you will be able to do the following:

 Describe the priority and classification of rules

 Describe and compare impact flags

 Identify the impact flag and intrusion event workflows

 Describe indications of compromise

402
 Bootcamp SSFIPS

Cisco Talos puts Snort rules into a classification. The classification gives the analyst context
and information about what the rule was addressing. Understanding the
classifications is a valuable way for the analyst to gain more insight into the potential severity
of the attack or attempted attack.

The classification field in the intrusion event is where the rule that generated the event
belongs.

When searching this field, enter the classification number, or all or part of the classification
name or description, for the rule that generated the events that you want to
view. You can also enter a comma-separated list of numbers, names, or descriptions.
Finally, if you add a custom classification, you can also search by using all or part of
its name or description. If you look at the Snort rule, the classification is located under the
classtype keyword, as shown in the graphic.

The graphic illustrates the event priority as determined by the Cisco Talos Security
Intelligence and Research Group {Talos). The priority corresponds to either the value of
the priority keyword or the value for the classtype keyword.

403
 Bootcamp SSFIPS

For other intrusion events, the priority is determined by the decoder or preprocessor. Valid
values are high, medium, and low.

The intrusion event workflow "Priority and Classification" is very valuable to the analyst for
looking at intrusion events based on the importance of the rule that the traffic
triggered according to Cisco Talos. This workflow lists events and their types in order of
event priority, along with a count showing how many times each event has
occurred.

One of the most valuable tools in the analyst's toolkit is the impact flag indicator. You will see
these for your intrusion events; they immediately indicate whether an event
is potentially a real event or a false positive. To help you evaluate the impact that an event
has on your network, the Firepower Management Center displays an impact
level in the table view of intrusion events. For each event, the system adds an impact-level
icon, whose color indicates the correlation between intrusion data, network
discovery data, and vulnerability information.

404
 Bootcamp SSFIPS

The graphic describes Impact 0 events. There are intrusion events where neither the source
or destination IP address is within the range of IP addresses that belong to
your enterprise. This score occurs in only one of two conditions. Either you have chosen not
to profile your entire enterprise or you are seeing intrusion events within your
enterprise that are using IP addresses that are not supposed to be working within your
network. This situation is a critical condition and should probably be investigated.

A score of Impact 4 is applied to intrusion events when the either the source or destination
IP address of a host is within the defined IP range of your network but has not
been seen before {that is. there is no current host profile for the device). These events are
usually very low in number. They usually show up only when new sections of a
network are being brought online, and they quickly change. Why? Seeing traffic from a host
means that you can start profiling the host for contextual analysis.

405
 Bootcamp SSFIPS

In an Impact 3 event, either the source or destination IP address is associated with a host
profile. It does not necessarily mean, however, that a connection event has
occurred. In fact, most Impact 3 events are outbound. The source host is an internal device
(profiled) connecting to an external device (not profiled). This is true of TCP
traffic. You may see some Impact 3 events if a new server process has started responding
on a host. In most cases, an inbound Impact 3 event means that a connection
attempt with a specific exploit may have tried to touch a host but no connection was made.

The Impact 3 example shown in the graphic is an internally sourced intrusion event that
warrants immediate investigation. Impact 3 typically signifies a compromised host
and often can lead to the exfiltration of data.

406
 Bootcamp SSFIPS
A score of Impact 2 is applied when an event not only has an IP address match but also
could have actually connected to a working service on the host {that is. "I reached
out to a web server, it responded, and we're talking"). In these cases, the threat actually
targeted and {if not blocked) landed against the victim host.

The graphic shows an example of an Impact 2 event.

Traditionally, Impact 1 is where the analyst must start investigating whether the host could
have been compromised. The analyst must pull asset information regarding the
host, validate the current operating system, understand the nature of the exploit launched
against it, and then decide whether it merits further forensic investigation. This
process is time-consuming, and it is the reason that organizations falsely focus on only high-
priority events.

However, Cisco automates the process, based on an understanding of the potential

weaknesses of assets on the network. Therefore, if a potential vulnerability exists for a
host. Firepower will match the intrusion event's Snort ID with the vulnerability that was being
targeted. If there is a match, the system gets a level 1 flag. Think of this
situation as a NetBIOS attack against a Windows server versus a Linux Samba server. Both
platforms respond to the protocol, but only the Windows host could have been
successfully compromised.

407
 Bootcamp SSFIPS
The other Impact 1 condition is an indication of compromise. This event is almost always
launched from a compromised host (so. usually your internal asset is the source
IP). In the detection scenario, however, the host is revealing conditions that have shown it to
be already compromised. In these cases, these events are automatically
scored with an Impact 1 flag to focus remediation efforts.

The intrusion event workflows that can be valuable to the analyst include Impact flags.
Remember that Impact flags look at the relevancy of the event. Impact flags can
provide immediate visibility into whether an event is a real event or a false positive.

 Impact and Priority—This workflow lets you find high-impact recurring events
quickly. The reported impact level is shown with the number of times that the event
has occurred. Using this information, you can identify the high-impact events that
recur most often, which might be an indicator of a widespread attack on your
network.

 Impact and Source—This workflow can help you identify the source of an attack in
progress. The reported impact level is shown with the associated source IP
address for the event. If. for example, events with a level 1 impact are coming from
the same source IP address repeatedly, they may indicate an attacker who has
identified vulnerable systems and is targeting them.

 Impact to Destination—You can use this workflow to identify events repeatedly

occurring on vulnerable computers, so that you can address the vulnerabilities on
those systems and stop any attacks in progress.

408
 Bootcamp SSFIPS

Impact to Destination, as an example, can be a valuable workflow for the analyst to organize
events by the highest impact. This example also looks at events from the
least likely false-positive events first.

The Firepower System uses indication of compromise (IOC) rules in the network discovery
policy to identify a host as likely to be compromised by malicious means. When
a host meets the conditions specified in these system-provided rules, the system tags it with
an indication of compromise (IOC). The related rules are known as IOC rules.
The IOC tags specify the nature of the likely compromise.

The Firepower Management Center can tag a host when one of the following actions occurs:

 The system correlates data gathered about your monitored network and its traffic by
using intrusion. Security Intelligence, and malware events, and determines
that a specific host should be tagged with an IOC.

 The Management Center can import IOC data from your AMP for Endpoints
deployments by means of the AMP cloud. Because this data examines activity on a
host itself—such as actions taken by or on individual programs—it can provide
insights into possible threats that network-only data cannot provide. For your
convenience, the Management Center automatically obtains from the AMP cloud any
new IOC tags that Cisco develops.

409
 Bootcamp SSFIPS
You can view and work with IOC data in several parts of the Firepower System web
interface. However, keep in mind that because IOC rules are triggered based
on data provided by other components of the Firepower System and by AMP for Endpoints,
those components must be correctly licensed and configured for IOC
rules to set IOC tags.

 Connection. Security Intelligence, intrusion, malware, and IOC discovery event views
indicate whether an event has triggered an IOC. IP addresses that represent
IOC-tagged hosts are tagged with a compromised host icon instead of the normal
host icon. Note that endpoint-based malware events that trigger IOC rules have
the event type AMP IOC and appear with an event subtype that specifies the
compromise.

 In the dashboard, the Threats tab of the Summary dashboard displays, by default.
IOC tags by host and new IOC rules triggered over time. The Custom Analysis
widget offers presets based on IOC data.

 The Indications of Compromise section of the Context Explorer displays graphs of

hosts by IOC category and displays IOC categories by host.

 You can write correlation rules against IOC data.

 The Indications of Compromise tab lists monitored hosts, which are grouped by IOC
tag.

 In the host profile view for a potentially compromised host, you can view all IOC tags
associated with that host, resolve any or all of its IOC tags, and configure
IOC rule states.

The graphic shows the Security Intelligence engine indications of compromise.

410
 Bootcamp SSFIPS
Lesson Summary

In this lesson, you learned the following:

 A Snort rule classification is determined by Talos, is hardcoded into the Snort rule,
and has an associated priority that indicates whether the rule is high or low
priority.

 Impact flags range from 0 to 4 and are used to help determine whether the event is a
false positive or a successful attack.

 Impact flag workflows allow intrusion event analysis to be correlated with the impact
to either the source or the destination, or to be correlated with the priority on the
Snort rule.

 Indications of compromise are automatically created in the Firepower Management

Center to correlate event types together so that the analyst has a context to help
determine whether a host is compromised.

411
 Bootcamp SSFIPS
Examining Analysis Tools

Description

This lesson explores the Firepower Management Center's analysis tools, including the
Context Explorer, dashboards, and the reporting engine.

Objectives

After completing this lesson, you will be able to do the following:

 Describe the Context Explorer

 Describe dashboards

 Describe the reporting feature

 Describe the typical analysis workflow when starting from Context Explorer

412
 Bootcamp SSFIPS

The Firepower System Context Explorer displays detailed, interactive graphical information
in context about the status of your monitored network, including data on
applications, application statistics, connections, geolocation, indications of compromise,
intrusion events, hosts, servers. Security Intelligence, users, files (including
mal ware files), and relevant URLs. Distinct sections present this data in the form of vivid
line, bar, pie, and donut graphs, accompanied by detailed lists.

The first section, a line chart of traffic and event counts over time, provides an at-a-glance
picture of recent trends in your network's activity.

You can easily create and apply custom filters to fine-tune your analysis, and you can
examine data sections in more detail by simply clicking or hovering your cursor over
graph areas. You can also configure the Explorer's time range to reflect a period as short as
the last hour or as long as the last year. Only users with the Administrator.
Security Analyst, or Security Analyst (read-only) user roles have access to the Context
Explorer.

The data displayed depends on such factors as how you license and deploy your managed
devices, and whether you configure features that provide the data. You can
also apply filters to constrain the data that appears in all Context Explorer sections.

The Context Explorers Indications of Compromise view is a recommended place for the
analyst to start. Remember that indications of compromise correlate not only

413
 Bootcamp SSFIPS
intrusion events that are detected on your hosts, but other potentially malicious or suspicious
events as well.

The Firepower System dashboard provides you with at-a-glance views of current system
status, including data about the events collected and generated by the system.
You can also use the dashboard to see information about the status and overall health of the
appliances in your deployment. Only certain user roles {Administrator.
Maintenance User. Security Analyst. Security Analyst [read-only], and custom roles with the
Dashboards permission) have access to the dashboard. Other roles see as their
default start pages a page relevant to the role; for example, a Discovery Admin sees the
Network Discovery page.

Dashboards are available on Firepower Management Center and 7000 and 8000 Series
devices only.

NGIPSv devices and ASA FirePOWER modules do not have a web interface and do not
support dashboards.

A dashboard is composed of tabs that display widgets. Widgets are small, self-contained
components that provide insight into various aspects of the Firepower System.
The Firepower System is delivered with several predefined dashboard widgets. For example,
the Appliance Information widget tells you the appliance name, model,
remote manager, and currently running version of the Firepower System software.

The dashboard has a time range that constrains its widgets. You can change the time range
to reflect a period as short as the last hour or as long as the last year.

By default, the home page for your appliance displays a predefined dashboard, the
Summary Dashboard. You can also use the Overview>Dashboards menu to
navigate to the Summary Dashboard or, on Management Centers, other predefined
dashboards. The Firepower System dashboard is highly customizable and
compartmentalized, and it is updated in real time. In contrast, the Context Explorer is
manually updated and is designed to provide broader context for its data. It has a
single, consistent layout designed for active user exploration.

The data that is displayed depends on such factors as how you license and deploy your
managed devices, whether you configure features that provide the data, and
whether the appliance supports a feature that provides the data.

414
 Bootcamp SSFIPS
Unless you have Administrator access, you can see only your own private dashboards; you
cannot view or modify private dashboards created by other users. In a
multidomain deployment, you cannot view dashboards from ancestor domains; however, you
can create new dashboards that are copies of the higher-level dashboards.

You use the dashboard to monitor real-time activity on your network and appliances
according to your own specific needs.

Conversely, you use the Context Explorer to investigate a predefined set of recent data in
granular detail and dear context. For example, if you notice that only 15
percent of hosts on your network use Linux, but they account for almost all YouTube traffic,
you can quickly apply filters to view data only for Linux hosts, only for
YouTube-associated application data, or both. Unlike the compact. narrowly focused
dashboard widgets, the Context Explorer sections are designed to provide striking
visual representations of system activity in a format that is useful to both expert and casual
users of the Firepower System.

Dashboard Widgets

A dashboard has one or more tabs, each of which can display one or more widgets in a
three-column layout.

The Firepower System is delivered with many predefined dashboard widgets, with each
widget providing insight into a different aspect of the Firepower System. Widgets
are grouped into three categories:

 Analysis & Reporting widgets display data about the events collected and generated
by the Firepower System.

 Miscellaneous widgets display neither event data nor operations data. Currently, the
only widget in this category displays an RSS feed.

 Operations widgets display information about the status and overall health of the
Firepower System.

The dashboard widgets that you can view depend on the following:

 Type of appliance you are using

415
 Bootcamp SSFIPS
 Your user role

 Your current domain (in a multidomain deployment)

In addition, each dashboard has a set of preferences that determines its behavior.

You can minimize and maximize widgets, add and remove widgets from tabs, and rearrange
the widgets on a tab.

Custom Analysis Widget

The Custom Analysis widget is a highly customizable widget that allows you to display
detailed information on the events collected and generated by the Firepower
System.

The Custom Analysis widget is delivered with numerous widget presets, which are groups of
configurations that are predefined by Cisco. The presets serve as examples
and can provide quick access to information about your deployment. You can use these
presets or create a custom configuration.

When you configure the widget preferences, you must specify which table and individual
field you want to display, as well as the aggregation method that configures how
the widget groups the data that it displays.

For example, you can configure the Custom Analysis widget to display a list of recent
intrusion events by configuring it to display data from the Intrusion Events table.
Choosing the Classification field and aggregating this data by count tells you how many
events of each type were generated. Note that the count includes reviewed
events for intrusion events; if you view the count in an event viewer, it will not include
reviewed events.

However, aggregating by unique events tells you how many unique intrusion events of each
type have occurred {for example, how many detections of network Trojans,
potential violations of corporate policy, attempted denial-of-service attacks, and so on).

Optionally, you can further constrain the widget by using a saved search, either one of the
predefined searches delivered with your appliance or a custom search that you
created. For example, if you use the Dropped Events search to constrain the first example
{intrusion events using the Classification field and aggregated by count), you
can see how many intrusion events of each type were dropped.

The colored bars in the widget background show the relative number of occurrences of each
event (read the bars from right to left). You can change the color of the bars,
as well as the number of rows that the widget displays. You can also configure the widget to
display the most frequently occurring events or the least frequently occurring
events.

The direction icon indicates and controls the sort order of the display. A downward-pointing
icon indicates descending order; an upward-pointing icon indicates ascending
order. To change the sort order, click the icon.

416
 Bootcamp SSFIPS

The Firepower Management Center contains three types of data:

 Security-related data

 Operations-related data

 Compliance-related data

You can run reports against all these types of data.

Firepower Management Center Reporting Engine

The Firepower System provides a flexible reporting system that allows you to quickly and
easily generate multisection reports with the event views or dashboards that
appear on your Firepower Management Center.

You can also design your own custom reports.

A report is a document file formatted in PDF, HTML, or CSV with the content that you want
to communicate. A report template specifies the data searches and formats for
the report and its sections. The Firepower System includes a powerful report designer that
automates the design of report templates. You can replicate the content of any
event view table or dashboard graphic that is displayed in the web interface.

417
 Bootcamp SSFIPS
You can build as many report templates as you need. Each report template defines the
individual sections in the report and specifies the database search that creates the
report's content, as '.veil as the presentation format (table, chart, detail view, and so on) and
the time frame. Your template also specifies document attributes, such as the
cover page and table of contents and whether the document pages have headers and
footers (available only for reports in PDF format). You can export a report template
in a single configuration package file and import it for reuse on another Firepower
Management Center.

You can include input parameters in a template to expand its usefulness. Input parameters
allow you to produce tailored variations of the same report. When you
generate a report with input parameters, the generation process prompts you to enter a
value for each input parameter. The values that you type constrain the report
contents on a one-time basis. For example, you can place an input parameter in the
destination IP field of the search that produces an intrusion event report; at report
generation time, you can specify a department's network segment when prompted for the
destination IP address. The generated report then contains only information
concerning that particular department.

You use report templates to define the content and format of the data in each of the report's
sections, as well as the document attributes of the report file (cover page,
table of contents, and page headers and footers).

After you generate a report, the template stays available for reuse until you delete it.

Your reports contain one or more information sections. You choose the format (text, table, or
chart) for each section individually. The format that you select for a section
may constrain the data that can be included. For example, you cannot show time-based
information in certain tables by using a pie chart format. You can change the
data criteria or format of a section at any time to obtain optimum presentation.

You can base a report's initial design on a predefined event view, or you can start your
design by importing content from any defined dashboard, workflow, or summary.
You can also start with an empty template, adding sections and defining their attributes one
by one.

418
 Bootcamp SSFIPS
Firepower Management Center Reporting Engine Best Practices

It is a best practice to know what you intend to report on. and ensure that you are retaining
this information initially and that the information is not being lost before your
reporting cycles.

As an example, suppose that you decide to report on connection event data. This data in
your Firepower Management Center is first-in-first-out every 5 days. You would
then need to ensure that you are running your reports at least once every 5 days.

Building Reports from Dashboards

Using Report Designer in your dashboards, you can send the data directly to the reporting
engine in your Firepower Management Center. This action is especially useful,
because you likely will use dashboards to see your events and relevant system information.
With this feature, you can simply dick and build your report from the report
designer. Both systems use the same Firepower Management Center database. The

419
 Bootcamp SSFIPS
dashboard widgets have almost 120 preset reports already built in. which is why it is so
valuable to have the dashboard lead you to the reporting engine.

In the example in the graphic, you can see how you might determine a way to approach your
events.

Back to Context Explorer—A Starting Point

From the Context Explorer, you can link directly into the events that you might want to look
at first. The IOC component of Context Explorer is a recommended place to
start for analysis for many networks.

420
 Bootcamp SSFIPS

When you choose Drill into Analysis, the appropriate workflow for that data is displayed.
Here you see 76 counts of the IOC, which indicates an exploit kit. This situation
can be potentially very bad in terms of a security breach. Clicking Table View displays the
entire data set that is available in the table.

Indications of Compromise—Table View

The graphic shows the table view. From here, you can see that the events are coming from
six hosts.

Indications of Compromise—Badly Infected Host

421
 Bootcamp SSFIPS
The graphic shows the host profile for one of the six affected hosts. Here you see the
various IOC sources. This is an example of a badly infected host.

422
 Bootcamp SSFIPS
Lesson Summary

In this lesson, you learned the following:

 Context Explorer is a feature in the Firepower Management Center that allows for
detailed, graphical, and interactive analysis.

 Dashboards are views of current system status, ranging from event data to system
and health status.

 The Reporting engine is designed to allow simplified reporting by providing access to

the event tables stored in the Firepower Management Center. The Reporting
engine also allows for integration with other event data analysis sections, including
dashboards.

 Context Explorer is a valuable tool for investigating a breach, because it offers a

context-sensitive way to navigate to additional analysis sections, such as workflows
and the event tables.

423
 Bootcamp SSFIPS
Tuning Intrusion Events

Description

This lesson details the process of intrusion event tuning. It also examines the intrusion event
classifications and actions that are likely if the event is a true positive or a false
positive.

Objectives

After completing this lesson, you will be able to do the following:

 Identify the four classifications of intrusion events.

 Identify the intrusion event workflow process.

 Describe the options that are available when a true-positive intrusion event occurs.

 Describe the options for tuning a false-positive intrusion event.

424
 Bootcamp SSFIPS

When you view events in the Firepower Management Center, the flowchart can be helpful to
start. When working through intrusion events, be sure that you first understand the
four potential types of events.

When you view events in the Firepower Management Center, this flowchart can be helpful
as a starting point.

While the focus of the event analysis process is (with good reason) determining whether an
event indicates a serious security threat, the process does not end after this
question is answered. The secondary question, for you to consider whenever you conclude
that an event is not a security threat, is whether the event presents any useful
information.

If an event is not a security threat, and does provide useful information, the analysis is
complete. Select another event and begin again. This time is the only time that it
is acceptable to analyze an event and then do nothing.

This event can happen, for example, with some informational or policy rules. A given alert
may not indicate a security threat, but could give you a more detailed picture
when paired with other alerts. In that case, it could be identified as useful information, even
when it is not a security threat.

If an event is not a security threat and does not provide useful information, you need to tune
out that event so that further such useless events do not burden later analysis.
If an event is found to add no value, you must take some action to maintain efficient and
useful alerting.

425
 Bootcamp SSFIPS
As mentioned earlier, the only time when it is acceptable to analyze an IPS event and then
do nothing to resolve it is when the event does not indicate a security threat
and is still useful information. If an event is a security threat, the system must be tuned,
following the organization's procedures. If an event adds no value, it must be
tuned out.

True positives are events that are identified as accurately generated. These events are the
first to be addressed.

A false positive is an event that has been determined to not be a true event, such as when
an event is triggered on a host that was not vulnerable to the attack. The
following are options to take on the rule to alleviate recurring false positives:

 Disable the rule.

 Suppress or threshold the rule.

 Write a Pass rule.

426
 Bootcamp SSFIPS

A false positive is an event that has been identified as not a true event, such as when an
event is triggered on a host that was not vulnerable to the attack. This topic
discusses options that you can take on the rule to alleviate recurring false positives.

Disabling a Rule

Disabling a rule involves changing the rule's state from Generate Events or Drop and
Generate Events to Disabled. When this action is completed and the policy is
reapplied, the detection engine no longer loads this rule. Traffic will no longer be analyzed to
match it and the console will show no alerts for it. This action is necessary
if the alert does not pertain to your environment. Obvious examples include disabling all
rules that look for Linux vulnerabilities for networks running only Windows. This
can also apply to software versions. If an organization has been entirely updated to the latest
version of Internet Explorer, then rules for vulnerabilities in IE6 or IE7 can be
disabled.

Suppressing a Rule

Suppression is the ability to shut off an event for a rule. This action can be appropriate for an
entire rule, or can be based on specific IP addresses (or a classless
interdomain routing [CIDR] block) as a source or destination. This action stops events from
being created without removing the rule from the detection engine.

While you have the option to suppress an entire rule, it is strongly suggested that the rule be
disabled instead. A totally suppressed rule is still loaded into the rules
engine, and traffic is still analyzed to match it, but only the event is disabled. Disabling the
rule has the same visible effed without burdening the detection engine with
loading the rule and analyzing traffic to match it.

Suppression by source or destination, however, is an excellent way to filter out false-positive

and useless events. For example, consider an IPS analyst who wants to alert
on Simple Network Management Protocol (SNMP) community strings that are inbound to the
network. By enabling the SNMP community string rule within the detection
engine, this rule will alert on legitimate SNMP traffic going to their SNMP collector. By adding
a suppression with a destination of the collector, this legitimate traffic does not create alerts
but the rule is left to run on illegitimate SNMP traffic.

427
 Bootcamp SSFIPS
Thresholding a Rule

Thresholding is a particular action that causes a rule to not alert as much. While it is similar
to suppression, the key difference is that suppression stops all alerts for a given
rule or IP range. Thresholding is used to limit the volume of alerts that are created by a rule.

Thresholding is used to reduce the number of logged alerts for noisy rules. It can be used to
significantly reduce false-positive or useless alerts by limiting the number of
times that a particular event is logged during a specific time interval.

There are three types of event thresholding: Limit, Threshold, and Both. Each of these types
takes the same options: Track By {source or destination), Count, and Seconds.

 Limit—This type of event thresholding limits the number of times that a particular
alert is created during a specified time interval. This type limits the number of
alerts (Count) during a certain time period (Seconds) by either source or destination
(Track By) and stops creating alerts when this level is acceptable. For
example, if Limit is set with a Count of 25 and Seconds is set to 60. and the rule is
triggered 30 times in 1 minute, only the first 25 will generate events.

If there is a rule that alerts whenever a host infected with a particular worm tries to infect
another host, even one infection could lead to thousands of alerts. In this
case, a limit by source will prevent the console from being overwhelmed and show the
analyst the information that is necessary for responding {such as the source
IP).

 Threshold—This type is for acknowledging an acceptable level of traffic that would

otherwise create an alert. With a threshold, no alert will be created unless the
sensor sees more than a certain number of alerts (Count) in a certain time period
(Seconds) by either source or destination (Track By).

For example, a rule has a threshold set for a count of 10, for 30 seconds, and then 12
matching packets are detected within 30 seconds. In this case, only one
alert is created in the console. If there were 20 matching packets in the time frame in
question, the user would receive two alerts.

 Both—This type sets both a Limit and Threshold type for a given rule, so that a
single event is created only in the given time period after the count is exceeded.
For example, a rule has a threshold for a count of 10, for 30 seconds, and then 12
matching packets are detected within 30 seconds. In this case, only one alert is
created in the console.

Additionally, there is Global Thresholding, which allows the sensor to specify a general
threshold for every rule. Thresholds that are added to a specific rule always
override this setting. You can configure thresholding in the IPS intrusion policy by
selecting a policy layer or Advanced Settings and then enabling Global Rule
Thresholding.

428
 Bootcamp SSFIPS
Pass Rule

A Pass rule is the ultimate tool for tuning out false-positive and useless alerts. It allows the
robust rules language to describe what not to alert on. A typical rule has the
action set to Alert, or perhaps Drop. A rule with an action of Pass, when detecting a packet
matching the rule, stops analyzing it and passes it through the system.

Because all Pass rules are processed before any Alert or Drop rules, any traffic passed will
never trigger an alert. This setting allows users to use the rules language to pass
on any conceivable traffic that may be cluttering up their console. This case is a specific
case of editing a rule, and all the caveats that are discussed in the preceding
section apply here as well. If the tuning that you require can be accomplished with threshold
or suppression, those tools should be used instead.

The most common use of Pass rules is to filter out specific traffic from one host to another
host. Suppression can be used to block alerts from a given host or to a given
host, but not both. If a particular rule is firing only between two IPs, you can filter it by editing
the rule, setting the action to Pass, adding these specific IPs for the source
and destination, and then saving the rule, enabling the rule, and pushing policy.

429
 Bootcamp SSFIPS
Lesson Summary

In this lesson, you learned the following:

 Intrusion events fall into one of four possible classifications, from being a true event,
where the event accurately represented the attack, to being a false positive,
where the event did not accurately represent the attack.

 Tuning intrusion events involves a workflow that looks at the usefulness and potential
accuracy of the event.

 With a true positive, where the intrusion event is a security event, there are tuning
options, such as setting the associated rule to drop the traffic.

 With a false positive, where the intrusion event is not a true event, you have options
for preventing further false positives, including disabling or suppressing the
offending rule.

430
 Bootcamp SSFIPS
Examining External Alerting

Description

This lesson introduces you to the external alerting options that are available in the Firepower
System.

Objectives

After completing this lesson, you will be able to do the following:

 Define external alerts in the Firepower Management Center

 Describe the default alert types

 Explain correlation policy alerting

431
 Bootcamp SSFIPS

The events that you have learned about in this module can also generate alerts. You have
the option of generating alerts in one of three formats: SNMP, email, or syslog.

You can configure alerts by selecting Policies > Actions > Alerts > Create Alert. You have
the following options:

 Create Email Alert, to specify which email addresses and relay host to use for the
alerts

 Create SNMP Alert, to specify the details of the trap server that you want to forward
the alerts to

 Create Syslog Alert, to specify the details of the syslog server that you want to
forward the alerts to

When configuring alerting, you also need an alert trigger. The Firepower Management
Center includes a number of default alert triggers, as shown in the graphic. You
can also create custom triggers.

432
 Bootcamp SSFIPS

The first step in configuring external alerting is to create an alert response, which is a set of
configurations that allows the Firepower System to interact with the external
system where you plan to send the alert. You can create alert responses to send alerts by
means of email, a Simple Network Management Protocol (SNMP) trap, or a
system log (syslog).

The information that you receive in an alert depends on the type of event that triggered the
alert. For example, an impact flag alert contains time stamp, intrusion rule,
impact flag, and event description information. As another example, discovery event alerts
also contain time stamp and description information, as well as discovery event
type information.

If you are using an alert response in a correlation policy, the information in the alert depends
on the type of event that triggered the correlation policy violation.

When you create an alert response, it is automatically enabled. Only enabled alert
responses can generate alerts. To stop alerts from being generated, you can
temporarily disable alert responses rather than delete your configurations.

You manage alert responses on the Alerts page (Policies > Actions > Alerts). The slider
next to each alert response indicates whether it is active; only enabled alert
responses can generate alerts. The page also indicates whether the alert response is being
used in a configuration—for example, to log connections in an access control
rule. You can sort alert responses by name, type, in-use status, and enabled/disabled status
by clicking the appropriate column header; dick the column header again to
reverse the sort.

In a multidomain deployment, you can create alert responses for the current domain only. In
addition, you can configure alerts for events occurring in the current domain
only. However, you can choose an alert response from an ancestor domain when
configuring the alert. This action allows you to notify administrators in ancestor domains
for specific events occurring in descendant domains.

433
 Bootcamp SSFIPS

The Firepower System includes the following default alert triggers:

 Impact Flag Alerts—You can configure the system to alert you whenever an
intrusion event with a specific impact flag occurs.

Impact flags help you evaluate the impact that an intrusion has on your network, by
correlating intrusion data, network discovery data, and vulnerability
information.

 Discovery Event Alerts—You can configure the system to alert you whenever a
specific type of discovery event occurs.

 Advanced Malware Protection Alerts—You can configure the system to alert you
whenever any network-based malware event, including a retrospective event, is
generated. You cannot, however, alert on endpoint-based (AMP for Endpoints)
malware events.

 Intrusion Email Alerts—While the Firepower System provides various views of

intrusion events within the web interface, some enterprises prefer to define external
intrusion event notification to facilitate constant monitoring of critical systems. If you
want to immediately notify a specific person of critical events, you can set up
email alerts to do so. You can also enable logging to syslog facilities or send event
data to an SNMP trap server.

Within each intrusion policy, you can specify intrusion event notification limits, set up
intrusion event notification to external logging facilities, and configure external
responses to intrusion events.

Some analysts prefer not to receive multiple alerts for the same intrusion event, but want to
control how often they are notified of a given intrusion event. You can create
event thresholds for a rule, which limit how often an event is generated in a time period. You
can also suppress a rule's event generation.

In a multidomain deployment, you can configure external alerting in any domain. In ancestor
domains, the system generates notifications for intrusion events in
descendant domains.

434
 Bootcamp SSFIPS

You can use the correlation feature to respond in real time to threats to your network with the
use of correlation policies. A correlation policy violation occurs when the
activity on your network triggers a correlation rule or compliance whitelist within an active
correlation policy.

When a correlation rule in an active correlation policy triggers, the system generates a
correlation event. Correlation rules can trigger when either of the following occurs:

 The system generates a specific type of event (connection. intrusion, malware,

discovery, user activity. and so on).

 Your network traffic deviates from its normal profile.

Introduction to Remediations

A remediation is a program that the Firepower System runs in response to a correlation

policy violation.

When a remediation runs, the system generates a remediation status event. Remediation
status events include details such as the remediation name, the correlation
policy and the rule that triggered it, and the exit status message.

The system provides several remediation types, also called modules:

 Cisco IOS Null Route—Blocks traffic sent to a host or network involved in a

correlation policy violation {requires Cisco IOS Version 12.0 or later).

 Cisco PIX Shun—Blocks traffic sent from a host involved in a correlation policy
violation (requires Cisco PIX® Firewall Version 6.0 or later).

 Nmap Scanning—Scans hosts to determine running operating systems and servers.

 Set Attribute Value—Sets a host attribute on a host involved in a correlation policy

violation.

435
 Bootcamp SSFIPS
Lesson Summary

In this lesson, you learned the following:

 External alerting allows you to send alerts by means of syslog, email, or SNMP to an
external source when certain event conditions occur.

 Several default alert triggers are provided in the Firepower Management Center by
default for the most common events, such as impact flags and intrusion events.

 Correlation policies allow alerts to be created for advanced conditions and for
complex conditions to trigger a response, which can be an alert or a remediation.

436
 Bootcamp SSFIPS
SecureBank Scenario—Detailed Analysis

The graphic shows the solutions to the requirements outlined for SecureBank at the
beginning of this module.

437
 Bootcamp SSFIPS
Module Summary for “Detailed Analysis Techniques”

In this module, you learned the following:

 Event analysis is performed by querying the SQL database on the Firepower

Management Center, and allows for contextual viewing of this data by means of
workflows.

 The most common event types are connection events, file and malware events,
intrusion events, and Security Intelligence events.

 Firepower provides the analyst with contextual information to assist with a breach
investigation, including hardcoded priority and classifications for the Snort rules and
the system's automated impact flag generation.

 Analysis tools that are available in the Firepower System are the Context Explorer,
dashboards, and reporting.

 Tuning intrusion events involves a workflow that looks at the usefulness and potential
accuracy of the event.

 External alerting allows you to send alerts by means of syslog, email, or SNMP to an
external source when certain event conditions occur. Correlation policies provide
advanced alerting functions, including remediation.

438
 Bootcamp SSFIPS
Knowledge Check

Q1) You can query the SQL tables that hold event data in the managed device, allowing for
third-party tools (or example. Crystal Reports) to analyze these events.
(Source: Overview of Event Analysis).

Q2) If logging is not enabled for a connection that resulted in an intrusion event, a
connection event is automatically generated. (Source: Examining Event Types)

Q3) An Impact flag of 4 (where the host is in the network discovery range but does not
contain a host profile yet) is often seen when a new network segment'
discovered. (Source: Examining Contextual Data)

Q4) Reports can be generated in the Firepower Management Center up to one month prior
to running the report, regardless of the event type you are querying.
(Source: Examining Analysis Tools)

Q5) It is always best to suppress intrusion events that are considered to be a false positive,
to prevent repeated events that are not true events. (Source: Tuning
Intrusion Events)

Q6) Events can be configured in the Firepower Management Center to send alert responses
by means of syslog, email, or SNMP. (Source: Examining External
Alerting)

439
 Bootcamp SSFIPS
Module 13: System Administration

Overview

Description

This module introduces the administration components of the Firepower Management

Center and managed device. In this module, you will examine system administration, health
monitoring, update management, and user account management.

Objectives

Upon completing this module, you will be able to able to describe key Firepower
Management Center system administration and user account management features. This
ability includes being able to meet these objectives:

• Describe the concepts of system configuration and health monitoring

• Identify Firepower System software update types and explain how they are implemented

• Describe the user management options for the Firepower Management Center

• Describe how to configure user accounts

440
 Bootcamp SSFIPS
SecureBank Scenario

SecureBank Scenario-System Administration

This module describes the system administration features that you can use to address the
scenario in the graphic.

441
 Bootcamp SSFIPS

Examining System Configuration and Health Monitoring

Description

This lesson provides an overview of the system configuration capabilities of both the
Firepower Management Center and the managed device, and explores the health-monitoring
systems that are designed as automatic health indicators in both the Firepower Management
Center and the managed device.

Objectives

After completing this lesson, you will be able to do the following:

• Identify system configuration settings for the Firepower Management Center and the
managed device

• Describe the system settings for the Firepower Management Center and identify the most
commonly configured settings

• Describe the system settings for managed devices

• Describe heath monitoring in the Firepower System

System configuration Basics

System configurator settings apply to either a Firepower Management Center or a Classic

managed device (7000 and 8000 Series, ASA FirePOWER. and NGIPSv):

• For the Firepower Management Center, these configuration settings are part of a "local”
system configuration. Note that system configuration on the Firepower Management Center
is specific to a single system, and changes to a Management Center's system configuration
affect only that system.

442
 Bootcamp SSFIPS
• For a Classic managed device, you apply a configuration from the Firepower Management
Center as part of a platform settings policy. You create a shared policy to configure a subset
of the system configuration settings, appropriate for managed devices that are likely to be
similar across a deployment.

Various system settings are management differently, depending on whether they apply to
the Firepower Management Center or to the managed device. For managing the Firepower
Management Center you use the System-Configuration menu. Note that this menu was
called System Policy in versions prior to 6.0. For managing the managed device, you use the
Platform Settings menu in the Firepower Management Center. This menu is located under
Devices > Platform Settings. The 7000 and 8000 Series Firepower devices have additional
settings, which are managed in the web interface of those managed devices.

Firepower Management Center System Configuration Settings

To manage the Firepower Management Center settings, complete the following procedure:

Step 1

Select System > Configuration

Step 2

From the navigation panel, choose the configurations that you want to change.

In the next few graphics, you will see a few of the most commonly used settings and how
they are configured. For a full list of the settings and how to configure them, refer to the
Firepower Management Center configuration guide:

443
 Bootcamp SSFIPS
Change Reconciliation

To monitor the changes that users make and to ensure that hey follow your organization’s
preferred standard, you can configure the system to send, by means of email a detailed
report of changes made over the past 24 hours.

Whenever a user saves changes to the system configuration, a snapshot is taken of the
changes. The change reconciliation report combines information from these snapshots to
present a clear summary of recent system changes.

The following sample graphic displays a User section of an example of a change

reconciliation report and lists both the previous value for each configuration and the value
after changes. When users make multiple changes to the same configuration, the report lists
summaries of each distinct change in chronological order, beginning with the most recent.

You can view changes made during the previous 24 hours.

Note the following change reconciliation options:

• The Include Policy Configuration option controls whether the system includes records of
policy changes in the change reconciliation report. This includes changes to access control,
intrusion, system, health, and network discovery policies. If you do not select this option, the
report will not show changes to any policies. This option is available on Firepower
Management Centers only.

• The Show Full Change History option controls whether the system includes records of all
changes over the past 24 hours in the change reconciliation report. If you do not select this
option, the report includes only a consolidated view of charges for each category.

Database and External Database Access Settings

444
 Bootcamp SSFIPS

You can specify the maximum number of each type of event that the Firepower Management
Center can store.

To improve performance, you should tailor event limits to the number of events that you
regularly work with. For some event types, you can disable storage.

The system automatically prunes intrusion events, discovery events, audit records. Security
Intelligence data, or URL filtering data from the appliance’s database. You can configure the
system to generate automated email notifications when events are automatically pruned.
You can also manually prune the discovery arc user databases to remove selected
discovery data, and you can purge discovery and connection data from the Firepower
Management Center database.

External Database Access Settings

You can configure the Firepower Management Center to allow read-only access to its
database by a third-party client. This allows you to query the database using any of the
following SQL tools:

• Industry-standard reporting tools, such as Actuate BIRT. JasperSoft iReport, or Crystal

Reports

• Any other reporting application (including a custom application) that supports JDBC SSL
connections

• The command-line Java application called RunQuery, provided by Cisco, which you can
either run interactively or use to obtain comma-separated results for a single query.

Use the Firepower Management Center's system configuration to enable database access
and to create an access list that allows selected hosts to query the database. This access
list does not also control appliance access.

You can also download a package that contains the following:

• RunQuery, the database query tool provided by Cisco

• InstallCert, a tool that you can use to retrieve and accept the SSL certificate from the
Firepower Management Center that you can want to access

445
 Bootcamp SSFIPS

• The JDBC driver that you must use to correct to the database

See the Firepower System Database Access Guide for information on using the tools in the
package you downloaded to configure database access:

Time Synchronization and Email Notification Settings

You can view the current time and time source from the Firepower Management Center or
the 7000 or 8000 Series device's local web interface by using the Time page. You can also
use a Firepower Management Center as a Network Time Protocol (NTP) server for its
managed devices. You can manage time synchronization by using the Time Synchronization
page. You can choose to synchronize the time manually or by using ore or more NTP
servers (one of which can be a Firepower Management Center).

Time settings are displayed on most pages on the appliance in local time using the time
zone that you set on the Time Zone page (America/New York by default), but are stored on
the appliance itself using UTC time. In addition, the current time appears in UTC at the top of
the Time Synchronization page (local time is displayed in the Manual clock setting option, if
enabled).

You can synchronize the appliance's time with an external time server. If you specify a
remote NTP server, your appliance must have network access to it. Do not specify an
.untrusted NTP server. Connections to NTP servers do not use configured proxy settings.
You can a so use the Firepower Management Center as an NTP server.

Cisco recommends that you synchronize your appliances to a physical NTP server Do not
synchronize your managed devices to a virtual Firepower Management Center.

446
 Bootcamp SSFIPS
Email Notifications

Configure a mail host if you plan to do any of the following:

• Email event-based reports

• Email status reports for scheduled tasks

• Email change reconciliation reports

• Email data-pruning notifications

• Use email for discovery events, impact nags, correlation event alerting, intrusion event
alerting, and health event alerting

When you configure email notification, you can select an encryption method for the
communication between tie system and the mail relay host, and you can supply
authentication credentials for the mail server if necessary. When fa configuration is
complete, you can test the connection.

Manage Device System Configuration Settings

To configure the managed device settings, complete the following procedure:

Step 1

Choose Devices > Platform Settings

Step 2

Manage your platform settings policies.

447
 Bootcamp SSFIPS

Platform Settings Policy

A platform settings policy is a shared set of features or parameters that define the aspects of
a managed device that are likely to be similar to other managed devices in your deployment,
such as time settings and external authentication.

A shared policy makes it possible to configure multiple managed devices at once, which
provides consistency in your deployment and streamlines your management efforts. Any
changes to a platform settings policy affects all the managed devices where you applied the
policy. Even if you want different settings for each device, you must create a shared policy
and apply it to the desired device.

For example, your organization's security policies may require that your appliances have a
"No Unauthorized Use" message when a user logs in. With platform settings, you can set the
login banner once in a platform settings policy.

You can also benefit from having multiple platform settings policies on a Firepower
Management Center.

For example, if you have different mail relay hosts that you use under different
circumstances or if you want to test different access lists, you can create several platform
settings policies and switch between them, rather than editing a single policy.

448
 Bootcamp SSFIPS
Health Monitoring

The health monitor on the Firepower Management Center tracks a variety of health
indicators to ensure that the hardware and software in the Firepower System are working
correctly. You can use the health monitor to check the status of critical functionality across
your Firepower System deployment You can use the health monitor to create a collection of
tests, referred to as a health policy, and apply the health policy to ore or more appliances.
The tests, referred to as health modules, are scripts that test for criteria that you specify. You
can modify a health policy by enabling or disabling tests or by changing test settings, and
you can delete health policies that you no longer need. You can also suppress messages
from selected appliances by blacklisting them.

The tests in a health policy run automatically at the interval that you configure. You can also
run all tests, or a specific test, on demand. The health monitor collects health events based
on the test conditions configured.

You can use the heath monitor to access health status information for the entire system, for
a particular appliance, or, in a multidomain deployment, a particular domain. Pie charts and
status tables on the Health Monitor page provide a visual summary of the status of all
appliances on your network, including the Firepower Management Center. Individual
appliance health monitors let you drill down into health details for a specific appliance.

Health Monitor Status

The graphic shows the system icons that represent different states

449
 Bootcamp SSFIPS
Health Policy

A health policy contains configured health test criteria for several modules. You can control
which health modules run against each of your appliances, and configure the specific limits
used in the tests run by each module.

When you configure a health policy, you decide whether to enable each health module for
that policy. You also select the criteria that control which health status each enabled module
reports each time that it assesses the health of a process.

You can create one health policy that can be applied to every appliance in your system,
customize each health policy to the specific appliance where you plan to apply it, or use the
default health policy provided for you.

In a multidomain deployment, administrators in ancestor domains can apply health policies

to devices in descendant domains, which descendant domains can use or replace with
customized local policies.

Default Health Policy

The health monitor on the Firepower Management Center provides a default health policy to
allow you to quickly implement health monitoring for your appliances. In the default health
policy, most of the health modules available on the running platform are automatically
enabled. You cannot edit the default health policy, but you can copy it to create custom
policies based on its configuration. The default health policy is automatically applied to the
Firepower Management Center, but you must apply it to a managed devices that you want to
monitor for health.

If you want to customize a health policy to use with your appliances, you can create a new
policy. The settings in the policy initially populate it with the settings from the health policy
that you choose as a basis for the new policy.

You can enable or disable modules within the policy and change the alerting criteria for each
module as necessary.

In a multidomain deployment, the system displays policies created in the current domain,
which you can edit.

450
 Bootcamp SSFIPS
It also displays policies created in ancestor domains, which you cannot edit. To view and edit
policies created in a lower domain, switch to that domain. Administrators in ancestor
domains can apply health policies to devices in descendant domains, which descendant
domains can use or replace with customized coal policies.

Health Policy Modules

Health modules, also sometimes referred to as health tests, are scripts that test for the
criteria that you specify in a health policy.

Refer to the following configuration guide for additional information:

Health Blacklists

In the course of normal network maintenance you disable appliances or make them
temporally unavailable. Because those outages are deliberate, you do not want the health
status from those appliances to affect the summary health status on your Firepower
Management Center.

451
 Bootcamp SSFIPS
You can use the health monitor blacklist feature to disable health-monitoring status reporting
on an appliance or module. For example, if you know that a segment of your network will be
unavailable, you can temporarily disable health monitoring for a managed device on that
segment to prevent the health status on the Firepower Management Center from displaying
a warning or critical state because of the lapsed connection to the device.

When you disable health-monitoring status, health events are still generated, but they have a
disabled status and do not affect the health status for the health monitor. If you remove the
appliance or module from the blacklist, the events that were generated during the blacklisting
continue to show a status of disabled.

To temporarily disable health events from an appliance, go to the blacklist configuration

page and add an appliance to the blacklist. After the setting takes effect, the system no
longer includes the backlisted appliance when calculating the overall health status. The
Health Monitor Appliance Status Summary lists the appliance as disabled.

At times it may be more practical to simply blacklist an individual health-monitoring module

on an appliance.

For example, when you reach the host limit or a Firepower Management: Center, you can
blacklist the Host Limit status messages.

Note that on the main Health Monitor page you can distinguish between appliances that are
blacklisted if you expand to view the list of appliances with a particular status by clicking the
arrow in that status row.

A blacklist icon and a notation are visible after you expand the view for a blacklisted or
partially blacklisted appliance.

Health Monitor Alerts

You can set up alerts to notify you through email, through SNMP, or through the system log
when the status changes for the modules in a health policy. You can associate an existing
alert response with health event levels to trigger an alert when health events of a particular
level occur.

For example, if you are concerned that your appliances may run out of hard disk space, you
can automatically send an email to a system administrator when the remaining disk space
reaches the warning level. If the hard drive continues to fill, you can send a second email
when the hard drive reaches the critical level.

452
 Bootcamp SSFIPS

In a multidomain deployment, you can view and modify health monitor alerts created in the
current domain only.

Health Monitor Alert Information

The alerts generated by the health monitor contain the following information:

• Severity, which indicates the severity level of the alert

• Module, which specifies the health module whose test results triggered the alert

• Descriptor, which includes the health test results that triggered the alert.

When you create a health monitor alert, you create an association between a severity level,
a health module, and an alert response. You can use an existing alert or configure a new
one specifically to report on system health. When the severity level occurs for the selected
module, the alert is triggered.

If you create or update a threshold in a way that duplicates an existing threshold, you are
notified of the conflict. When duplicate thresholds exist, the health monitor uses the
threshold that generates the fewest alerts and ignores the others. The timeout value for the
threshold must be between 5 and 4.294.967.295 minutes.

453
 Bootcamp SSFIPS
Lesson Summary

In this lesson, you learned the following:

• Separate system configuration options are available for the Firepower Management Center
and for the managed device.

• The Firepower Management Center system settings are managed under System
Configuration and include various settings that can be modified according to your needs.

• The managed device's system settings are managed by a platform settings policy.

• Health monitoring in the Firepower System consists of health modules that run every 5
minutes by default to check certain health functions on both the Firepower Management
Center and the managed device.

454
 Bootcamp SSFIPS
Managing Updates

Description

This lesson explores ire updates that are available for both the Firepower Management
Center and the managed device, and gives best-practice information about how to perform
these updates

Objectives

After completing this lesson, you will be able to do the following:

• Identify the update packages that are available for the Firepower System

• Describe Firepower software updates

• Describe VDB updates

• Describe intrusion rule updates

• Describe geolocation database updates

• Describe the Firepower Management Center update process

455
 Bootcamp SSFIPS
Firepower System Software Update Overview

Cisco electronically distributes several distinct types of updates:

• Major and minor updates to the system software itself

• Intrusion rule updates

• Geolocation database (GeoDB) updates

• Vulnerability database (VDB) updates

For most update types, you can schedule their download and installation.

456
 Bootcamp SSFIPS

Firepower Softwares Update

There are a few basic steps to updating your Firepower System deployment. First, you must
prepare for the update by reading the release notes and completing any required pre-update
tasks. Then you can begin the update—first by updating your Firepower Management
Center, and then by updating the devices that it manages. You must monitor the update's
progress until it is complete, and then verify the update's success. Finally, complete any
required post-update steps.

Firepower Software Update Flowchart

Before you update the system, note the following requirements:

• Firepower System version requirements—You must make sure that your appliances
(including software-based devices) are running the correct version of the Firepower System
The release rotes indicate the required version. If you are running an earlier version, you can
obtain updates from the support site.

• Operating system requirements—Make sure that the computers where you installed
software-based devices are running the correct versions of their operating systems The

457
 Bootcamp SSFIPS
release notes indicate the required versions. For information on supported operating
systems for NGIPSv devices, see the Firepower System Virtual Installation Guide.

• Time and disk space requirements—Make sure that you have enough free disk space
and that you allow enough time for the update When you update a managed device, the
update requires additional disk space on the Firepower Management Center The release
notes indicate space and time requirements.

• Configuration and event backup guidelines—Before you begin a major update. Cisco
recommends that you delete any backups that reside on the appliance after copying them to
an external location. Regardless of the update type, you should also back up current event
and configuration data to an external location Event data is not backed up as part of the
update process.

You can use the Firepower Management Center to back up event and configuration data for
itself and for the devices that it manages.

Firepower VDB Updates

The Cisco vulnerability database (VDB) is a database of known vulnerabilities to which hosts
may be susceptible, as well as fingerprints for operating systems, clients, and applications.
The Firepower System correlates the fingerprints with the vulnerabilities to help you
determine whether a particular host increases your risk of network compromise. The Cisco
Talos Security Intelligence and Research Group (Talos) issues periodic updates to the VDB.

To update the VDB, use the Product Updates page on the Firepower Management Center.
When you upload VDB updates obtained from Support to your appliance, they appear on the
page, along with updates and uninstaller updates for the Firepower System.

The time that it takes to update vulnerability mappings depends on the number of hosts in
your network map. You may want to schedule the update during low system usage times to
minimize the impact of any system downtime Asa general rule, divide the number of hosts
on your network by 1000 to determine the approximate number of minutes required for
performing the update

458
 Bootcamp SSFIPS

Intrusion Rule (Snort Rule) Updates

As new vulnerabilities become known. Tabs releases intrusion rule updates mat you can
import onto your Firepower Management Center and then implement by deploying the
changed configuration to your managed devices. These updates affect intrusion rules,
preprocessor rules, and the policies that use the rules.

Intrusion rule updates are cumulative, and Cisco recommends that you always import the
latest update. Vou cannot import an intrusion rule update that either matches or predates the
version of the currently installed rules.

An intrusion rule update may provide the following:

• New and modified rules and rule states—Rule updates provide new and updated
intrusion and preprocessor rules. For new rules, the rule state may be different in each
system-provided intrusion policy. For example, a new rule may be enabled in the Security
Over Connectivity intrusion policy and disabled in the Connectivity Over Security intrusion
pokey. Rule updates may also change the default state of existing rules, or delete existing
rules entirely.

• New rule categories—Rule updates may include new rule categories, which are always
added.

• Modified preprocessor and advanced settings—Rule updates may change the

advanced settings in the system-provided intrusion policies and the preprocessor settings in
system-provided network analysis policies. They can also update default values for the
advanced preprocessing and performance options in your access control policies.

459
 Bootcamp SSFIPS
• New and modified variables—Rule updates may modify default values for existing default
variables but do not override your changes New variables are always added.

In a multidomain deployment, you can import local intrusion rules in any domain, but you can
import intrusion rule updates from Talos in the Global domain only.

When Intrusion Rule Updates Modify Policies

Intrusion rule updates can affect both system-provided and custom network analysis
policies, as well as all access control policies:

• System-provided—Changes to system-provided network analysis and intrusion policies,

as well as any changes to advanced access control settings, automatically take effect when
you redeploy the policies after the update.

• Custom—Because every custom network analysis and intrusion policy uses a system-
provided policy as its base, or as the eventual base in a pokey chain, rule updates can affect
custom network analysis and intrusion policies However, you can prevent rule updates from
automatically making those changes. This allows you to update system-provided base
policies manually, on a schedule independent or rule update imports. Regardless of your
choice (implemented on a per-custom-policy basis), updates to system-provided polices do
not override any settings that you have customized.

Note that importing a rule update discards all cached changes to network analysis and
intrusion policies. For your convenience, the Rule Updates page lists policies with cached
changes and the users who made those changes.

Geolocation Database Updates

The Cisco geolocation database (GeoDB) is a database of geographies data (such as

country, city, coordinates) and connection-related data (such as Internet service provider,
domain name, connection type) associate: with routable IP addresses. When your system
detects GeoCB info-mat on t-a: matches a detected IP address, you can view the
geolocation information associated with that IP address. Vou must install the GeoDB on your
system to view any geolocation details other than country or continent. Cisco issues periodic
updates to the GeoDB.

To updated the GeoDB use the Geolocation Updates page (System > Updates >
Geolocation Updates) on the Firepower Management Center. When you upload GeoDB
updates that you have obtained from Support or from your appliance, they appear on this
page.

460
 Bootcamp SSFIPS

The time necessary to update the GeoDB depends on your appliance: the installation usually
takes 30 to 40 minutes.

Although a GeoDB update does not interrupt any other system functions (including the
ongoing collection of geolocation information), the update does consume system resources
while it is in process Consider this when planning your updates.

The GeoDB update overrides any previous versions of the GeoD3 and is effective
immediately. When you update the GeoDB, the Firepower Management Center
automatically updates the related data on its managed devices. It may take a few minutes for
a GeoDB update to take effect throughout your deployment. You do not need to redeploy
any policies after an update.

Performing Updates

You can download al updates directly from the Firepower Management Center by using the
GUI, or download directly from the Support site and upload the updates to the Firepower
Management Center.

Snort Restart Flowchart—Updates and Policy Applies

461
 Bootcamp SSFIPS
Whether or not you will Crop any packets or have traffic pass through uninspected depends
on the policies and updates being applied. Always deploy policies during a change window.
Refer to the following guide for additional information.

You can also contact Cisco Support for clarification.

The graphic illustrates how Snort restarts can occur when you enable or disable the Inspect
traffic during the policy apply. This is an advanced access control policy option.

Note the following when you enable Inspect traffic during policy apply:

• Certain configurations can require the Snort process to restart

• When the configurations that you deploy do not require a Snort restart, the system initially
uses the currently deployed access control policy to inspect traffic, and switches during
deployment to the access control policy that you are deploying.

• When you disable Inspect traffic during a policy apply, the Snort process always restarts
when you deploy the policy.

• How a Snort restart affects traffic depends on the interface configuration and the platform.

462
 Bootcamp SSFIPS

Lesson Summary

In this lesson, you learned the following:

• Cisco electronically distributes the following update types: major and minor updates to the
system software of the Firepower Management Center and the managed device, intrusion
rule updates, geolocation database updates, and vulnerability database updates.

• Firepower software updates include both the Firepower Management Center and the
managed device.

• VDB updates update the vulnerability database in the Firepower System and affect
Firepower fingerprinting and known vulnerabilities.

• Intrusion rule updates occur twice weekly at a minimum and affect all the Snort rules in the
Firepower System.

• Geolocation database updates are the mappings of IP address to locations.

• To perform updates in the Firepower system, you navigate to System > Update. Always
remain aware of the potential for a Snort restart during the update.

463
 Bootcamp SSFIPS

Examining User Account Management Features

Description

This lesson provides an overview of the user account management options that are available
in the Firepower System.

Objectives

After completing this lesson, you will be able to do the following:

• Describe the user account management features

• Describe the features and benefits of internal versus external user account management

• Describe the system-defined user access roles

464
 Bootcamp SSFIPS

User Account Management Concepts

So far in this course, you have been accessing the Firepower system as the default user
Admin. While this is useful for performing al of the administrative tasks, this is not a good
security practice. Users should be allowed to access the system with only the minimum level
of permissions required for doing their jobs. To facilitate this practice, the Firepower
Management Center allows you to create individual user accounts and assign individual
roles to those accounts in order to control access to features within the Management Center.

The accounts that are created can be internal to the Firepower database or external through
the use of external authentication systems. Currently, external authentication is supported
for LDAP or RADIUS. When using external authentication, you can still take advantage of
the user roles within the Firepower Management Center, out you a so can take advantage of
group memberships of those authentication systems.

Internal vs. External User Authentication

The difference between internal and external authentication refers to where the Firepower
System must go for user account information when a user logs in. The sequence followed by
the systems is as follows

At the login screen, when the user provides login credentials:

• If the user account is configured as internal the managed device checks its local user
account store. If the password provided by the user matches, the user is authenticated and

465
 Bootcamp SSFIPS
is allowed access to the system User permissions are granted by way of the user account
configuration within the Firepower system.

• If the user account is configured as external, the system checks the local database of the
managed device to see if the user exists and to determine if it should apply any account-
specific parameters. If the user is not in the local account store, the system contacts one of
the configured external account repositories. The user credentials are checked against the
external authentication database, and if they are correct, the user is granted access User
permissions are granted implicitly through the defaults that are configured in the
authentication objects that point to external authentication sources, or by the default setting
for external users in the system policy.

System-Defined User Acces Roles

The predefined user access roles are as follows:

• Access Admin—Provides access to access control policy and associate; features n the
Polices menu. Access Admins cannot deploy policies.

• Administrator—Provides access to analysis and reporting features, rule and policy

configuration, system management, and all maintenance features. Administrators can also
deploy configuration changes, including policies, to devices. Administrators have access to
all menu options: their sessions present a higher security risk if compromised, so you cannot
make them exempt from login session timeouts. You should fan it use of the Administrator
role for security reasons.

• Discovery Admin—Provides access to network discovery, application detection, and

correlation features in the Policies menu. Discovery Admins cannot deploy policies.

• External Database User—Provides read-only access to the Firepower System database

by using an application that supports JDBC SSL connections. For the third-party application
to authenticate to the Firepower System, you must enable database access in the system
settings. On the web interface. External Database Users have access only to online help-
related options in the Help menu. Because this role's function does not involve the web
interface, access is provided only for ease of support and password changes

• Intrusion Admin—Provides access to all intrusion policy, intrusion rule, and network
analysis policy features in the Policies and Objects menus Intrusion Admins cannot deploy
policies

466
 Bootcamp SSFIPS
• Maintenance User—Provides access to monitoring and maintenance features.
Maintenance Use's nave access to maintenance-related options in the Health and System
menus.

• Network Admin—Provides access to access control. SSL inspection. DNS policy, and
identity policy features in the Policies menu, as well as device configuration features in the
Devices menus Network Admins can deploy configuration charges to devices.

•Security Analyst—Provides access to security event analysis features, and read-only

access to health events, in the Overview, Analysis. Health, and System menus.

• Security Analyst (Read Only)—Provides read-only access to security event analysis

features and health event features in the Overview. Analysis. Health, and System menus.

• Security Approver—Provides limited access to access control and associated policies

and network discovery polices in the Policies menu. Security Approvers can view and deploy
these policies but cannot make policy charges.

If these roles do not fit the responsibilities of individuals tasked with monitoring or managing
the Firepower system, you can create custom roles.

467
 Bootcamp SSFIPS

Lesson Summary

In this lesson, you learned the following:

• The Firepower Management Center allows you to create individual user accounts and
assign those accounts individual roles to control access to features within the Management
Center.

• User authentication can be performed internally by the Firepower System or externally

through the use of an LDAP or RADIUS server.

• Ten predefined user access roles within the Firepower System provide varying levels of
access from Administrator to specific tasks such as Security Analyst.

468
 Bootcamp SSFIPS

Configuring User Accounts

Description

This lesson describes how to create user accounts, how to create custom user roles, and
how to use the permission escalation feature. You will then look at creating users in
multidomain deployments and implementing external authentication.

Objectives

After completing this lesson, you will be able to do the following:

• Describe the procedures required for configuring internal user accounts

• Describe the procedures required for configuring specific device access groups

• Describe the procedures required for configuring external LDAP and RADIUS account
objects

469
 Bootcamp SSFIPS

Creating User Accounts

This topic discusses the how to create user accounts, including creating custom user roles
and configuring permission escalation.

To create a user, navigate to System — User This action brings up a listing of all user
accounts that have been previously created and the default user admin. Click Create User
to create the new account.

The dialog box that is presented is fairly standard in terms of account creation. Password
expiation and warnings of expiration are configured here, along with a maximum number of
failed logins. If a user's password expires or if the user exceeds the number of failed logins,
the account becomes locked. Unlocking k requires that an administrator navigate to the
System — Users screen and unlock the account.

The following options are available:

• Force Password Reset at Login—This option forces the user to change the password
during the first login.

• Check Password Strength—This option ensures that the passwords are a minimum of
eight characters, are not dictionary words or repeat ng characters, and are a mix of
uppercase and lowercase characters.

• Exempt from Browser Session Timeout—This option prevents the user from being
logged out, based on the setting in the system configuration setting. Users in the
Administrator role cannot be made exempt.

470
 Bootcamp SSFIPS

Custom User Roles

If the default roles Co not meet your management requirements, you can create custom user
roles with specialized access privileges. To do this, navigate to the User Role tab and click
the Create User Role button. A dialog box is displayed, in which you can select which tabs
and menu items that role will have access to.

Custom user roles can be completely original or can be based on a predefined user role
(using the copy feature). Like predefined user roles, custom roles can serve as default roles
for externally authenticated users. Unlike predefined roles, you can modify and delete
custom roles.

471
 Bootcamp SSFIPS

Permission Escalation

The user role tab also allows you to configure permission escalation. With this feature, you
can grant a user the ability to temporarily escalate privileges in case of an emergency
Situation in which an administrator is not available to perform remedial actions that require a
higher degree of access.

If invoked, the privilege escalation is recorded in the audit log. The escalated permissions
are valid only during the current session. After the user logs out the next login returns the
user to the set of permissions that are normally granted to the user's assigned role.

Configuring Permission Escalation

To configure the escalation, you would define the escalation target—that is, who a user
would esca ate to (as shown in the graphic). The escalation must then be enabled: you can
enable it by using a custom user role. A password for the escalation can be either the
specified user's password or an assigned user's password.

When an escalation is enabled for a user, it is displayed as an option under the user's name
in the menus after that user logs in.

472
 Bootcamp SSFIPS

Multidomain Deployments

For Firepower Systems that are utilizing the multidomain features, you can create user
accounts in any domain in which you have been assigned Admin access. You can assign
different access roles for individual domains or provide global access For example, you
might want a single user to be an administrator of two domains, but deny that user access to
the ancestor domain.

When you tog in to the Firepower Management Center, you log in to a single domain, called
the current domain. Depending on your user account, you may be able to switch to other
domains In addition to any restrictions imposed by your user role, your current domain level
can also limit your ability to modify configurations.

External Authentication Requirement

473
 Bootcamp SSFIPS

This topic explains the two steps required for configuring external authentication, creating an
authentication object, and enabling external authentication.

Authentication Objects

To configure external authentication, you must create authentication objects Authentication

objects are server profiles for external authentication servers that contain connection
settings and authentication filter settings for those servers. Vou can create, manage, and
delete authentication objects on the Firepower Management Center.

The two types of authentication objects that you can create are LDAP or RADIUS. While you
can have both LDAP and RADIUS objects in the configuration, only one may be used at any
given time.

When the user logs in to a managed device for the first time, the managed device associates
the external credentials with a set of permissions by creating a local user record. Tie user is
assigned permissions based on either of the following:

• Group or access list that the user belongs to

• Default user access role that you set in the platform settings policy for the managed device

If permissions are granted through group or list membership, they cannot be modified.
However, if they are assigned by default user role, you can modify them in the user account,
and the modifications that you make override the default settings. Here are two examples:

• If the default role for externally authenticated user accounts is set to a specific access role,
users can log into the managed device by using their external account credentials without
any additional configuration by the system administrator.

• If an account is externally authenticated and by default receives no access privileges, users

can log n but cannot access any functionally. You (or your system administrator) can then
change the permissions to grant the appropriate access to user functionality.

You cannot manage passwords for externally authenticated use's or deactivate externally
authenticated users through the Firepower System interface For externally authenticated
users, you cannot remove the minimum access rights through the Firepower System user
management page for users assigned an access role because of LDAP group or RADIUS
list membership or attribute values. On the Edit User page for an externally authenticated
user, rights granted because of settings on an external authentication server are marked
with a status of Externally Modified.

474
 Bootcamp SSFIPS
You can assign additional rights, however. When you modify the access rights for an
externally authenticated user, the Authentication Method column on the User Management
page displays a status of External-Locally Modified.

Authentication Object Creation Example—LDAP

To create authentication objects, navigate to System — Users, click the External

Authentication tab. and then click the Add External Authentication Object buttom.

About LDAP Authentication Objects

LDAP authentication objects allow you to define the settings that you need for connecting to
an LDAP server. The object also contains settings to allow you to search specific branches
of an LDAP directory tree, so that you can focus the user account search on the specific
directory where the account information is located.

To create an LDAP authentication object, you need the following.

• The server name or IP address for the server where you plan to connect.

• The server type of the server where you plan to connect.

• The username and password for a user account with sufficient privileges to browse the
LDAP tree; Cisco recommends that you use a domain admin user account for this purpose.

• If there is a firewall between the managed device and the LDAP server, an entry in the
firewall to allow outgoing connections.

• If possible, the base distinguished name for the server directory where the usernames
reside.

• You can also enable Common Access Card (CAC) authentication. You can configure LDAP
authentication to authenticate users logging in to the web interface and authorize access to
specific functionality based or group membership or default access rights. With CAC

475
 Bootcamp SSFIPS
authentication and authorization configured, users have the option to log n directly, without
providing a separate username and password for the managed device.

Enabling External Authentication

Having created and tested your authentication object, you need to enable external
authentication Vou can do this from the Firepower Management Center GUI.

Select Devices — Platform Settings and create or edit a Firepower policy. From the policy
screen, choose External Authentication from the left menu aid set the Status field to
Enabled. To confirm the changes, save and deploy the policy.

476
 Bootcamp SSFIPS

Lesson Summary

In this lesson, you learned the following:

• You can create a completely new custom user role, or you can use the copy feature to
base a new custom user role on a predefined user role.

• When working with multidomain deployments, users can be granted access to specific
domains and can be assigned different access roles for individual domains.

• To configure external authentication, you must create an authentication object and enable
external authentication in the system policy.

477
 Bootcamp SSFIPS

SecureBank Scenario

SecureBank Scenario-System Administration

The graphic shows the solutions to the requirements outlined for SecureBank at the
beginning of this module.

478
 Bootcamp SSFIPS

Module Summary for "System Administration"

In this module, you learned the following

• Both the Firepower Management Center and the managed device contain system
configuration settings that enable you to make system changes to the appropriate devices,
and a health-monitoring system that ensures the health of all devices, with optional alerting
on health issues

• Firepower System software update types include software updates for both the Firepower
Management Center and the managed devices, VDB updates. Snort rule updates, and
geolocation updates

• User management in the Firepower System can be managed for both internally
authenticated and externally authenticated users by means of LDAP and RADIUS.

• The Firepower Management Center allows the administrator to configure users’ access to
both specific domains and specific features.

479