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.
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.
|Fundamental||Provides security at a level that is appropriate for most organizations, creating a robust security policy, which is highly maintainable and quick to configure. This is the default setting.|
|Enhanced||Provides extra customization, creating a security policy with more granularity.|
|Comprehensive||Provides the highest level of customization, creating a security policy with more granularity, but it may take longer to configure.|
|Vulnerability Assessment||Specifies a security policy that is built using the recommendations from a vulnerability assessment tool. By default, the system does not add explicit entities, leaving that to the tool. (Only available if a vulnerability assessment tool is selected on the Vulnerability Assessments Settings screen.)|
|Custom||Provides the level of security that you specify when you adjust settings such as which security policy elements are included in the security policy. The policy type changes to Custom if you change any of the default settings for a policy type.|
|Fast||Builds a security policy using lower threshold values for the rules so they are likely to meet the thresholds more quickly; for example, this setting is useful for smaller web sites with less traffic. Selecting this value may create a less accurate security policy.|
|Medium||Builds a security policy based on greater threshold values for the rules. This is the default setting and is recommended for most sites.|
|Slow||Builds a security policy using even higher thresholds for the rules and takes longer to meet them; for example, this value is useful for large web sites with lots of traffic. Selecting this value may result in fewer false positives and create a more accurate security policy.|
By adjusting the automatic policy building settings, you change the way that Application Security Manager creates the security policy.
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.
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.
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).
Automatic policy building has three stages:
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.
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%.
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.
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.
|Fast||Use if your application supports a small number of requests from a small number of sessions; for example, useful for web sites with less traffic. However, choosing this option may present a greater chance of adding false entities to the security policy.|
|Medium||Use if your application supports a medium number of requests, or if you are not sure about the amount of traffic on the application web site. This is the default setting.|
|Slow||Use if your application supports a large number of requests from many sessions; for example, useful for web sites with lots of traffic. This option creates the most accurate security policy, but takes Policy Builder longer to collect the statistics.|
The system now automatically builds the security policy with the adjusted security policy rules.
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).
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.
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.
|All HIDDEN Fields||Adds to the security policy all hidden form input parameters, seen in responses, as dynamic content value parameters.|
|Using statistics - FORM parameters||Adds parameters from forms as dynamic content value parameters.|
|Using statistics - link parameters||Adds parameters from links as dynamic content value parameters.|
|Statistics: Configure parameters as dynamic if <num>...||Specifies the number (<num>) of unique value sets that must be seen for a parameter before the system considers it a dynamic content value. The default value is 10.|
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.
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.
|Collapse Parameters, Cookies and Content Profiles||When selected, collapses many common parameters, cookies, and content profiles (parameter/URL) into one of each type. In the field, type the number of occurrences (2 or greater) the Policy Builder must detect before collapsing them to one entity.|
|Collapse URLs||When selected, collapses many common explicit URLs into one wildcard URL with a common prefix and suffix. The Policy Builder collapses URLs only in the same directory (with the same prefix path), and if they have the same file extension. For example, the system collapses the URLs /aaa/x.php, /aaa/y.php, and /aaa/z.php into /aaa/*.php. In the field, type the number of occurrences (2 or greater) the Policy Builder must detect before collapsing them to one entity, and type the minimum depth to collapse the URLs.|
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.
|1xx||All informational responses (the request was received; continuing to process it). Included by default.|
|2xx||All successful responses (the request was received, understood, accepted, and processed successfully). Included by default.|
|3xx||All redirection (the client needs to take additional action on the request). Included by default.|
|4xx||Server failed to fulfill the response as a result of client syntax or input errors.|
|5xx||All server error responses (the server failed to fulfill a request).|
|Specific codes such as 100, 306, 400, or 404||Refer to your web application or the Hypertext Transfer Protocol -- HTTP/1.1 specification (RFC-2616).|
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.
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.
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.
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.