Migrating 'Web Security' - Handling config anomalies prior to upgrade

[dhshah]

With the latest release of Strata Cloud Manager (config management), there are changes to how 'Web Security' is being handled in your environment. 

Change 1: Security Services -> Web Security -> Web Access Policies will be migrated to Security Services -> Security Policies Rulebase as a single rulebase (with policies coexisting). 

- You will have control over the rule ordering

Change 2: Security Services -> 'Web Security' central settings (Threat Management, Decryption etc) will move to Security Services -> "Internet Security"

Change 3: If we had both block and allow selections within the same Web Access policy, these will be split out into two rules - one for Block followed by one for Allow.

Why are we doing this ?

There was a lot of feedback around the rigidity of the current support with Web Access policies, especially around rule ordering and cross-referencing of objects and profiles that led to operational inefficiencies due to unusable rulebases OR duplication of objects. The move to a single rulebase helps make it much more flexible and user-controllable. 

As we do this, not that 'Web Security' is not something to be enabled anymore but will be available for use and creating policies against (you continue to have the choice to use it or not)

Scenarios for Troubleshooting

There are certain scenarios/cases you need to be aware of and plan for mitigation: 

If you currently have no Web Security enabled at any node
Case 1: If you have any config in Source or Destination region block (Security Services -> Web Security -> Security Settings -> Threat Management -> Country Block)

• It will generate a source-region and destination-region block policy
• Mitigation - remove it to ensure no change of behavior if these policies are not desired. Push/commit the change.

Case 2: If you have removed/detached the Web Security default (Internet-Security-Default) snippet from Global, the upgrade will auto-attach this snippet back to “Global” (and it cannot be disassociated). This may fail if the snippet is attached to some child nodes.

• This will cause reference errors as profiles/objects in this snippet are referenced by other snippets

• Mitigation: If the auto-attach fails, then you will have to attach this snippet to “Global” to overcome the reference errors

Case 3: Decryption under Web Security will be set to ‘no decrypt’; catch-all (internet-access-default) will be disabled at upgrade to ensure no change of behavior.

• In cases where the upgrades have issues and you observe changes above are not implemented, then follow steps below.
• Mitigation:
  • Under Global -> Internet Security -> Security Settings -> Decryption -> Bypass & Logging settings: set Default Decryption Setting to ‘No Decrypt’
  • Under Global -> Security Policy: Go to Global Post Rules and disable “internet-access-default’

If you have Web Security Enabled only partially on nodes

Case 1: If you have policies created on a parent folder, but one or more of the child folders/scopes do not have Web Security enabled

• This will cause all of the parent policies to be inherited by all child scopes and get enforced if pushed.

• Mitigation: If that is not desired, move the policies from the parent to a snippet and attach it to ALL child nodes where you want these enforced. Move the snippet to its appropriate position in the rulebase. And then push the changes.

Case 2: The internet access default post-rule in Global will be enabled

• This will impact traffic on all child nodes, as it gets enforced as a Global post-rule

• Mitigation: If this is not desired, disable the internet-access-default policy and create a specific block/deny default policy in the nodes where you want the enforcement

For Hybrid (Prisma Access + NGFW tenant):
Case 1: Security zones used by Internet Access policies are defaulted to Inbound zone = any; Outbound zone = internet

• If these zones do not exist on the NGFW then push time validation/commits will fail

• Mitigation: Under Security Services -> Internet Security -> Security Settings -> General, customize the settings to provide an Inbound and Outbound zone for the NGFWs OR Create a zone by name ‘internet’ for the NGFWs

Case 2: If you have device scope disabled but Web Security enabled for certain NGFWs, then snippets cannot be attached directly to the nodes

• The Internet Access best practice snippet cannot be attached - this snippet carries the default best practice policies for Internet/GenAI access and will get removed on push for those devices
• Mitigation: Enable the device scope for those devices and attach the Internet Access best practice snippet. And attempt a push.

Web Security enabled and Snippet with Web Security policies and Security Rules in same snippet

Case 1: After the upgrade, the web access policies will move to the security rulebase of the snippet. The snippet is attached in order in the security rulebase of folders. As a result web access policies will be placed just above the security policies of that snippet. Prior to the upgrade, they were getting placed at the top of the rulebase above all security rules. This can potentially change the ordering for you.

• Mitigation: Move the web security policies into a different snippet (no security rules in that snippet) and attach that to the folders, in the right rulebase position.

Rule name collision between Web Access policy and Security Rules

Case 1: If you have rule names in Web Access policies that are the same as rule names in Security policy, then post migration to a single rule base will cause name conflicts.

Mitigation: Pick unique names for Web Access policies that do not collide