Migrate Port-Based to App-ID Based Security Policy Rules

1. Identify port-based rules.
   Port-based rules have no configured (allowed) applications. PoliciesSecurityPolicy OptimizerNo App Specified displays all port-based rules (Apps Allowed is any).

2. Prioritize which port-based rules to convert first.
   PoliciesSecurityPolicy OptimizerNo App Specified enables you to sort rules without affecting their order in the rulebase and provides other information that helps you prioritize rules for conversion based on your business goals and risk tolerance.

   • Traffic (Bytes, 30 days)—(Click to sort.) Rules that currently match the most traffic are at the top of the list. This is the default sorting order.
   • Apps Seen—(Click to sort.) A large number of legitimate applications matching a port-based rule may indicate you should replace it with multiple application-based rules that tightly define the applications, users, and sources and destinations. For example, if a port-based rule controls traffic for multiple applications for different user groups on different sets of devices, create separate rules that pair applications with their legitimate users and devices to reduce the attack surface and increase visibility. (Clicking the Apps Seen number or Compare shows you the applications that have matched the rule.)

     The firewall updates Apps Seen approximately every hour. However, if there is a large volume of application traffic or a large number of rules, it may take longer than an hour to update. After you add an application to a rule, wait at least an hour before running Traffic logs to see the application’s log information.
   • Days with No New Apps—(Click to sort.) When the applications seen on a port-based rule stabilize, you can be more confident the rule is mature, conversion won’t accidentally exclude legitimate applications, and no more new applications will match the rule. The Created and Modified dates help you evaluate a rule’s stability because older rules that have not been modified recently may also be more stable.
   • Hit Count—Displays rules with the most matches over a selected time frame. You can exclude rules for which you reset the hit counter and specify the exclusion time period in days. Excluding rules with recently reset hit counters prevents misconceptions about rules that show fewer hits than you expect because you didn’t know the counter was reset.

     You can also use Hit Count to View Policy Rule Usage and help identify and remove unused rules to reduce security risks and keep your rulebase organized.
3. Review the Apps Seen on port-based rules, starting with the highest priority rules.
   On No Apps Specified, click Compare or the number in Apps Seen to open Applications & Usage, which lists applications that matched a port-based rule over a specified Timeframe, with each application’s Risk, the date it was First Seen, the date it was Last Seen, and the amount of traffic over the last 30 days.
   You can check Applications seen on port-based rules over the past 7, 15, or 30 days, or over the rule’s lifetime (Anytime). For migrating rules, Anytime provides the most complete assessment of applications that matched the rule.

   You can search and filter the Apps Seen, but keep in mind that it takes an hour or more to update Apps Seen. You can also order the Apps Seen by clicking the column headers. For example, you can click Traffic (30 days) to bring the applications with the most recent traffic to the top of the list, or click Subcategory to organize the applications by subcategory.

   The granularity of measurement for First Seen and Last Seen data is one day, so on the day you define a rule, the dates in these two columns are the same. On the second day the firewall sees traffic on an application, you’ll see a difference in the dates.
