ASM automatic learning policy

Hi,

If it is in blocking mode, then it will block. As you can see in the snapshot "Current edited policy" it shows "blocking".

https://support.f5.com/kb/en-us/products/big-ip_asm/manuals/product/asm-implementations-12-0-0/25.html

Yes my But according to F5

"•If the Policy Builder is in Automatic learning mode, it automatically takes the suggested action when the score (also known as the Learning Score) reaches 100 percent. (The score percentage is indicated on the screen.) A suggestion reaches a score of 100% if that suggestion occurs a lot and if the chances of that traffic being a real violation are low, and/or if traffic that triggered the suggestion comes from a trusted IP address."

if the score reaches 100% it means false positive, but it takes the "suggested action" which is to block? So we are blocking on a false positive?..clearly I am missing something.

In making policy for WAF you will ask if "trasparent or blocking mode". In trasparent mode the policy will try to digest and analyze the traffic in a period of one week or more. As soon as the policy is mature enough you can enforce it. Yes, there are a lot of false positive and you can tune up later on by having support ID (Blocking mode) and allowed specific request.

In the policy building you have two tabs, "Traffic Learning" and "Learning & Blocking Settings". In Traffic Learning, there are accept suggestion, delete suggestion and ignore suggestion. If those parameters or request are valid you can accept or do other suggestions. It is better to put your policy in transparent mode to learn more about your specific applications. While in Learning & Blocking Settings you have general settings which are Enforcement, learning, Auto-Apply and learning speed. This is how your policy deal with your application. I think your policy is in blocking mode (Enforcement) and if you didn't define your policy building properly you will have a lot of calls from application owner. The rest of the settings are defaults but you may change it.

It is better to sit with application owner during blocking mode and test the application and this task is tedious and need a lot of patience.

From https://support.f5.com/kb/en-us/products/big-ip_asm/manuals/product/asm-implementations-12-1-0/24.html

About policy building rules If you are using the automatic learning setting, the Policy Builder builds the security policy automatically in three stages. These stages each have separate sets of settings in the Policy Building Process area of the Learning and Blocking Settings screen. Rules in each stage determine when an element in the security policy moves from one stage to the next.

Loosen policy Tighten policy (stabilize) Track Site Changes 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 Learning Speed setting. Slow learning speed causes the system to create the policy by looking at more traffic, over more time, and from more different IP addresses, so the values in the rules are higher. Fast learning speed causes the system to build the policy from fewer requests, from only one IP address, 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 to the Custom policy type (instead of Fast, Medium, or Slow).

About automatic policy building stages Automatic policy building is enabled when you have Learning Mode set to Automatic. In this case, the Policy Builder builds the security policy in three stages:

Loosen Policy 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 makes learning suggestions on ways to update the security policy. Based on wildcard matches, Policy Builder suggests adding the legitimate policy entities (putting most into staging to learn their properties), and disabling violations that are probably false positives. If you are using automatic learning, the Policy Builder implements the suggestions when policy building rules are met, updates the security policy, and enforces the entities. If you are using manual learning and want to enhance the security policy, you can address each of the suggestions that the system made.

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, it then makes learning suggestions. If you are using automatic learning, over time, the Policy Builder adds the entities to the security policy. If you are using manual learning, you can accept, delete, or ignore the suggested additions to the security policy.

Tighten Policy (stabilize) Rules that tighten a security policy are applicable only when you are using automatic learning. 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, or a change was made to any of its attributes.

Similarly, the Policy Builder enforces the entity (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.

Track Site Changes This stage occurs after the security policy is stable, and is only relevant when using automatic learning. 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 suggestions or 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, the Policy Builder continues to monitor traffic and note whether the web application has changed, and if it has, makes suggestions for loosening the policy. However, the security policy is not updated unless you manually change it.

I understand the differences of the modes. The application is not live hence why I have blocking mode and yes I am working with the application owner also I have staging enabled. What I am trying to determine regarding the traffic learning is how to determine whether to accept suggestion or does the ASM automatically select a suggestion based on the score? What happens when the score is 100% for the entity "Failed to convert character" for example , does it take the suggested action? but wont that "set block to enable" but F5 says

"A suggestion reaches a score of 100% if that suggestion occurs a lot and if the chances of that traffic being a real violation are low"

Your policy is in blocking mode, try to navigate to your policy and go to >>Security>Application Security>Policy Building. In "Current edited security policy" select drop-down menu and look for your policy. After choosing your policy, go to "Learning and Blocking Settings", look for Enforcement and again use the drop-down menu to select transparent. ASM had a learning mode and this mode have multiple "Entity Type" such as File TYpe, Parameters and so on. Each Entity have categories like "Learn new Entities, Not Enforced, Not Enforced and Have Suggestions and Ready to be Enforced.

ASM automatically select suggestion based on the learning score. It needs action, that is why you have to enforced and if you have violation but false positive you have to allow it in order the application to work. Some application needs longer string and this string is set 10 by default and the request string is 600 or the Header have POST request it will trigger a violation or block by ASM policy.

Yes, when it gets to 100%, the actions shown will be taken, that is to enable Alarm and Block on that violation.

Staging is not relevant here (failed to convert character) because staging is not a property of Violations -- it applies to URLs, Attack Signatures, parameters etc, so that is not affected.

A way to interpret that particular learning suggestion is that the system is seeing traffic that isn't triggering that violation, so it is 50% sure that it is safe to enable blocking and alarming (more so if you look at the event logs and you don't see any requests that are flagged with this violation).

Each violation is assigned a percentage value which reflects the progress of learning for each entity or item. This percentage value is called the Learning Score. For each request, ASM tracks the originating IP address, the time the HTTP session was opened, how many requests have been made, any violation ratings that have been assigned, and numerous proprietary rules of varying tolerance. The staging status of any entities or violation items is also considered for calculating the learning score. High-rated illegal requests will lower the score and slow down the acceptance of the respective suggestions induced by those requests, while speeding up and raising the score for suggestions induced by low-rated requests. You are correct that in automatic mode, a learning suggestion is accepted when the learning score reaches 100 percent. You can test this by creating a trusted IP address, and then sending a request from that IP--the score will be 100 percent immediately because the request came from a trusted source. In production, this takes longer. Check out the Policy Building Process menus on the traffic learning screen. You can see how many requests from different IP addresses must be processed for loosening and tightening the policy. In your example, 512 requests triggered a specific violation--if numerous requests are triggering the same one, then ASM will ultimately decide that those requests are valid and that the violation is a false positive. Make sense?

"but what does it mean when it says "512 requests triggered this suggestion"

It means precisely that, that the "failed to convert character" violation has been seen 512 times during the Learning/Enforcement Readiness Period.

This is a relatively high number of occurrences so its pushing the learning score up each time it sees this violation occur. When it reaches 100% the Automatic Policy Builder will accept the violation into the policy as a required part of the policy in order to allow the application to function correctly.

However, the default behavior for a violation of this type is to Alarm and Block and therefore when this violation type is moved into the Policy and Enforced (as its already in Blocking Mode) any future violations will be Alarmed and Blocked giving you in this case a false positive result.

Automatic Policy Building is great but you do still have to weed out the odd False Positives.