For increased flexibility and web interface ease-of-use, the Firepower Management Center allows you to create named objects, which 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 that contain variables 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.

You can also:

• Group objects to reference multiple objects with a single configuration; see Object Groups.

• Override object values for selected devices or, in a multidomain deployment, selected domains; see Object Overrides.

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.

Port objects represent different protocols in slightly different ways:

TCP and UDP

A port object represents the transport layer protocol, with the protocol number in parentheses, plus an optional associated port or port range. For example: TCP(6)/22.

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, code. For more information on ICMP types and codes, see:

• http:/​/​www.iana.org/​assignments/​icmp-parameters/​icmp-parameters.xml

• http:/​/​www.iana.org/​assignments/​icmpv6-parameters/​icmpv6-parameters.xml

Other

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, including access control policies, 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 affect on the managed device when the configuration is deployed.

• If you create a port object containing both TCP and UDP ports, then add it as a source port condition in a rule, you cannot add a destination port, and vice versa.

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 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:

• During initial configuration of a 7000 or 8000 Series device, the system creates security zones based on the detection mode you selected for the device. For example, the system creates a Passive zone in passive deployments, while in inline deployments the system creates External and Internal zones. When you register the device to the Firepower Management Center, those security zones are added to the Management Center.

• You can create security zones on the fly while configuring interfaces on a managed device.

• You can create security zones 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 multi-context mode or vice versa, the system removes all interfaces from your security zone configurations.

When you update a security zone object, re-deploy configuration changes to managed devices.

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 re-deploy 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 those filters do not automatically update when you update the system software or the VDB.

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 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. For example, if you select the medium and high risk filters and the medium and high business relevance filters, the system displays the applications that have medium or high risk, and also have medium or high business relevance.

Tip	Click an information icon () for more information about the associated application. To display additional information, click any of the Internet search links in the pop-up that appears.

After you determine the applications 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.

Each VLAN tag object 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.

Each URL object 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 policies and event searches. For example, you could write an access control rule that blocks a specific website.

When creating URL objects, especially 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 using the subject common name in the public key certificate 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.

• When matching web traffic 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 when creating an object. For example, use example.com rather than http://example.com/.

Each geolocation object 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).

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.

Tip	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, the majority of the rules use the variable $HOME_NET to specify the protected network and the variable $EXTERNAL_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 $HTTP_SERVERS and $HTTP_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 $HOME_NET correctly defines your network and $HTTP_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 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.

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 (Talos) and 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.

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

Caution

Importing an access control or an intrusion policy overwrites existing default variables in the default variable set with the imported default variables. If your existing default variable set contains a custom variable not present in the imported default variable set, the unique variable is preserved.

The Security Intelligence feature allows you to specify the traffic that can traverse your network based on the source or destination IP address, domain name, or URL. You configure Security Intelligence in access control policies, separate from access control rules. This is especially useful if you want to blacklist — deny traffic to and from — specific IP addresses or URLs, before the traffic is analyzed by access control rules. You can also add IP addresses, URLs, and domain names to a whitelist to force the system to handle their connections using access control.

If you are not sure whether you want to blacklist a particular IP address or URL, a monitor-only setting allows the system to handle a connection using access control, but also logs the connection’s match to the blacklist.

By default, access control policies use Global whitelists and blacklists for IP addresses and URLs. Similarly, DNS policies use the Global DNS whitelist and blacklist.

In a multidomain deployment, access control policies can also use:

• Descendant whitelists and blacklists. In ancestor domains, descendant lists represent items whitelisted or blacklisted in subdomains. Descendant lists can also contain items added for lower-level domains by higher-level domain administrators. From an ancestor domain, you cannot view the contents of descendant lists.

• Domain-specific whitelists and blacklists. In subdomains, domain-specific lists represent items whitelisted or blacklisted in or for the named domain. You can view the contents of domain-specific lists for ancestor domains, and edit the contents of the domain-specific list for your domain.

Global, Descendant, and Domain-specific lists apply to any zone, and you can disable them on a per-policy basis.

Finally, you can build custom whitelists and blacklists for IP addresses, URLs, or domain names, using:

• network or URL objects

• network, URL, or DNS categories

• Security Intelligence lists and feeds

You can constrain these by security zone. In a DNS policy, you can also constrain DNs based on network or VLAN.

Comparing Feeds and Lists

A Security Intelligence feed is a dynamic collection of IP addresses, URLs, or domain names that the Firepower Management Center downloads from an HTTP or HTTPS server at the interval you configure. Because feeds are regularly updated, the system can use up-to-date information to filter your network traffic.

