BIG-IP ASM Policy Life Cycle

Overview

Before you deploy an application security policy, it helps to have an understanding of exactly what you are trying to protect and why.

• Defining your security problem before you start makes it easier to develop and enforce a security policy.
• Some use cases require more extensive policy development and tuning, while with other use cases, a simple security policy suffices.

The Three Phases

The application security policy life cycle has three phases:

• Phase 1: Create and deploy policy
  • Create a new policy using the template and policy-building mode most appropriate for your web application.
  • Decide whether to automate the policy building process.
  • You can change most decisions made during this phase in later phases.
• Phase 2: Tune policy
  • False positive violations are identified and policy settings are adjusted to allow legitimate traffic to pass through to the protected application.
  • This is necessary as some legitimate traffic may not pass set policy rules and may resemble an attack.
  • Over time, the security policy eventually becomes stricter, meaning that policy components that have not triggered any violations are enforced, and acceptance occurs for elements specific to your application, such as file types, parameters, and HTTP methods.
• Phase 3: Maintain policy
  • The security policy adapts to application changes, new security requirements, attack signature updates, and activities, prompted by the review of logs and reports on traffic inspected by the BIG-IP ASM system. During this phase, keep the policy up-to-date and accurate for the application it protects.
  • A good, finely-tuned security policy deployed according to the security requirements of your application should incur minimal operational costs. A very strict and application-specific security policy can potentially take more time and effort to maintain, especially in light of application changes. A generic, lightweight policy requires very little maintenance, even when applied to multiple or different applications.

Policy Tuning Details

Of the three phases, policy tuning requires the most attention and skill from an administrator. Administrators can choose to manually tune a security policy or have the BIG-IP ASM system tune the policy automatically.
Tasks included in tuning include adjusting policy blocking settings, populating entry lists, and enforcing entities and attack signatures.

• Adjusting policy blocking settings
  • Depending on the policy’s initial settings, the BIG-IP ASM system may need to disable specific violations if they block legitimate requests. Conversely, as more traffic passes the policy without triggering an alarm, the BIG-IP ASM system enforces or enables violation mitigation rules.
  • At the end of the tuning process, the policy should contain all the relevant violations. This is true whether you started with a fully enforced list and tuned it down (“loosened“), or you started with a blank list and enforced violations over time (“tightened“).
• Modular or gradual blocking
  • One of the most successful approaches to tuning a BIG-IP ASM policy involves modular blocking, also known as gradual blocking. Gradual blocking allows some violations to be blocked while others are being tuned. This means you can enable policy components with little-to-no tuning, before the tuning process begins.
• Populating entity lists
  • In an HTTP request, all entities are L7. A BIG-IP ASM policy can contain a whitelist of these entities and disallow entities not on that list, it can contain a blacklist of entities to disallow, including wildcards or matching generic patterns.
  • A BIG-IP ASM policy usually starts with catch-all wildcards (*) for the entity lists (file types, parameters, URIs, cookies, headers, and entities). Depending on the deployment settings, the BIG-IP ASM system suggests specific entities to populate the lists.
  • After the lists are populated, wildcards can be removed and the list enforced. Not all entity types are relevant to all security and application requirements, so F5 recommends tuning to include only those that are important to you.
• Enforcing entities and attack signatures
  • Most policy entities have attributes in them, such as byte lengths, values, characters, and others. You can configure a security policy to enforce those attributes.
  • The tuning phase for each entity is marked with a Staging flag, meaning the entity’s attributes are only checked, not enforced.
  • After all attributes are manually or automatically adjusted to fit legitimate application use, the Staging flag can be manually or automatically removed.
  • Attack signatures behave the same way. All signatures in a policy start in staging. This means that traffic is not blocked if it matches that signature.
  • After you disable the signatures causing false positives, you can turn off staging and enforce the rest of the signatures.
• Additional security checks
  • The BIG-IP ASM system can deploy additional security checks in order to protect the application. This is true even for malicious traffic that does not match disallowed policy elements or attack signatures. These checks include session tracking, web scraping, brute force protection, and denial-of-service (DoS) protection.
  • Session tracking includes the ability to track users and sessions according to their activities in the application, blocking them completely, or logging their requests, whether legitimate or malicious.
  • Web scraping detects non-human behaviors on the website, flagging, and blocking bots with malicious intents, even if all they do is access legitimate resources on the website.
    Note: Starting in BIG-IP 14.1.0, the web scraping feature is combined with the Proactive Bot Defense feature of the DoS profile to form a single unified Bot Defense profile.
  • DoS protection guards the application from heavy traffic patterns and rates that are meant to bring down the application or database, even when each request appears to be in order and does not trigger any of the violations in the policy.