The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This guide does not include information on how to upgrade the system software or firewall chassis. Instead, see the Cisco Secure Firewall Threat Defense Upgrade Guide for Management Center for the version that the Firewall Management Center is currently running.
The system can obtain content updates from the internet. We recommend you schedule or enable automatic content updates whenever possible. Some updates are auto-enabled by the initial setup process or when you enable the related feature. After initial setup, we recommend you review all auto-updates and adjust them if necessary.
|
Component |
Description |
Details |
|---|---|---|
|
Vulnerability database (VDB) |
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 system uses the VDB to help determine whether a particular host increases your risk of compromise. |
Schedule: As a scheduled task. Uninstall: No. |
|
Geolocation database (GeoDB) |
The Cisco geolocation database (GeoDB) maps IP addresses to countries/continents. |
Schedule: From its own update page Uninstall: No. |
|
Intrusion rules (SRU/LSP) |
Intrusion rule updates provide new and updated intrusion rules and preprocessor rules, modified states for existing rules, and modified default intrusion policy settings. Rule updates may also delete rules, provide new rule categories and default variables, and modify default variable values. |
Schedule: From its own update page. Uninstall: No. |
|
Security Intelligence feeds |
Security Intelligence feeds are collections of IP addresses, domain names, and URLs that you can use to quickly filter traffic that matches an entry. |
Schedule: From the object manager. Uninstall: No. See: Cisco Secure Firewall Management Center Device Configuration Guide |
|
URL categories and reputations |
URL filtering allows you to control access to websites based on the URL’s general classification (category) and risk level (reputation). |
Schedule: When you configure integrations/cloud services, or as a scheduled task. Uninstall: No. See: Cisco Secure Firewall Management Center Device Configuration Guide |
Any
Global unless indicated otherwise.
Admin
We recommend you read any release notes or advisory text that accompanies a content update. These provide critical and release-specific information, including compatibility, prerequisites, new capabilities, behavior changes, and warnings.
Review scheduled updates to be sure they occur when you intend. The system schedules tasks — including updates — in UTC. This means that when they occur locally depends on the date and your specific location. Also, because updates are scheduled in UTC, they do not adjust for Daylight Saving Time, summer time, or any such seasonal adjustments that you may observe in your location. If you are affected, scheduled updates occur one hour "later" in the summer than in the winter, according to local time.
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 system uses the VDB to help determine whether a particular host increases your risk of compromise.
Cisco issues periodic updates to the VDB. The time it takes to update the VDB and its associated mappings on the Firewall Management Center depends on the number of hosts in your network map. As a rule of thumb, divide the number of hosts by 1000 to determine the approximate number of minutes to perform the update.
The initial setup on the Firewall Management Center automatically downloads and installs the latest VDB from Cisco as a one-time operation. Optionally, schedule tasks to download and install VDB updates and deploy configurations. For more information, see Vulnerability Database Update Automation.
For VDB 343+, all application detector information is available through Cisco Secure Firewall Application Detectors. This site includes a searchable database of application detectors. The release notes provide information on changes for a particular VDB release.
For VDB 363+, the system installs a smaller VDB (also called VDB lite) on lower memory devices running Snort 2. This smaller VDB contains the same applications, but fewer detection patterns. Devices using the smaller VDB can miss some application identification versus devices using the full VDB.
If your Firewall Management Center has internet access, we recommend you schedule regular VDB updates. See Vulnerability Database Update Automation.
Use this procedure to manually update the VDB.
 Caution |
