Make sure your appliances can reach Talos resources.

The system must be able to communicate with the following Cisco resources after the upgrade:

• https://regsvc.sco.cisco.com/ — Registration

• https://est.sco.cisco.com/ — Obtain certificates for secure communications

• https://updates-talos.sco.cisco.com/ — Obtain client/server manifests

• http://updates.ironport.com/ — Download database (note: uses port 80)

• https://v3.sds.cisco.com/ — Cloud queries

The cloud query service also uses the following IP address blocks:

• IPv4 cloud queries:

  • 146.112.62.0/24

  • 146.112.63.0/24

  • 146.112.255.0/24

  • 146.112.59.0/24

• IPv6 cloud queries:

  • 2a04:e4c7:ffff::/48

  • 2a04:e4c7:fffe::/48

Identify potential rule issues.

Understand the upcoming changes. Examine your current URL filtering configuration and determine what post-upgrade actions you will need to take (see the next section).

In FMC deployments, we recommend you generate an access control policy report, which provides details on the policy's current saved configuration, including access control rules and rules in subordinate policies (such as SSL). For each URL rule, you can see the current categories, reputations, and associated rule actions. On the FMC, choose Policies > Access Control, then click the report icon () next to the appropriate policy.

Remove deprecated categories from rules. Required.

The upgrade does not modify URL rules that use deprecated categories. Rules that use them will prevent deploy.

On the FMC, these rules are marked.

Create or modify rules to include the new categories.

Most of the new categories identify threats. We strongly recommend you use them.

On the FMC, these new categories are not marked after this upgrade, but Talos may add additional categories in the future. When that happens, new categories are marked.

Evaluate rules changed as a result of merged categories.

Each rule that included any of the affected categories now include all of the affected categories. If the original categories were associated with different reputations, the new rule is associated with the broader, more inclusive reputation. To filter URLs as before, you may have to modify or delete some configurations; see Guidelines for Rules with Merged URL Categories.

Depending on what changed and how your platform handles rule warnings, changes may be marked. For example, the FMC marks wholly redundant and wholly preempted rules, but not rules that have partial overlap.

Evaluate rules changed as a result of split categories.

The upgrade replaces each old, single category in URL rules with all the new categories that map to the old one. This will not change the way you filter URLs, but you can modify affected rules to take advantage of the new granularity.

These changes are not marked.

Understand which categories were renamed or are unchanged.

Although no action is required, you should be aware of these changes.

These changes are not marked.

Evaluate how you handle uncategorized and reputationless URLs.

Even though it is now possible to have uncategorized and reputationless URLs, you cannot still cannot filter uncategorized URLs by reputation, nor can you filter reputationless URLs.

Make sure that rules that filter by the Uncategorized category, or by Any reputation, will behave as you expect.

Rule Order Determines Which Rule Matches Traffic

When considering rules that include the same category, remember that traffic matches the first rule in the list that includes the condition.

Categories in the Same Rule vs Categories in Different Rules

Merging categories in a single rule will merge into a single category in the rule. For example, if Category A and Category B are merging to become Category AB, and you have a rule with both Category A and Category B, then after merge the rule will have a single Category AB.

Merging categories in different rules will result in separate rules with the same category in each rule after the merge. For example, if Category A and Category B are merging to become Category AB, and you have Rule 1 with Category A and Rule 2 with Category B, then after merge Rule 1 and Rule 2 will each include Category AB. How you choose to resolve this situation depends on the rule order, on the actions and reputation levels associated with the rules, on the other URL categories included in the rule, and on the non-URL conditions that are included in the rule.

Associated Action

If merged categories in different rules were associated with different actions, then after merge you may have two or more rules with different actions for the same category.

Associated Reputation Level

If a single rule includes categories that were associated with different reputation levels before merging, the merged category will be associated with the more inclusive reputation level. For example, if Category A was associated in a particular rule with Any reputation and Category B was associated in the same rule with reputation level 3 - Benign sites with security risks, then after merge Category AB in that rule will be associated with Any reputation.

Duplicate and Redundant Categories and Rules

After merge, different rules may have the same category associated with different actions and reputation levels.

Redundant rules may not be exact duplicates, but they may no longer match traffic if another rule earlier in the rule order matches instead. For example, if you have pre-merge Rule 1 with Category A that applies to Any Reputation, and Rule 2 with Category B that applies only to Reputation 1-3, then after merge, both Rule 1 and Rule 2 will have Category AB, but Rule 2 will never match if Rule 1 is higher in the rule order.

On the FMC, rules with an identical category and reputation will show a warning. However, these warnings will not indicate rules that include the same category but a different reputation.

Caution: Consider all conditions in the rule when determining how to resolve duplicate or redundant categories.

Other URL Categories in a Rule

Rules with merged URLs may also include other URL categories. Therefore, if a particular category is duplicated after merge, you may want to modify rather than delete these rules.

Non-URL Conditions in a Rule

Rules with merged URL categories may also include other rule conditions, such as application conditions. Therefore, if a particular category is duplicated after merge, you may want to modify rather than delete these rules.

Merged categories in the same rule

Rule 1 has Category A and Category B.

Rule 1 has Category AB.

Merged categories in different rules

Rule 1 has Category A.

Rule 2 has Category B.

Rule 1 has Category AB.

Rule 2 has Category AB.

The specific result varies by the rules' order in the list, reputation levels, and associated actions. You should also consider all other conditions in the rule when determining how to resolve any redundancy.

Merged categories in different rules have different actions

(Reputation is the same)

Rule 1 has Category A set to Allow.

Rule 2 has Category B set to Block.

(Reputation is the same)

Rule 1 has Category AB set to Allow.

Rule 2 has Category AB set to Block.

Rule 1 will match all traffic for this category.

Rule 2 will never match traffic, and will display a warning indicator if you show warnings after merge, because both category and reputation are the same.

Merged categories in the same rule have different reputation levels

Rule 1 includes:

Category A with Reputation Any

Category B with Reputation 1-3

Rule 1 includes Category AB with Reputation Any.

Merged categories in different rules have different reputation levels

Rule 1 includes Category A with Reputation Any.

Rule 2 includes Category B with Reputation 1-3.

Rule 1 includes Category AB with Reputation Any.

Rule 2 includes Category AB with Reputation 1-3.

Rule 1 will match all traffic for this category.

Rule 2 will never match traffic, but you will not see a warning indicator because the reputations are not identical.