Network Security
Web Security Management
Table of Contents
Expand All
|
Collapse All
Network Security Docs
-
- Security Policy
-
- Security Profile Groups
- Security Profile: AI Security
- Security Profile: WildFire® Analysis
- Security Profile: Antivirus
- Security Profile: Vulnerability Protection
- Security Profile: Anti-Spyware
- Security Profile: DNS Security
- Security Profile: DoS Protection Profile
- Security Profile: File Blocking
- Security Profile: URL Filtering
- Security Profile: Data Filtering
- Security Profile: Zone Protection
-
- Policy Object: Address Groups
- Policy Object: Regions
- Policy Object: Traffic Objects
- Policy Object: Applications
- Policy Object: Application Groups
- Policy Object: Application Filter
- Policy Object: Services
- Policy Object: Auto-Tag Actions
- Policy Object: Devices
-
- Uses for External Dynamic Lists in Policy
- Formatting Guidelines for an External Dynamic List
- Built-in External Dynamic Lists
- Configure Your Environment to Access an External Dynamic List
- Configure your Environment to Access an External Dynamic List from the EDL Hosting Service
- Retrieve an External Dynamic List from the Web Server
- View External Dynamic List Entries
- Enforce Policy on an External Dynamic List
- Find External Dynamic Lists That Failed Authentication
- Disable Authentication for an External Dynamic List
- Policy Object: HIP Objects
- Policy Object: Schedules
- Policy Object: Quarantine Device Lists
- Policy Object: Dynamic User Groups
- Policy Object: Custom Objects
- Policy Object: Log Forwarding
- Policy Object: Authentication
- Policy Object: Decryption Profile
- Policy Object: Packet Broker Profile
-
-
-
- The Quantum Computing Threat
- How RFC 8784 Resists Quantum Computing Threats
- How RFC 9242 and RFC 9370 Resist Quantum Computing Threats
- Support for Post-Quantum Features
- Post-Quantum Migration Planning and Preparation
- Best Practices for Resisting Post-Quantum Attacks
- Learn More About Post-Quantum Security
-
-
-
- Investigate Reasons for Decryption Failure
- Identify Weak Protocols and Cipher Suites
- Troubleshoot Version Errors
- Troubleshoot Unsupported Cipher Suites
- Identify Untrusted CA Certificates
- Repair Incomplete Certificate Chains
- Troubleshoot Pinned Certificates
- Troubleshoot Expired Certificates
- Troubleshoot Revoked Certificates
Web Security Management
Web Security is a consolidated, Security policy management interface
that’s optimized for web security admins in Prisma Access Cloud
Management.
Where Can I Use This? | What Do I Need? |
---|---|
|
|
Web Security is a consolidated, Security policy management interface that’s optimized
for Web Security Admins. Web Security provides a
simplified and consolidated management experience for admins who’re focused on securing
access to the internet and SaaS applications.
Some key features of Web Security are:
- Consolidated Security policy management - Define URL and application access Security policies for users and security protections, all from a single location. Your threat protection settings are applied globally to all web traffic, which eliminates the need to configure them on a per-Security policy basis. You can also turn on SSL Decryption easily from a central location.
- Built-in best practices - Secure web traffic in just a couple of clicks. The ready-to-use default Security policy configurations adhere to Palo Alto Networks’ best practice recommendations. Simply Enable Web Security and Push Config to secure web traffic right away. You can use the default security rules as-is or customize your own.
- Separation of roles and responsibilities - As a Web Security Admin, you can manage web-bound traffic from Web Security, while other traffic is enforced according to the Security policies set in Configuration. All Prisma Access configurations can be handled on a single console with clear separation.
- Web Security Admins - Can manage settings relevant to their role, but other settings are hidden from view.
- Account Admin, App Admin, or Instance Admin - Can also view Web Security settings.
The Web Access Security policy layer works with your existing security
policy. It includes default, best practice Security policies that you can enable
immediately and then customize based on the needs of your organization. Web access
Security policy is enforced ahead of your Security policy rulebase.

Learn about the features available to you in Web Security with
the Web Security Overview video.
Web Security policy Migration
If you had Web Security policies prior to upgrading your environment, you'll find
them in a new editable Snippet called “web-sec-migration”. If you had targeted rules
specific for GlobalProtect, Explicit Proxy, or Remote Networks, your find them in a
separate snippet that's attached to the relevant scope.


So you don't encounter any functional changes to your configuration, snippets have
already associated with their correct level, but you'll need to perform a full ("All
Admin" scope) before your commits can function.

Rule Order for Web Security and Security Policy
Web Access security rules your create in folder are inherited by child folders, as
are any other rules in your configuration. When GlobalProtect, Explicit Proxy, or
Remote Networks are heirs of Web Security policy, Web Security rules go to the top
of the rulebase. Security policies from higher-level parent folders get priority
over Web Access Security policies in lower-level child folders. Default security
policies are always placed at the bottom and below any Web Security rules in a child
folder.
Newly created Global Web Access policy rules are positioned between Web Security
rules and the regular security rules, with Global Catch All policies placed on top
of the intrazone default rules in post-rules.
Web Security policies offer a framework for abstracting policies, enabling
translation of user intent into the language understood by the enforcement node.
This ensures continuity for current rules without altering user experience through
default rule ordering.
Here's the order of rule enforcement:
Global - Web Access Security policies
Global - Security policies
|
Prisma Access - Web Access Security policies
Prisma Access - Security policies (pre-rules)
|
Remote Networks - Web Access Security policies
Remote Networks - Security policies
|
Prisma Access - Security policies (post-rules)
|
Global - Security policies (post-rules)
|

Get a Behind-the-Scenes Look at your Custom Security policies
Your custom security rules go through a transformation after your build them so that
Prisma Access can enforce them properly. The Detail
Usage tab gives you an advanced view of your custom security rules, so
you can pinpoint in your logs the work your Web Security rules are
doing.
To see the details for any of your rules, select ManageConfigurationNGFW and Prisma AccessSecurity ServicesWeb SecurityWeb Access Security policy, select a rule you want to see details for from the Security policies
tab, and then select the Detail Usage tab.
You may notice that a single security rule is separated into multiple rules in this
view. This is because the rule's intent may require more than one rule to
accomplish.