Do not perform tasks related to mapped vulnerabilities while the VDB is updating. Even if the Message Center shows no progress for several minutes or indicates that the update has failed, do not restart the update. Instead, contact Cisco TAC. In most cases, the first deploy after a VDB update restarts the Snort process, interrupting traffic inspection. The system warns you when this will happen (updated application detectors and operating system fingerprints require a restart; vulnerability information does not). Whether traffic drops or passes without further inspection during this interruption depends on how the targeted device handles traffic. For more information, see Snort Restart Traffic Behavior. |
If the Firewall Management Center cannot access the internet, get the update yourself: https://www.cisco.com/go/firepower-software. Select or search for your model (or choose any model—you use the same VDB for all Firewall Management Centers), then browse to the Coverage and Content Updates page.
|
Step 1 |
Go to the VDB update page.
|
||
|
Step 2 |
Choose how you want to get the VDB onto the Firewall Management Center.
|
||
|
Step 3 |
Install the VDB.
Monitor update progress in the Message Center. After the update completes, the system uses the new vulnerability information. However, you must deploy before updated application detectors and operating system fingerprints can take effect. |
||
|
Step 4 |
Verify update success. The VDB update page and Help ( |
Deploy configuration changes; see the Cisco Secure Firewall Management Center Device Configuration Guide.
The geolocation database (GeoDB) is a database that you can leverage to view and filter traffic based on geographical location. We issue periodic updates to the GeoDB, and you must regularly update the GeoDB to have accurate geolocation information. As part of the initial configuration, the system schedules weekly GeoDB updates. We recommend you review this task and make changes if necessary, as described in Schedule GeoDB Updates.
A GeoDB update overrides any previous versions. The Firewall Management
Center automatically updates its managed devices, and unless
the update adds new countries (this is rare) you do not need to redeploy. You can
see your current version on Help (
).
 Note |
We no longer provide the geolocation IP package, which contained contextual data associated with routable IP addresses. This saves disk space and does not affect geolocation rules or traffic handling in any way. Any contextual data is now stale, and upgrading to most later versions deletes the IP package. Options to download the IP package or view contextual data have no effect, and are removed in later versions. |
As part of the initial configuration, the system schedules weekly GeoDB updates. We recommend you review this task and make changes if necessary, as described in this procedure.
Note that the system does not automatically deploy after GeoDB updates because in most cases it is not necessary. However, after a scheduled GeoDB update adds a new country (this is rare), deploy as soon as you are able. This allows the new country to count as part of its continent. For example, if an update adds Country to Continent, rules that filter based on "Continent" do not match traffic through Country until you deploy.
Note |
The IP Package Download option available in some versions has no effect. We no longer provide an IP package. In later versions, this option is removed. |
Make sure the Firewall Management Center can access the internet.
|
Step 1 |
Go to the GeoDB update page.
|
|
Step 2 |
Under Recurring Geolocation Updates, check Enable Recurring Weekly Updates.... |
|
Step 3 |
Specify the Update Start Time. |
|
Step 4 |
Click Save. |
Use this procedure to perform an on-demand GeoDB update.
Note |
The IP Package Download option available in some versions has no effect. We no longer provide an IP package. In later versions, this option is removed. |
If the Firewall Management Center cannot access the internet, get the update yourself: https://www.cisco.com/go/firepower-software. Select or search for your model (or choose any model—you use the same GeoDB for all Firewall Management Centers), then browse to the Coverage and Content Updates page.
|
Step 1 |
Go to the GeoDB update page.
|
|
Step 2 |
Under One-Time Geolocation Update, choose how you want to update the GeoDB.
|
|
Step 3 |
Click Import. Monitor update progress in the Message Center. |
|
Step 4 |
Verify update success. The GeoDB update page and Help ( |
If the update adds a new country (this is rare), deploy now. Until you deploy, the new country does not count as part of its continent. For example, if an update adds Country to Continent, rules that filter based on "Continent" do not match traffic through Country until you deploy.
As new vulnerabilities become known, the Talos Intelligence Group releases intrusion rule updates. These updates affect intrusion rules, preprocessor rules, and the policies that use the rules. Intrusion rule updates are cumulative and we recommend you keep the system up to date. You 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 policy. 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.
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.
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 re-deploy 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 policy 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 of rule update imports. Regardless of your choice (implemented on a per-custom-policy basis), updates to system-provided policies do not override any settings you 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.
For changes made by an intrusion rule update to take effect, you must redeploy configurations. When importing a rule update, you can configure the system to automatically redeploy to affected devices. This approach is especially useful if you allow the intrusion rule update to modify system-provided base intrusion policies.
Caution |
Although a rule update by itself does not restart the Snort process when you deploy, other changes you have made may. Restarting Snort briefly interrupts traffic flow and inspection on all devices, including those configured for high availability/scalability. Interface configurations determine whether traffic drops or passes without inspection during the interruption. When you deploy without restarting Snort, resource demands may result in a small number of packets dropping without inspection. |
As part of the initial configuration, the system schedules daily intrusion rule updates. We recommend you review this task and make changes if necessary, as described in Schedule Intrusion Rule Updates. You may want to change the frequency, or enable automatic deploy after rule imports. For high availability Firewall Management Centers, you only need to import the update on the active unit.
A local intrusion rule is a custom standard text rule that you import from a local machine as a plain text file with ASCII or UTF-8 encoding. You can create local rules using the instructions in the Snort users manual, which is available at http://www.snort.org.
In a multidomain deployment, you can import local intrusion rules in any domain. You can view local intrusion rules imported in the current domain and ancestor domains.
As part of the initial configuration, the system schedules daily intrusion rule updates. We recommend you review this task and make changes if necessary, as described in this procedure.
Make sure your process for updating intrusion rules complies with your security policies.
Consider the update's effect on traffic flow and inspection due to bandwidth constraints and Snort restarts. We recommend performing updates in a maintenance window.
Make sure the Firewall Management Center can access the internet.
|
Step 1 |
Go to the rule update page.
|
|
Step 2 |
Under Recurring Rule Update Imports, check Enable Recurring Rule Update Imports. |
|
Step 3 |
Specify the Import Frequency and start time. |
|
Step 4 |
(Optional) Check Reapply all policies... to deploy after each update. |
|
Step 5 |
Click Save. |
Use this procedure to perform an on-demand intrusion rule update.
Make sure your process for updating intrusion rules complies with your security policies.
Consider the update's effect on traffic flow and inspection due to bandwidth constraints and Snort restarts. We recommend performing updates in a maintenance window.
If the Firewall Management Center cannot access the internet, get the update yourself: https://www.cisco.com/go/firepower-software. Select or search for your model (or choose any model—you use the same update for all Firewall Management Centers), then browse to the Coverage and Content Updates page.
|
Step 1 |
Go to the rule update page.
|
|
Step 2 |
Under One-Time Rule Update/Rules Import, choose how you want to update intrusion rules.
|
|
Step 3 |
(Optional) Check Reapply all policies... to deploy after the update. |
|
Step 4 |
Click Import. |
|
Step 5 |
Verify update success. The rule update page and Help ( |
If you did not deploy as a part of the update, deploy now.
Use this procedure to import local intrusion rules. Imported intrusion rules appear in the local rule category in a disabled state. You can perform this task in any domain.
Make sure your local rule file follows the guidelines described in Best Practices for Importing Local Intrusion Rules.
Make sure your process for importing local intrusion rules complies with your security policies.
Consider the import's effect on traffic flow and inspection due to bandwidth constraints and Snort restarts. We recommend scheduling rule updates during maintenance windows.
|
Step 1 |
Go to the rule update page.
|
|
Step 2 |
(Optional) Delete existing local rules. Click Delete All Local Rules, then confirm that you want to move all created and imported intrusion rules to the deleted folder. |
|
Step 3 |
Under One-Time Rule Update/Rules Import, choose Rule update or text rule file to upload and install, then click Choose File and browse to your local rule file. |
|
Step 4 |
Click Import. |
Edit intrusion policies and enable the rules you imported.
Deploy configuration changes; see the Cisco Secure Firewall Management Center Device Configuration Guide.
Observe the following guidelines when importing a local rule file:
The rules importer requires that all custom rules are imported in a plain text file encoded in ASCII or UTF-8.
The text file
name can include alphanumeric characters, spaces, and no special characters
other than underscore (_), period (.), and dash (-).
The system imports local rules preceded with a single pound character (#), but they are flagged as deleted.
The system imports local rules preceded with a single pound character (#), and does not import local rules preceded with two pound characters (##).
Rules cannot contain any escape characters.
In a multidomain deployment, the system assigns a GID of 1 to a rule imported into or created in the Global domain, and a domain-specific GID between 1000 and 2000 for all other domains.
You do not have to specify a Generator ID (GID) when importing a local rule. If you do, specify only GID 1 for a standard text rule.
When importing a rule for the first time, do not specify a Snort ID (SID) or revision number. This avoids collisions with SIDs of other rules, including deleted rules. The system will automatically assign the rule the next available custom rule SID of 1000000 or greater, and a revision number of 1.
If you must import rules with SIDs, a SID can be any unique number 1,000,000 or greater.
In a multidomain deployment, if multiple administrators are importing local rules at the same time, SIDs within an individual domain might appear to be non-sequential because the system assigned the intervening numbers in the sequence to another domain.
When importing an updated version of a local rule you have previously imported, or when reinstating a local rule you have deleted, you must include the SID assigned by the system and a revision number greater than the current revision number. You can determine the revision number for a current or deleted rule by editing the rule.
Note |
The system automatically increments the revision number when you delete a local rule; this is a device that allows you to reinstate local rules. All deleted local rules are moved from the local rule category to the deleted rule category. |
Import local rules on the primary Firewall Management Center in a high availability pair to avoid SID numbering issues.
The import fails if a rule contains any of the following: .
A SID greater than 2147483647.
A list of source or destination ports that is longer than 64 characters.
When importing into the Global domain in a multidomain deployment, a GID:SID combination uses GID 1 and a SID that already exists in another domain; this indicates that the combination existed before Version 6.2.1. You can reimport the rule using GID 1 and a unique SID.
Policy
validation fails if you enable an imported local rule that uses the deprecated
threshold keyword in combination with the intrusion
event thresholding feature in an intrusion policy.
All imported local rules are automatically saved in the local rule category.
The system always sets local rules that you import to the disabled rule state. You must manually set the state of local rules before you can use them in your intrusion policy.
The system generates logs of rule updates/imports, listed by timestamp, user, and whether each update succeeded or failed. These logs contain detailed import information on all updated rules and components; see Intrusion Rule Update Log Details. Use this procedure to view rule import logs. Note that deleting an import log does not delete the imported objects. In a multidomain deployment, you can view data for the current domain and for any descendant domains. You cannot view data from higher level or sibling domains.
|
Step 1 |
Go to the rule update page.
|
|
Step 2 |
Click Rule Update Log. |
|
Step 3 |
(Optional) View details for any rule update by clicking
View ( |
 Tip |
You search the entire Rule Update Import Log database even when you initiate a search by clicking Search on the toolbar from the Rule Update Import Log detailed view with only the records for a single import file displayed. Make sure you set your time constraints to include all objects you want to include in the search. |
|
Field |
Description |
|---|---|
|
Action |
An indication that one of the following has occurred for the object type:
|
|
Default Action |
The default action defined by the rule
update. When the imported object type is |
|
Details |
A string unique to the component or rule.
For rules, the GID, SID, and previous revision number for a
changed rule, displayed as |
|
Domain |
The domain whose intrusion policies can use the updated rule. Intrusion policies in descendant domains can also use the rule. This field is only present in a multidomain deployment. |
|
GID |
The generator ID for a rule. For example,
|
|
Name |
The name of the imported object, which for rules corresponds to the rule Message field, and for rule update components is the component name. |
|
Policy |
For imported rules, this field displays
|
|
Rev |
The revision number for a rule. |
|
Rule Update |
The rule update file name. |
|
SID |
The SID for a rule. |
|
Time |
The time and date the import began. |
|
Type |
The type of imported object, which can be one of the following:
|
|
Count |
The count ( |
If your Firewall Management Center is not connected to the internet, essential updates will not occur automatically. You must manually obtain and install these updates.
For more information, see:
|
Feature |
Minimum Management Center |
Minimum Threat Defense |
Details |
|---|---|---|---|
|
Content updates and product upgrades no longer share a page. |
7.2.6 7.4.1 |
Any |
Content updates and product upgrades no longer share a page.
Other version restrictions: Not supported with Firewall Management Center Version 7.3.x or 7.4.0. |
|
Deprecated: scheduled download of maintenance releases. |
7.2.6 7.4.1 |
Any |
Upgrade impact. Scheduled download tasks stop retrieving maintenance releases. The Download Latest Update scheduled
task no longer downloads maintenance releases; now it only
downloads the latest applicable patches and VDB updates. To
direct-download maintenance (and major) releases to the Firewall Management
Center, use System( |
|
Custom intrusion rule import warns when rules collide. |
6.7.0 |
Any |
The FMC now warns you of rule collisions when you import custom (local) intrusion rules. Previously, the system would silently skip the rules that cause collisions—with the exception of Version 6.6.0.1, where a rule import with collisions would fail entirely. On the Rule Updates page, if a rule import had collisions, a warning icon is displayed in the Status column. For more information, hover your pointer over the warning icon and read the tooltip. Note that a collision occurs when you try to import an intrusion rule that has the same SID/revision number as an existing rule. You should always make sure that updated versions of custom rules have new revision numbers. New/modified screens: We added a warning icon to
System( |
|
Automatic VDB update during initial setup. |
6.6.0 |
Any |
When you set up a new or reimaged FMC, the system automatically attempts to update the vulnerability database (VDB). This is a one-time operation. If the FMC has internet access, we recommend you schedule tasks to perform automatic recurring VDB update downloads and installations. |
|
Automatic software downloads and GeoDB updates. |
6.5.0 |
Any |
When you set up a new or reimaged FMC, the system automatically attempts to update the vulnerability database (VDB). This is a one-time operation. If the FMC has internet access, we recommend you schedule tasks to perform automatic recurring VDB update downloads and installations. |
|
Signed SRU, VDB, and GeoDB updates. |
6.4.0 |
Any |
So the system can verify that you are using the correct update files, Version 6.4+ uses signed updates for intrusion rules (SRU), the vulnerability database (VDB), and the geolocation database (GeoDB). Earlier versions continue to use unsigned updates. Unless you manually download updates, for example, in an air-gapped deployment—you should not notice any difference in functionality. If, however, you do manually download and install SRU, VDB, and GeoDB updates, make sure you download the correct package for your current version. Signed update files begin with 'Cisco' instead of 'Sourcefire,' and terminate in .sh.REL.tar instead of .sh, as follows:
We will provide both signed and unsigned updates until the end-of-support for versions that require unsigned updates. Do not untar signed (.tar) packages. If you accidentally upload a signed update to an older FMC or ASA FirePOWER device, you must manually delete it. Leaving the package takes up disk space, and also may cause issues with future upgrades. |
|
FMC warns of Snort restart before VDB updates. |
6.2.3 |
Any |
The FMC now warns you that vulnerability database (VDB) updates restart the Snort process. This interrupts traffic inspection and, depending on how the managed device handles traffic, possibly interrupts traffic flow. You can cancel the install until a more convenient time, such as during a maintenance window. These warnings can appear:
|
|
Deprecated: Geolocation details |
6.2.3 |
Any |
We no longer provide the geolocation IP package, which contained contextual data associated with routable IP addresses. This saves disk space and does not affect geolocation rules or traffic handling in any way. Any contextual data is now stale, and upgrading to most later versions deletes the IP package. Options to download the IP package or view contextual data have no effect, and are removed in later versions. |
Feedback