Transition Anti-Spyware Profiles Safely to Best Practices
Table of Contents
Transition Anti-Spyware Profiles Safely to Best Practices
Apply Anti-Spyware profiles to allow rules to protect against command-and-control attacks
without risking application availability.
The following guidance helps determine whether to start with block or alert actions
as you define the initial Anti-Spyware profiles and begin the transition to best
practices profiles.
Anti-Spyware requires an Advanced Threat Prevention or active legacy Threat Prevention
subscription.
To identify and prevent threats,
the firewall must have visibility into application traffic. Decrypt as much traffic
as local regulations, business considerations, privacy considerations,
and technical ability allow. If you don’t decrypt traffic, the firewall
can’t analyze encrypted headers and payload information.
In
addition, follow Threats Content Update best
practices to ensure that your Security profile signatures are up
to date.
- Business-critical applications—Set the initial action to alert to ensure application availability. However, in some situations, you can use the block action from the start. For example, when you’re already protecting applications with an Anti-Spyware profile that blocks critical, high, and/or medium signatures, and you’re confident the profile meets your business and security needs, you can use a similar profile to block spyware and protect those applications.The alert action enables you to analyze Threat logs and create exceptions when necessary before moving to a block action. Alerting and monitoring before you move to blocking gives you confidence that:
- The profile won’t block business-critical applications when you deploy it.
- You create necessary exceptions as you transition to the blocking state to maintain application availability.
Transition to the best practice state as soon as you’re comfortable you’ve identified any exceptions you need to make and configure the profile accordingly. - Critical and high severity signatures—False positive rates are typically low. For applications that aren’t critical to your business, block critical and high severity signatures from the start.
- Medium severity signatures—These might generate false positives and require initial monitoring. Start by alerting on medium severity signatures for internal traffic and blocking medium severity signatures for external-facing traffic. Monitor the Threat logs ( ) to see if you should block applications for which you receive alerts or if you need to allow them.
- Low and informational severity signatures—The default action for most of these signatures is alert or allow. Unless you have a specific need to alert on all low and informational signatures, start with the default action.
- Enable single packet capture for all severity signatures during the transition if you have the resources. Enabling packet capture allows you to investigate events in greater detail if necessary. As you move to best practice profiles, if low and informational events create too much packet capture activity (too large a volume of traffic) and the information isn’t useful, transition to disabling packet capture on these severities.Packet captures consume management plane resources. Check system resources (for example, ) to understand usage before and after you implement packet capture to ensure that your system has sufficient resources to take all the packet captures.
- If you treat internal applications differently than external applications, you might need an Anti-Spyware profile for internet-facing traffic and another Anti-Spyware profile for internal traffic.
- DNS Policies:
- Set the Policy Action for DNS signatures to Sinkhole to identify potentially compromised hosts that attempt to access suspicious domains. DNS sinkhole enables you to track the hosts and prevent them from accessing those domains. (Enabling DNS sinkhole immediately is the best practice.) Set Packet Capture to extended-capture.
- Sinkhole all of the DNS Security domain types and set Packet Capture as shown in Figure 1 (PAN-OS 10.0 and later).
- In addition, block all DNS record types used for Encrypted Client Hello (ECH) to maximize security. This prevents the client from initiating an ECH connection during the handshake process, which might otherwise interfere with inspection of the client hello contents by Advanced DNS Security.
- Block all DoH requests by creating applicable App-ID and/or URL Filtering policies. If it is necessary to allow DoH traffic, create a sanctioned DoH resolver that uses DNS Security to inspect the DoH requests.
Allow traffic only to sanctioned DNS servers. Use the DNS Security service to prevent connections to malicious DNS servers.On PAN-OS based systems, set the DNS sinkhole address as the FQDN, for example, sinkhole.paloaltonetworks.com, so that if the IP address changes, the setting is still valid. For Prisma Access, use the sinkhole IP address.Anti-Spyware profile DNS Policies ![]()
- Inline Cloud Analysis (requires Advanced Threat Prevention subscription and PAN-OS 10.2 or later)—Enable cloud inline analysis on all outbound traffic. Set the Action to reset-both for all models.Air-gapped environments cannot use Advanced Threat Prevention because it’s a cloud service and requires a cloud connection.
When you have the initial profiles in place, monitor the Threat logs for enough time to gain
confidence that you understand whether any business-critical applications cause alerts
or blocks. Transition to best practices Anti-Spyware
profiles as soon as you’re comfortable doing so. Create exceptions (open a
support ticket if necessary) in each profile as needed to remediate any confirmed false
positives before you implement full best-practice Anti-Spyware profiles.