Applies To:
Show VersionsBIG-IP ASM
- 11.5.10, 11.5.9, 11.5.8, 11.5.7, 11.5.6, 11.5.5, 11.5.4, 11.5.3, 11.5.2, 11.5.1
Overview: Configuring automatic policy build settings
Application Security Manager completely configures the automated policy build settings according to the selections you make when you created the security policy. You can review the settings, and change them later if needed.
There are two levels of automated policy build settings: basic and advanced. The basic settings are sufficient for most installations, and require less work. The advanced level allows you to view and change all of the configuration settings if you want further control over security policy details. However, in most cases, you do not need to change the default values of these settings. F5 highly recommends that you use the default settings for automatic policy building.
Task summary
Configuring automatic policy building settings
If you are an advanced user, you can review or adjust the settings that the system uses for automatic policy building. In most cases, you do not need to change the values of these settings.
By adjusting the automatic policy building settings, you change the way that Application Security Manager creates the security policy.
About security policy elements
A security policy element specifies a part of the application that Application Security Manager (ASM) is protecting, and indicates what to include when building the security policy. Examples of policy elements are HTTP protocol compliance, file type lengths, parameter value lengths and name metacharacters, methods, header and cookie lengths, attack signatures, evasion technique violations, and so on. These elements included form the basis of the security policy that the automatic policy building process is creating.
Different policy types specify different sets of policy elements. The fundamental policy type includes the fewest number of policy elements, and the comprehensive type includes nearly all policy elements. When traffic accesses the web application that the policy is protecting, ASM verifies details about the selected policy elements. For example, if HTTP Protocol Compliance is selected, ASM checks that the traffic is protocol-compliant. If attack signatures is selected, the security policy examines the traffic for patterns in the signatures. The same goes for the other policy elements included in the security policy.
Modifying security policy elements
When you create a security policy, the policy includes security policy elements such as file types, URLs, parameters, evasion technique violations, and so on. These elements form the basis of the security policy that the automatic policy building process is creating. You can modify which security policy elements are included in the security policy.
The security policy now includes the policy elements that you selected. The system examines legitimate requests and responses from different sessions and different IP addresses, over a period of time. It then populates the security policy with the security policy elements it finds, and puts them in staging.
About automatic policy building rules
During automatic policy building, the Policy Builder builds security policies in three stages. These stages each have separate sets of settings in the Rules area of the Settings screen. Rules in each stage determine when an element in the security policy moves from one stage to the next.
Some of the rules have different values depending on whether the traffic comes from a trusted or untrusted source. The system generally considers trusted traffic, and the policy elements it contains to be legitimate, and adds them to the policy more quickly than it does those in untrusted traffic.
You can adjust the values for the rules by changing the Policy Builder learning speed. Slow learning speed causes the system to create the policy by looking at more traffic, so the values in the rules are higher. Fast learning speed causes the system to build the policy from fewer requests, and the values you see in the rules are lower.
Advanced users can view and change the conditions under which the Policy Builder modifies the security policy during any of the three stages. Changing the values in any of the rules (to values not matching any of the default values) also changes the learning speed and chances of adding false entities settings to the Custom policy type (instead of Slow, Medium, and Fast).
About automatic policy building stages
Automatic policy building has three stages:
Accept as Legitimate (Loosen)
During this stage, the Policy Builder identifies legitimate application usage based on repeated behavior from sufficient different user sessions and IP addresses, over a period of time. The system updates the security policy accordingly. Based on wildcard matches, Policy Builder adds the legitimate policy entities (putting most into staging to learn their properties), and disables violations that are probably false positives.
For example, when the Policy Builder sees the same file type, URL, parameter, or cookie from enough different user sessions and IP addresses over time, then it adds the entity to the security policy.
Stabilize (Tighten)
During this stage, the Policy Builder refines the security policy elements until the number of security policy changes stabilizes. For example, the Policy Builder enforces an entity type after it records a sufficient number of unique requests and sessions, for different IP addresses, over a sufficient length of time since the last time an explicit file type, URL, or parameter was added to the security policy.
Similarly, the Policy Builder enforces the entity's attributes (takes them out of staging) after it records a sufficient number of unique requests and sessions from different IP addresses, over a sufficient length of time for a particular file type, URL, parameter, or cookie.
When the traffic to the application no longer includes new elements, and the Policy Builder has enforced the policy elements, the security policy is considered stable and its progress reaches 100%.
Track Site Changes
This stage occurs after the security policy is stable. If the Track Site Changes setting is enabled and the Policy Builder discovers changes to the web application, it logs the change (Site change detected) and temporarily loosens the security policy to make the necessary adjustments. When the Policy Builder stabilizes the added elements, it re-tightens the security policy.
Although it is not recommended, you can disable the Track Site Changes option. If you do, when the security policy progress reaches 100% stability, the system disables automatic policy building. The security policy is not updated unless you manually change it, or restart automatic policy building by re-enabling the Track Site Changes option.
Modifying security policy rules
Automatic policy building rules specify how a security policy is built. When you create the security policy, values for the rules are set according to the policy type you select. Advanced users can view and modify the rules, for trusted and untrusted traffic, if your application has unique requirements. In most cases, you do not need to change the values of the rules.
The system now automatically builds the security policy with the adjusted security policy rules.
Adding trusted IP addresses to a security policy
In a security policy, you can include a list of IP addresses that you want the system to consider safe or trusted.
Application Security Manager (ASM) processes traffic from trusted clients differently than traffic from untrusted clients. For clients with trusted IP addresses, the rules are configured so that ASM requires less traffic (by default, only 1 user session) to update the security policy with entity or other changes. It takes more traffic from untrusted clients to change the security policy (for example, if using the default values).
Learning from responses
If you are using automatic policy building, you can have the system examine responses as well as requests for entities to include in the security policy. This is called learning from responses, and the system does this by default. You may want to learn from responses because a response might include more information about the web application than is found in the request. You can disable this setting if your application does not need to examine responses for entities to add to the security policy, or if the application does not use dynamic parameters.
If you disabled the Learn from responses check box, the Policy Builder never adds to the security policy elements found in responses. If the check box is enabled, the Policy Builder adds elements found in responses to the security policy.
Specifying when to add dynamic parameters
Dynamic parameters are those whose values can change, and are often linked to a user session. If you are using automatic policy building, you can specify the conditions under which the Policy Builder adds dynamic parameters to the security policy.
When the Application Security Manager receives a request that has an entity (for example, a file extension or URL) containing a dynamic parameter, the system collects the parameter value or name from web application’s response to the request and adds it to the security policy.
Collapsing entities in a security policy
When using automatic policy building, the system automatically simplifies your security policy by combining several similarly named explicit entities into wildcard entities. For example, multiple parameters beginning with paramare combined into param*. You can specify which entities should be collapsed and after how many occurrences.
Learning based on response codes
When using automatic policy building, the system automatically learns from legitimate traffic including transactions that return response codes of 1xx, 2xx, and 3xx. These classes of codes are added by default to the policy building settings. You can change which response codes are listed, or add specific response codes, such as those used by the web application you are protecting.
Limiting the maximum number of policy elements
When using automatic policy building, the system has reasonable limits to the maximum number of file types, URLs, parameters, and cookies that can be added to the security policy. These limits work fine for most situations. You can adjust the limits if needed.
- If the web site requires more than the maximum number of elements, you can increase the limits, or reconsider the type of the policy (you may not need to include all the elements explicitly).
- If the site includes a dynamic element that the Policy Builder cannot learn (such as dynamic sessions in URL or dynamically generated parameter names), either configure the security policy to include the element (for example, dynamic sessions in URL), or clear the element type. The Policy Builder should not be configured to learn that element type in such an environment.
Specifying the file types for wildcard URLs
When using automatic policy building, for security policies that are tracking URLs (policy types other than fundamental), the system adds a wildcard URL instead of explicit URLs for commonly used file types. You can specify which file types are changed to wildcard URLs.
Restoring default values for automatic policy building
If you have adjusted the settings for automatic policy building and want to replace those values, you can restore them to the system default values.
Stopping and starting automatic policy building
You can start the Real Traffic Policy Builder, which automatically builds a security policy. When you use automatic policy building, the Policy Builder can update the security policy as needed, adding elements, for example, if changes occur on the application web site. You can manually stop automatic policy building at any time, such as when the security policy stabilizes, and you think the web application will not change for a while. However, you do not need to stop Policy Builder because the system does this automatically
For security policies that were created using one of the manual methods or imported from an earlier release, you can start automatic policy building so the system builds the security policy for you. By examining the traffic going to the application, the Policy Builder can add various web site entities to the security policy in order to enhance it.
If you stopped automatic policy building, the security policy remains the same unless you manually add to it. If you started automatic policy building, the Policy Builder automatically discovers and populates the security policy with the policy elements (such as file types, URLs, parameters, and cookies). As the Policy Builder runs, you see status messages in the identification and messages area at the top of the screen. You can monitor general policy building progress, and see the number of elements that are included in the policy.