Transition Vulnerability Protection Profiles Safely to Best Practices

• 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 ( MonitorLogsThreat) 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.

• 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, DashboardSystem 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.