: Transition Anti-Spyware Profiles Safely to Best Practices
Focus
Focus

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 (
    Monitor
    Logs
    Threat
    ) 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,
    Dashboard
    System Resources
    ) 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 of the DNS record types because they are used by encrypted DNS queries. This prevents clients from encrypting the client hello during the DNS resolution process, which blocks the exchange of key information.
    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.

Recommended For You