Transition Safely to Best Practice Security Profiles

Apply Security profiles to allow rules to protect against malicious traffic without risking application availability.
Security profiles enable you to inspect network traffic for threats such as vulnerability exploits, malware, command-and-control (C2) communication, and even unknown threats, and prevent them from compromising your network using various types of threat signatures (some protections require a subscription).
The end goal is to reach a best practice state for all of your Security profiles. However, to ensure the availability of business-critical applications, it may not be feasible to implement a full best practice Security profile configuration from the start. In most cases, you can safely block some signatures, file types, or protocols while alerting on others until you gain the information and confidence to finish a safe transition to best practice Security profiles without affecting availability.
The path to implementing best practice Security profiles is:
  1. Run a Best Practice Assessment (BPA) on your configuration.
  2. Review the Adoption Summary in the BPA results to see the current state of your Security profile adoption.
  3. Identify gaps in adoption in the BPA results.
  4. Review your Security profile configuration in the BPA results to see the best practice check results for each profile.
  5. Use the following safe transition steps to move toward the best practice state for your Security profiles.
Ask yourself the following questions to help determine the right approach to enabling Security profiles for a given network segment or set of Security policy rules:
  1. Do I already have Security profiles enabled on rules that protect similar applications or network segments? If the answer is yes, you may be able to duplicate those profile settings, including block actions you already deem to be safe to enable.
  2. Is the network segment I’m protecting critical for my business? If the answer is yes and you don’t have proven profiles enabled in similar segments, you may prefer to alert first and examine the traffic that causes the alerts before blocking to ensure the profile won’t block critical applications.
  3. Am I deploying Security profiles to counter an immediate threat? If the answer is yes, you may want to block as the initial action instead of alerting.
  4. Is there a firewall change process in place that allows investigation and remediation of false positives in a timely manner? If the answer is yes, you may be able to block as the initial action instead of alerting.
    The majority of “false positives” are attempted attacks against a vulnerability that doesn’t exist in your network. The attack is real, but the danger is not because the vulnerability isn’t present, so the attack is often seen as a false positive. Brute Force attack signatures can also cause false positives if the attack threshold is set too low.
Consider your current security posture in combination with the guidance for each type of Security profile to decide how to deploy the profiles initially and then move to the best practice guidance.

Related Documentation