Network Security
Plan a Public Key Infrastructure (PKI) Rollout
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
Plan a Public Key Infrastructure (PKI) Rollout
Ensure that all of your network devices have valid SSL Forward Trust certificates
before rolling out decryption to avoid unnecessary certificate warnings and calls to tech
support.
| Where Can I Use This? | What Do I Need? |
|---|---|
|
No separate license required for decryption when using NGFWs or
Prisma Access.
Note: The features and capabilities available to you in
Strata Cloud Manager depend on your active license(s).
|
Plan how to roll out your public key infrastructure (PKI). Network devices need an SSL
Forward Trust certificate authority (CA) certificate for trusted sites and an SSL
Forward Untrust CA certificate for untrusted sites. Generate separate Forward Trust and
Forward Untrust certificates. Don't sign the Forward Untrust certificate with the
enterprise root CA because you want the Untrust certificate to warn users that they are
trying to access potentially unsafe sites. Palo Alto Networks Next-Generation Firewalls
(NGFWs) have two methods of generating CA certificates for SSL
decryption:
- Generate the SSL CA certificates from your enterprise root CA as subordinate certificates—If you have an existing enterprise PKI, this is the best practice. Generating a subordinate certificate from your enterprise root CA makes the rollout easier and smoother because network devices already trust the enterprise root CA, so you avoid any certificate issues when you begin the deployment phase. If you don't have an enterprise root CA, consider getting one.
- Generate a self-signed root CA certificate on the NGFW and create subordinate CA certificates on that NGFW—If you don't have an enterprise root CA, this method provides a self-signed root CA certificate and the subordinate Forward Trust and Untrust CA certificates. With this method, you need to install the self-signed certificates on all of your network devices so that those devices recognize the NGFW’s self-signed certificates. Because the certificates must be deployed to all devices, this method is better for small deployments and proof of concept (PoC) trials than for large deployments.
Don't export the Forward Untrust certificate to the certificate trust lists of your network
devices. Installing the Untrust certificate in the Trust List results in devices
trusting websites that the NGFW does not trust. In addition, users won't see
certificate warnings for untrusted sites, so they won't know the sites are untrusted
and may access those sites, which could expose your network to threats.
Regardless of whether you generate Forward Trust certificates from your enterprise root CA or use
a self-signed certificate generated on the NGFW, generate a separate subordinate
Forward Trust CA certificate for each NGFW. The flexibility of using separate
subordinate CAs enables you to revoke one certificate when you
decommission a device (or device pair) without affecting the rest of the deployment.
It also reduces the impact in any situation in which you need to revoke a
certificate. Separate Forward Trust CAs on each NGFW also helps troubleshoot
issues because the CA error message the user sees includes information about the
NGFW the traffic is traversing. If you use the same Forward Trust CA on every
NGFW, you lose the granularity of that information.
There is no benefit to using different Forward Untrust certificates on different NGFWs, so you can use the same Forward Untrust certificate on all NGFWs. If you need additional security for your private keys, consider
storing them on a hardware security
module.
You may need to make special accommodations for guest users. If guest users don't need
access to your corporate network, don't allow access, and then you won't have to decrypt
their traffic or create infrastructure to support guest access. If you need to support
guest users, discuss with your legal department whether you can decrypt guest
traffic.
If you can decrypt guest traffic, treat guests similarly to the way you treat BYOD
devices. Decrypt guest traffic and subject it to the same Security policy that you apply
to other network traffic. Do this by redirecting guest users through an Authentication
Portal, instruct them how to download and install the CA certificate, and clearly notify
users that their traffic will be decrypted. Include the process in your company’s
privacy and computer usage policy. In addition, restrict guest traffic to only the areas
guests need to access.
If you can’t decrypt guest traffic for legal reasons, then isolate guest traffic and
prevent it from moving laterally in your network:
- Create a separate zone for guests and restrict guest access to that zone. To prevent lateral movement, don’t allow guest access to other zones.
- Allow only sanctioned applications, use URL filtering to prevent access to risky URL categories, and apply the best practice Security profiles.
- Prevent guests from accessing websites with unknown or expired CAs by enabling the block sessions with untrusted issuers and block sessions with expired certificates options in your decryption profiles.
All employees, contractors, partners, and other users should use your normal corporate
infrastructure, and you should decrypt and inspect their traffic.