Step 4: Implementation

User identity authentication and validation and device identity verification at all points of a transaction and whenever device posture, user behavior, or application behavior changes. No unknown users or devices (managed or unmanaged) should be in your enterprise.
Security policy rules that:
Create the architecture by segmenting the network, enforcing the principle of least privilege access, inspecting traffic, and logging traffic.
Adhere to your security standards.
Follow users everywhere in the enterprise.
Decryption policy rules that gain visibility into application traffic so that Security policy rules can inspect the traffic.

It’s much easier to know the applications you want to allow to support your business than to take on the never-ending task of identifying and blocking all the applications you don’t want to allow.
All breaches and malicious activity happen on rules that allow. Focus security on traffic you allow and allow only the traffic required for business purposes.

Run the on-demand Best Practice Assessment (BPA) tool to set a best practice configuration baseline and see areas where you can improve security. As you develop and implement Zero Trust security policy rules, run the BPA periodically to measure progress.
Think like a journalist about each asset or resource that you want to protect: who, what, when, where, why, and how should you allow access to the attack surface?

Who
should access a resource?
User-ID identifies users and enables you to control who accesses a resource in policy. Through a lens of least-privilege access (who needs to know?), allow access only to individuals, groups, and devices that have legitimate business reasons to access a resource.
Use the Cloud Identity Engine (CIE) to centralize cloud-based user and user group identification and user authentication. CIE aggregates all identity information across Identity and Access Management (IAM) solutions to provide consistent policy that follows users everywhere.
Create Authentication policy to verify the identities of users when they attempt to access resources. Authentication policy also determines whether to require Multi-Factor Authentication (MFA).
Use MFA to protect sensitive services and applications by requiring at least one more authentication factor in addition to entering a password in Authentication Portal, such as a one-time-use code delivered to a cell phone or email, before the firewall allows access to sensitive services, applications, and resources. For remote users, configure GlobalProtect to facilitate MFA notifications (you must also configure MFA on the firewall).
For devices that use GlobalProtect, configure Host Information Profiles (HIPs) to define access policy for hosts, enforce policy on those hosts, and prevent devices that don’t meet your security and maintenance standards from accessing resources. For example, you can use a HIP to ensure that endpoints have encryption enabled, the host’s antivirus signatures are up-to-date, etc. If a host doesn’t meet the HIP requirements, the security policy blocks access.
What
application accesses the resource?
Create application-based Layer 7 policy using App-ID, which identifies applications regardless of port, protocol, or evasive tactics, so that you allow only the right applications in your enterprise. Policy based on Layer 3 and Layer 4 relies on IP addresses that an attacker can spoof and leaves ports open to evasive applications.
If you use SaaS applications, use the App-ID Cloud Engine (ACE) to identify thousands of SaaS App-IDs and use the SaaS Security service to control sanctioned and unsanctioned SaaS applications.
Set the Service to application-default to safely enable applications on their default ports and prevent evasive applications from accessing your network on non-standard ports.
Use Policy Optimizer to examine existing policy rules (both application-based rules and legacy port-based rules), identify unused rules, and identify rules with unused applications. (If you need to migrate a legacy configuration to a PAN-OS device, follow the Best Practices for Migrating to Application-Based Policy).
When
do users access the resource?
For applications that users access only during certain hours or at certain times of year (for example, applications used only for quarterly meetings), apply a schedule to the policy rule to prevent suspicious access during off-times. Adversaries often attack and attempt to exfiltrate data outside of normal business hours to reduce the chance of discovery. If an application used only at certain times of year or at certain times of day is used outside those times, that’s suspicious behavior.
Where
is the resource located?
Add the location of the destination resource to the policy. When appropriate, also restrict the source (zone and IP address) of the traffic.
Why
is the data accessed—what is the data’s value if lost (toxicity)?
Classify data to understand its toxicity—why is the data worth protecting? Would you have to disclose the loss if an attacker exfiltrated the data? Set up Data Filtering to prevent sensitive information from leaving your enterprise and use data classification tools to provide metadata about the data. Understanding the toxicity of data helps you determine how to protect data, what to do with data after using it, and how to tag it for use in policy.
How
should you allow access to the resource?
Apply Content-ID and best practices to protect against threats in application traffic:
Apply the philosophy of least-privilege access to security policy rules. Allow only users with legitimate business reasons to access only the applications they need to access for business purposes at only the proper times and only in the proper way.
Log all internal and external traffic through Layer 7. The firewall security policy rules enable logging by default. Forward logs to
Cortex Data Lake
(or to Panorama or to Log Collectors) to consolidate logs for easier and more thorough analysis.
Apply policy and threat prevention consistently across all use cases (data center, cloud, branches, endpoints, etc.), for all local and remote users so the policy follows the user wherever the user goes, for all applications, and for all resources. Inconsistent policy increases vulnerabilities, is difficult to understand and maintain, and may negatively affect compliance requirements and audits.
In addition to physical NGFWs and VM-Series, CN-Series, and cloud firewalls, use
Prisma Access
(cloud) and GlobalProtect (on-premise installation and with
Prisma Access
) to extend consistent Zero Trust policy to endpoints. For endpoints on which you don’t want to or can’t place an agent, use GlobalProtect Clientless VPN to apply consistent policy. Secure unmanaged IoT endpoints using the IoT Security service. Create and reuse Panorama templates and stacks to apply consistent policy across similar locations, such as your data centers or your perimeters.
Use cloud delivered security services (CDSS) whenever possible to ensure that you receive the latest threat prevention signatures in real time to protect against malware and command-and-control, advanced URL Filtering to control website access and prevent phishing attacks, WildFire for known and new malware, Enterprise DLP to prevent data exfiltration, SaaS Security to protect SaaS applications, IoT Security to protect unmanaged devices, and the DNS Security service to safeguard DNS transactions.
Configure security profiles (Vulnerability Protection profiles for IPS, Antivirus and WildFire profiles to protect against malware including day-one malware, Anti-Spyware profiles to prevent command-and-control threats, File Blocking profiles to block or alert on risky file types, and URL Filtering to control website access, help prevent phishing attacks, and enforce safe search for search engines) and apply them to all allowed traffic. Follow best practices for data center firewall and perimeter firewall security profiles.
Use WildFire best practices to detect and prevent zero-day malware.
Use decryption best practices to decrypt as much traffic as regulations and business requirements enable you to decrypt so you can inspect as much traffic as possible. You can’t protect your enterprise against threats you can’t see.
Determine what to do with sensitive data after you use it—abstract it using encryption, tokenization, or masking, or dispose of it by archiving or deleting it. Archive stale data (approximately 80% of data on most systems hasn’t been accessed for two or more years).
Use Cortex XDR to refine and improve policy.