Policy Modification

Loosen Policy

• Purpose:

  • Starts with a stricter security posture and gradually reduces restrictions as legitimate traffic patterns are identified.

  • Focused on reducing false positives by adjusting policy rules to match observed legitimate traffic.

• Key Characteristics:

  1. Automatic Legitimate Traffic Recognition:

     • Traffic is automatically declared legitimate once it reaches a predefined threshold of safe behavior.

  2. Reduction in Violation Triggers:

     • Focuses on minimizing violations by adapting the policy to real-world traffic.

  3. Disabling Attack Signatures:

     • Temporarily disables attack signatures for certain types of traffic to avoid unnecessary blocking.

  4. Limited Restrictions During Early Policy Building:

     • Entities are placed in staging, where violations and blocking are disabled to allow observation and analysis of traffic patterns.

  5. Gradual Relaxation:

     • The security posture is adjusted based on observed traffic behavior to ensure a balance between security and usability.

• Use Case:

  • Applications with a well-defined set of behaviors where initial traffic can be used to fine-tune the policy.

  • Organizations concerned about false positives impacting application availability.

---

Tighten Policy

• Purpose:

  • Starts with minimal security enforcement and builds up over time as traffic behavior is analyzed.

  • Focused on strengthening security by gradually enforcing strict rules and removing generic allowances.

• Key Characteristics:

  1. Starts with a Blank List:

     • The policy begins without predefined restrictions, allowing all traffic initially.

  2. Incremental Enforcement:

     • Gradually enforces rules for entities like file types, parameters, and URLs based on observed legitimate traffic.

  3. Attack Signature Enforcement:

     • Attack signatures not triggered during the Enforcement Readiness Period (staging phase) are enforced.

  4. Removal of Wildcards:

     • Wildcards are deleted, and specific entities are defined and enforced to create a stricter policy.

  5. Policy Stability:

     • Once traffic no longer includes new elements, and existing rules have been enforced, the policy is considered STABLE.

• Use Case:

  • New or dynamic applications where traffic patterns are initially unpredictable.

  • Organizations requiring a robust and gradual security posture improvement.

---

Comparison Table

Aspect	Loosen Policy	Tighten Policy
Starting Point	Fully-enforced list with strict rules	Blank list with no initial restrictions
Objective	Reduce false positives and ease restrictions	Gradually strengthen security and enforce rules
Approach	Gradual relaxation based on observed traffic	Incremental enforcement as traffic patterns stabilize
Attack Signatures	Disabled during initial policy building	Enforced after staging period if not triggered
Entity Handling	Entities placed in staging to analyze behavior	Wildcards replaced with enforced entities over time
Policy Stability	Declared when traffic behavior matches relaxed rules	Declared when no new elements are observed
Use Case	Apps with predictable, well-defined traffic patterns	Apps with dynamic or evolving traffic patterns

---

Best Practices

1. Monitor Closely During Transition:

   • Whether loosening or tightening, regular monitoring ensures the policy evolves correctly without compromising security or usability.

2. Balance Security and Usability:

   • Adjust the pace of modification to match the application's criticality and traffic complexity.

3. Leverage Automatic Learning:

   • Use the Policy Builder for intelligent recommendations to minimize manual effort.

4. Plan for Staging:

   • Use the staging period to gather traffic insights without enforcing violations immediately.

By carefully choosing between Loosening and Tightening, organizations can align their security posture with operational goals while maintaining robust protection.