ASM staging in Transparent and Blocking - what is difference

Piotr,

If an ASM object(e.g. signature/parameter/URI) is in Staging this means that when the Policy is in Blocking mode any violations relevant to this object will NOT BE BLOCKED.

Staging is useful when your Policy is in Blocking mode, but the we application you are protecting changes and you want to add new URI/Parameters/signatures in such a way without causing a block (basically have a selective transparent mode for that object).

Enforcement Readiness Period is basically a safety catch. It is there to protect you from generating unnecessary Blocks (false positives) by making sure you wait X number of days before you are allowed to click the Enforce button. It is assumed that the duration of the ERP will give you (the ASM Administrator) enough time to analyze the violations, weed out the false positives and tune the policy to minimize them without causing actual blocks and affecting live users.

So after the ERP is over the learning does not stop, you just get a chance to Enforce.

There is NO AUTOMATIC ENFORCEMENT IN ASM. Remember this. Otherwise you will wake up one night by the angry helpdesk calls of people screaming that the application has stopped working in the middle of the night because ASM has started enforcing something and it is causing false positive blocks :)

Enforcement is always manual and it is the ASM Administrator's decision to click on the Enforce button.

Hope this helps,

Sam

Hello Piotr, Transparency applies to the overall security policy. A security policy in transparent mode will never block an illegal request. A security policy in blocking mode can block requests if other conditions are met. Staging applies to 2 vastly different things: the entities of a web application which have enforceable attributes (such as byte length), or violation rules which can be turned on or off, such as attack signatures. If a violation occurs involving any entity or other rule which is in staging, the request will not be blocked even if the policy is in blocking mode. Transparent mode guarantees that no requests will be blocked. If you have a complex application, and you need to allow time for ASM to learn the attributes of entities (such as parameters and cookies), and/or you need to allow time for ASM to identify attack signatures which are causing false positives, you use the Enforcement Readiness Period to control how much time to allow for traffic to be observed. During this time, you can assess violations and determine if they are false positives or not. When you are ready, you can remove entities from staging, one at a time, or as a group, by Enforcing them. This allows you to reduce false positives which harm the user experience. After the default period expires, ASM will designate entities and rules as ready to be enforced. However, you always have the option to Enforce an entity earlier if necessary.

For rules that are in staging, you have the option to Enforcing them, which removes staging, or to disable them entirely--at either the policy level, or if they are applied to an entity at a granular level.

Learning will occur as long as a wildcard exists for those entities for which learning attributes is relevant.

The Real Traffic Policy Builder option can automate this process. By using trusted traffic first, many administrators can build a robust policy.

I would add that learning suggestions will occur as long as the "Learn" checkbox for a given violation is enabled on the "Blocking Settings" list regardless of the enforcement mode (transparent/blocking).

You are really great, to be honest from your posts I learned more than during whole day of playing with lab and reading docs!!

I have one more question (can't promise that last :-)

Can't really figure out how exactly three options for entities work - I mean Never (wildcard only), Selective and Add All Entities.

Taking File Types as example:

I assume that with first option * entry stays forever in Allowed File Types, values for all parameters (like URL Length) are set to Any here - so in fact any kind of files with any parameters will be allowed - seems to me as there is no much learning here - Am I right? By default for this entry (when Rapid Deployment Policy is used) staging from beginning is disabled (11.6.0HF4). What if it would be enabled?

How other options are working? What will happen with second option if two URLs, /index.html and /someurl/page.php will be accessed - will those be added as explicit entries to Allowed File Types List? Again for this setting * entry should stay in the list? If so what will happen after ERP period is over?

What with last option for the same scenario as above - will two entries be added? I guess for this scenario in the end * entry should be removed?

If that is not to much to ask - when given option should be used in real life? What are pros and cons or how process of creating final police would be different?

Sorry for so much questions but if you will find time I will really appreciate expert advice and knowledge!

Piotr

Another setting I am puzzled by.

When Explicit URL is defined in Allowed URLs it's possible to check Perform Staging.

Then in Help it's described like that:

"Specifies, when checked (enabled), that the system places this URL in staging. If you place this URL in staging, the system does not block requests for this URL."

I wonder what does that mean? If URL is defined in Allowed URLs how it can ever be blocked even if it's not in staging? Is above statement correct or it's just generic description of staging behavior not really related to Allowed URLs?

Piotr

Piotr,

You ask a lot of good questions. Regarding:

Yes learned entities may be in staging. Learning of allowed entities (file types, urls, parameters, etc) occurs in two stages. The first stage is learning the explicit entity, for example, index.php. The second stage of learning allows for fine tuning the attributes of the explicit entity. File types have length limitations that can be adjusted. Parameters have a number of attributes such as type, allowed meta-characters, allow empty value, and so on. When ASM learns an entity it is place in staging automatically so you have the opportunity to adjust it's attributes for your application. Once it's correct then it should be taken out of staging (this is also referred to as enforcing or enforced). Only then will ASM block traffic that does not comply with the entities settings, for example, if the query string in a request is more bytes than the policy allows for a file type or an allowed parameter contains a XSS attack. The important thing to remember (as covered earlier in this thread) is that ASM will not block anything that is in staging. For ASM to block traffic the security policy must be in blocking mode, the entity or attack signature must bo out of staging and the relevant violation must be set to block on the Blocking Settings list. Even then ASM may not block sometimes, for example, if an allowed parameter is set to "Ignore value" then ASM does not apply any attack signatures or other security to the value of the parameter.

Your first impression is correct. ASM will make learning suggestions on the Manual Traffic Learning screen when a request exceeds POST data length for an allowed file type in the policy, provided that the "Illegal POST data length" violation is set to "Learn" on the Blocking Settings Violation List. You then have the ability to "Accept" the new maximum length that ASM suggests which will cause ASM to modify the POST data length setting for the file type.

Correct.

Correct, when you are using manual policy building.

BTW, based on your production experience which way of creating policy is most convenient for building policy when more advanced setup is necessary - Rapid Deployment Policy and then manual tweaking or starting from the begging with Real Traffic Policy Builder and then fine tuning based on collected data?

I know that there is no single answer for every configuration but probably there are ways that are used more often than other, or maybe you can share some hints when to use one way and when another?

Piotr

Scott, you should write how to guide or ASM for Dummies! Way you are explaining things is 100 times better than all ASM related official docs I was reading till now, I appreciate your help very much!

Piotr

That SOL8866: Disabling attack signature checks for specific objects has info that I can't figure out:

You can disable attack signature checks for specific objects. This functionality allows you to prevent an attack signature from triggering for a valid URI request, header, parameters or other attributes within the request while leaving the attack signatures in place for the entire policy.

The BIG-IP ASM security policy does not trigger an attack signature if a matching signature is found for an explicitly defined object. To configure an object as an explicit object, to prevent false attack signature triggers, perform the procedure appropriate for your ASM version:

Note: This only applies for signatures that use the objonly attribute. If the signature is written using the uricontent attribute, a specific URL does not cause the attack signature to trigger.

Note: An attack signature is triggered when a signature matches the explicitly defined object and additional parts of the object, if not defined within the explicit object. This behavior is by design; it ensures that the administrator is notified, and information that attempts to pass is flagged if it has not been explicitly defined by the administrator.

I am puzzled especially by two Note entries.

Article is to disable signatures on some entities. That is achieved by defining for example explicit URL, then what they mean in first note?

What second note means? That if part of explicit entity is not specified then signature is triggering violation?

Piotr