Note	The system does not perform peer SSL certificate verification when downloading custom feeds, nor does the system support the use of certificate bundles or self-signed certificates to verify the remote peer.

To help you build blacklists, the Firepower System provides:

• the Intelligence Feed, which represents IP addresses determined by Talos to have a poor reputation

• the DNS and URL Intelligence Feed, comprised of domain names and URLs with a poor reputation

When the Firepower Management Center downloads updated feed information, it automatically updates its managed devices. Although it may take a few minutes for a feed update to take effect throughout your deployment, you do not have to re-deploy access control policies after you create or modify a feed, or after a scheduled feed update.

Note

If you want strict control over when the system downloads a feed from the Internet, you can disable automatic updates for that feed. However, Cisco recommends that you allow automatic updates. Although you can manually perform on-demand updates, allowing the system to download feeds on a regular basis provides you with the most up-to-date, relevant data.

A Security Intelligence list, contrasted with a feed, is a simple static list of IP addresses, domain names, or URLs that you manually upload to the system. Use custom lists to augment and fine-tune feeds and default whitelists and blacklists. Note that editing custom lists (as well as editing network objects and removing entries from a whitelist or blacklist) require an access control policy deploy for your changes to take effect.

A sinkhole object represents either a DNS server that gives non-routeable 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.

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 10000 unique SHA-256 values.

There are two predefined categories of file lists:

Clean List

If you add a file to this list, the system treats it as if the AMP cloud assigned a clean disposition.

Custom Detection List

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

In a multidomain deployment, a clean list and custom detection list is present for each domain. In lower-level domains, you can view but not modify ancestor's 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 Malware action and a matching file type to calculate a file’s SHA value.

Caution

Do not include malware on the clean list. The clean list overrides both the AMP cloud and the custom detection list.

A cipher suite list is an object comprised of several cipher suites. Each predefined cipher suite value represents a cipher suite used to negotiate an SSL- or TLS-encrypted session. You can use cipher suites and cipher suite lists in SSL rules to control encrypted traffic based on whether the client and server negotiated the SSL session using that cipher suite. If you add a cipher suite list to an SSL rule, SSL sessions negotiated with any of the cipher suites in the list match the rule.

Note	Although you can use cipher suites in the web interface in the same places as cipher suite lists, you cannot add, modify, or delete cipher suites.

Each distinguished name object represents the distinguished name listed for a public key certificate’s subject or issuer. You can use distinguished name objects and groups in SSL rules to control encrypted traffic based on whether the client and server negotiated the SSL session using a server certificate with the distinguished name as subject or issuer.

Your distinguished name object can contain the common name attribute (CN). If you add a common name without “CN=” then the system prepends “CN=” before saving the object.

You can also add a distinguished name with one of each attribute listed in the following table, separated by commas.

You can define one or more asterisks (*) as wild cards in an attribute. In a common name attribute, you can define one or more asterisks per domain name label. Wild cards match only within that label, though you can define multiple labels with wild cards. See the following table for examples.

PKI objects represent the public key certificates and paired private keys required to support your deployment. Internal and trusted CA objects consist of certificate authority (CA) certificates; internal CA objects also contain the private key paired with the certificate. Internal and external certificate objects consist of server certificates; internal certificate objects also contain the private key paired with the certificate.

If you use trusted certificate authority objects and internal certificate objects to configure ISE, you can establish a connection to ISE.

If you use internal certificate objects to configure captive portal, the system can authenticate the identity of your captive portal device when connecting to users' web browsers.

If you use trusted certificate authority objects to configure realms, you can configure secure connections to LDAP or AD servers.

If you use PKI objects in SSL rules, you can match traffic encrypted with:

• the certificate in an external certificate object

• a certificate either signed by the CA in a trusted CA object, or within the CA’s chain of trust

If you use PKI objects in SSL rules, you can decrypt:

• outgoing traffic by re-signing the server certificate with an internal CA object

• incoming traffic using the known private key in an internal certificate object

You can manually input certificate and key information, upload a file containing that information, or in some cases, generate a new CA certificate and private key.

When you view a list of PKI objects in the object manager, the system displays the certificate’s Subject distinguished name as the object value. Hover your pointer over the value to view the full certificate Subject distinguished name. To view other certificate details, edit the PKI object.

Note

The Firepower Management Center and managed devices encrypt all private keys stored in internal CA objects and internal certificate objects with a randomly generated key before saving them. If you upload private keys that are password protected, the appliance decrypts the key using the user-supplied password, then reencrypts it with the randomly generated key before saving it.