Transition Vulnerability Protection Profiles Safely to Best Practices

Apply Vulnerability Protection profiles to allow rules to protect against malware exploits and vulnerabilities without risking application availability.
The decision to block or alert when you first apply Vulnerability Protection profiles to traffic depends on your current security posture and your business requirements regarding security vs. availability. The following guidance helps determine whether to start with block or alert actions as you begin the transition to best practice Vulnerability Protection profiles.
Vulnerability Protection 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
    —It’s usually best to set the initial rule
    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 similar applications with a Vulnerability Protection profile that blocks on vulnerability signatures, and you’re confident the profile meets your business and security needs, you can use a similar profile to block vulnerabilities and protect the similar applications.
    Alerting enables you to analyze Threat logs and create exceptions when necessary before you start blocking traffic. Alerting and monitoring before moving to blocking gives you confidence that:
    • The initial 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.
    Keep the length of time you maintain the initial alert action to a minimum to reduce the chance of a security breach. Transition to the blocking state as soon as you’re comfortable that you’ve identified any exceptions you need to make and configured the profile accordingly.
  • Critical and high severity signatures
    —False positive rates for critical and high severity signatures are typically low and usually indicate an attack against a vulnerability that doesn’t exist on your network. For applications that aren’t critical to your business, such as internet access, block (
    reset-both
    ) 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 and 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.
  • Fine-tune profile rules that alert before you transition to blocking them, especially for internet-facing and data center traffic. Move to blocking as soon as you comfortably can.
  • Set signatures in the brute-force category to alert and then move to blocking as soon as you can. Brute-force events are aggregate events that trigger when an action takes place multiple times in a short time period. For example, one SSH login attempt is an informational event, but 100 login attempts in 10 seconds trigger the brute-force signature. Although it might take time to tune the profile so that normal network traffic doesn’t trigger a brute-force signature, transition to blocking these signatures as soon as safely possible, based on your comfort level.
    Brute-force alert Vulnerability Protection profile
  • The default
    Action
    for most low and informational severity signatures is
    alert
    or
    allow
    . Unless you have a specific need to alert on all low and informational signatures, configure the
    Action
    as
    default
    .
  • If the resources are available, enable extended packet capture for critical, high, and medium severity signatures on which you alert. Enable single packet capture for blocked signatures and for low and informational severity signatures. Enabling packet capture enables you to investigate events in greater detail if necessary. As you move to best practice profiles, if 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 informational events.
    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.
  • For
    Inline Cloud Analysis
    , use the same criteria for alerting versus blocking business applications that you use for the Vulnerability Protection rules. If you have existing controls, you can replicate them to block traffic. For new controls, alert for at least a week before transitioning to blocking. Move to blocking as soon as you can.
    Inline Cloud Analysis alert Vulnerability Protection profile
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. Create exceptions (open a support ticket if necessary) in each profile as needed to remediate confirmed false positives before you transition to full best practices Vulnerability Protection profiles. How fast you complete the transition to best practice profiles depends on your business, applications, and comfort level—be aware that some applications are only used weekly, monthly, quarterly, or yearly for audits, periodic events and meetings, etc.

Recommended For You