4. Clone or add applications to the rule to specify the applications you want to allow on the rule.
   On Applications & Usage, convert a port-based rule to an application-based rule in either of two ways:

   • Clone the rule—Preserves the original port-based rule and places the cloned application-based rule directly above it in the rulebase.
   • Add Applications to the Rule—Replaces the original port-based rule with the new application-based rule and deletes the original rule.
     If you have existing application-based rules and you want to migrate applications to them from port-based rules, you can Add Applications to an Existing Rule instead of cloning a new rule or converting the port-based rule by adding applications to it.

   Some applications appear on the network at intervals, for example, for quarterly or yearly events. These applications may not display on the Applications & Usage screen if the history isn’t long enough to capture their latest activity.

   When you clone a rule or add applications to a rule, nothing else about the original rule changes. The original rule’s configuration remains the same except for the applications you added to the rule. For example, if the original rule’s Service allowed Any application or specified a particular service, you need to change the Service to Application-Default to restrict the allowed applications to their default ports on the new rule.

   Cloning is the safest way to migrate rules, especially when Applications & Usage shows more than a few well-known applications matching the rule (Rule Cloning Migration Use Case: Web Browsing and SSL Traffic provides an example of this). Cloning preserves the original port-based rule and places it below the cloned application-based rule, which eliminates the risk of losing application availability because traffic that doesn’t match the cloned rule flows through to the port-based rule. When traffic from legitimate applications hasn’t hit the port-based rule for a reasonable period of time, you can remove it to complete that rule’s migration.

   To clone a port-based rule:

   1. In Apps Seen, click the check box next to each application you want in the cloned rule. Keep in mind that it takes an hour or more to update Apps Seen.
   2. Click Create Cloned Rule. In the Create Cloned Rule dialog, Name the cloned rule (“slack” in this example) and add other applications in the same container and application dependencies, if required. For example, to clone a rule by selecting the slack-base application:
      The green text is the selected application to clone. The container application (slack) is in the gray row. The applications listed in italics are applications that have not been seen on the rule but are in the same container as the selected application. Individual applications that have been seen on the rule are in normal font. All the applications are included in the cloned rule by default (Add Container App, which adds all the applications in the container, is selected by default) to help prevent the rule from breaking in the future.
   3. If you want to allow all of the applications in the container, leave Add container app selected. This also “future proofs” the rule because when an application is added to the container app, it’s automatically added to the rule.
      If you want to constrain access to some of the individual applications in the container, uncheck the box next to each individual application you don’t want users to access. This also unchecks the container app, so if you want to allow new applications in the container later, you have to add those applications individually.
      If you uncheck the container app, all the apps are unchecked and you manually select the apps you want to include in the cloned rule.
   4. If application dependencies are listed in a box below the Applications (there are none in this example), leave them checked. The applications you selected need those application dependencies to run. Common dependencies include ssl and web-browsing.
   5. Click OK to add the new application-based rule directly above the port-based rule in the rulebase.
   6. Commit the configuration.

   When you clone a rule and Commit the configuration, the applications you select for the cloned rule are removed from the original port-based rule’s Apps Seen list. For example, if a port-based rule has 16 Apps Seen and you select two individual applications and one dependent application for the cloned rule, after cloning, the port-based rule shows 13 Apps Seen because the three selected applications have been removed from the port-based rule (16-3 = 13). The cloned rule shows the three added applications in Apps on Rule.

   Creating a cloned rule with a container app works a bit differently. For example, a port-based rule has 16 Apps Seen and you select one individual application and a container app for the cloned rule. The container app has five individual applications and has one dependent application. After cloning, the cloned rule shows seven Apps on Rule—the individual application, the five individual applications in the container app, and the dependent application for the container app. However, in the original port-based rule, Apps Seen shows 13 applications because only the individual application, the container app, and the container app’s dependent application are removed from the port-based rule.

   In contrast to cloning, adding applications to a port-based rule replaces the rule with the resulting application-based rule. Adding applications to a rule is simpler than cloning, but riskier because you may inadvertently miss applications that should be on the rule, and the original port-based rule is no longer in the rulebase to catch accidental omissions. However, adding applications to port-based rules that apply to only a few well-known applications migrates the rule quickly to an application-based rule. For example, for a port-based rule that only controls traffic to TCP port 22, the only legitimate application is SSH, so it’s safe to add applications to the rule.

   Adding applications using the traditional Security policy rule’s Application tab does not change Apps Seen or Apps on Rule. To preserve accurate application usage information, when replacing port-based rules with application-based rules, add applications using Add to This Rule or Match Usage (or create a cloned rule or add applications to an existing application-based rule instead) in Apps Seen.

   There are three ways to replace a port-based rule with an application-based rule by adding applications (Add to This Rule and Match Usage in Apps Seen and Add in Apps on Rule):

   • Add to This Rule applications from Apps Seen (applications that matched the rule). Keep in mind that it takes an hour or more to update Apps Seen.
     1. Select applications from Apps Seen on the rule.
     2. Click Add to This Rule. In the Add to This Rule dialog, add other applications in the same container app and application dependencies, if required. For example, to add slack-base to a rule:
        Similar to the Create Cloned Rule dialog, the green text in Add to This Rule is the selected application to add to the rule. The container app (slack) is in the gray row. The applications listed in italics are applications that have not been seen on the rule but are in the same container as the selected application. Individual applications that have been seen on the rule are in normal font. All the applications are included in the cloned rule by default (Add Container App, which adds all the applications in the container, is selected by default) to help prevent the rule from breaking in the future.
     3. If you want to allow all of the applications in the container, leave Add container app selected. This also “future proofs” the rule because when an application is added to the container app, it’s automatically added to the rule.
        If you want to constrain access to some of the individual applications in the container, uncheck the box next to each individual application you don’t want users to access. This also unchecks the container app, so if you want to allow new applications in the container later, you have to add those applications individually.
        If you uncheck the container app, all the apps are unchecked and you manually select the apps you want to include in the cloned rule.
     4. If application dependencies are listed in a box below the Applications (there are none in this example), leave them checked. The applications you selected need those application dependencies to run.
     5. Click OK to replace the port-based rule with the new application-based rule.
     When you Add to This Rule and Commit the configuration, the applications you didn’t add are removed from Apps Seen because the new application-based rule no longer allows them. For example, if a rule has 16 Apps Seen and you Add to This Rule three applications, the resulting new rule shows only those three added applications in Apps Seen.
     Add to This Rule with a container app works a bit differently. For example, a port-based rule has 16 Apps Seen and you select one individual application and a container app to add to the new rule. The container app has five individual applications and has one dependent application. After adding the applications to the rule, the new rule shows seven Apps on Rule—the individual application, the five individual applications in the container app, and the dependent application for the container app. However, Apps Seen shows 13 applications because the individual application, the container app, and the container app’s dependent application are removed from that list.
   • Add all of the Apps Seen on the rule to the rule at one time with one click (Match Usage).
     Port-based rules allow any application, so Apps Seen may include unneeded or unsafe applications. Use Match Usage to convert a rule only when the rule has seen a small number of well-known applications with legitimate business purposes. A good example is TCP port 22, which should only allow SSH traffic, so if SSH is the only application seen on a port-based rule that opens port 22, you can safely Match Usage.
     1. In Apps Seen, click Match Usage. Keep in mind that it takes an hour or more to update Apps Seen. All the applications in Apps Seen are copied to Apps on Rule.
     2. Click OK to create the application-based rule and replace the port-based rule.
   • If you know the applications you want on the rule, you can Add applications manually in Apps on Rule. However, this method is equivalent to using the traditional Security policy rule Application tab and does not change Apps Seen or Apps on Rule. To preserve accurate application usage information, convert rules using Add to This Rule, Create Cloned Rule, or Match Usage in Apps Seen.
     1. In Apps on Rule, Add (or Browse) and select applications to add to the rule. This is equivalent to adding applications on the Application tab.
     2. Click OK to add the applications to the rule and replace the port-based rule with the new application-based rule.
        Because this method is equivalent to adding applications using the Application tab, the dialog to add application dependencies doesn’t pop up.
5. For each application-based rule, set the Service to application-default.
   If business needs require you to allow applications (for example, internal custom applications) on non-standard ports between particular clients and servers, restrict the exception to only the required application, sources, and destinations. Consider rewriting custom applications so they use the application default port.
6. Commit the configuration.
7. Monitor the rules.
   • Cloned rules—Monitor the original port-based rule to ensure the application-based rule matches the desired traffic. If applications you want to allow match the port-based rule, add them to the application-based rule or clone another application-based rule for them. When only applications that you don’t want on your network match the port-based rule for a reasonable period of time, the cloned rule is robust (it catches all the application traffic you want to control) and you can safely remove it.
   • Rules with Added Applications—Because you convert only port-based rules that have a few well-known applications directly to application-based rules, in most cases the rule is solid from the start. Monitor the converted rule to see if the expected traffic matches the rule—if there’s less traffic than expected, the rule may not allow all of the necessary applications. If there’s more traffic than expected, the rule may allow unwanted traffic. Listen to user feedback—if users can’t access applications they need for business purposes, the rule (or another rule) may be too tight.