ASM : Working with blocking mode only

Thank you Jacob for confirming that. I was told long time ago by an F5 integrator, that blocking and learning at the same time was not possible, but this is wrong if i got it well.

 

The underlying idea of my post is that a team is working on blocking mode directly in qualification, saying that they have no time for learning and limited storage for logs on their bigip. The result of a specific application policy deployment is that blocking mode provides too many blocking, they switch to transparent and this made things better to stabilize the policy according to what they said.

 

In preproduction we should have trusted sources, so working in transparent mode should make more sense. In blocking mode, maybe some blocked requests is delaying the possibilty to run subjacent ones, where as in transparent a full browsing of the application is possible in a shorter amount of time.

 

For experienced ASM administrators I always recommended that a policy be in blocking mode from the start whether building in production or preproduction environment . This is in fact what the Fundamental and Comprehensive deployment templates do beginning with v13.0. With the policy properly configured there is no issue with ASM blocking requests in this state since all attack signatures are in staging by default and if you are learning entities (file types, urls, parameters, etc) they are also in staging after accepting them into the policy. Staging prevents blocking at a more granular level (per signature/entity) and gives you time to sort out false positives before enforcing (disabling staging) a signature/entity. The advantage with this approach is that as you gradually enforce elements of the policy you increase the application security. When building a policy this way it is important to be aware that there are some elements of the policy which do not have the staging option. For example, if the violations under the Policy General Features, HTTP protocol compliance, and Evasion technique detected are enabled and set to block then ASM will will block traffic that triggers them. You should disable the violations or disable blocking for them until you confirm they will not cause false positives.

 

All that being said, if you do not have much experience with ASM then using transparent mode is the safest way to go.

 

Hi G.Scott, Thanks a lot for your comment. I just found out that i forgot to tell you that i meant by Blocking, also Signatures and Entities (out of staging). Nothing in staging in fact, everything blocked from the start of the preproduction deployment.

 

I agree that this approach looks strange even for a preproduction with trusted sources (and controlled sources), like it does for me (i never seen this before).

 

The reason seems to be the lack of time to work on ASM. I'm trying to provide arguments to improve this way to work, to make things better, but i haven't been dealing with this before so i need to dig the topic.

 

Hi,

 

Transparent mode gives you the ability to get your policy setup around your infrastructure without blocking any traffic. There is no additional benefit. It simply does not take action against traffic. The awesome part is that you can create a policy without the fear of taking down your application. This includes being able to enforce any attack signatures, URLs, parameters, cookies, etc. The idea of transparent mode is to get your policy as close as possible to perfect, meaning eliminating false positives and ensuring that you will be blocking legitimate attacks from day one when moved into blocking. When you feel you have a secure policy but are still going to be blocking attacks you can move it into blocking. Be sure to watch the event logs when you do move it into blocking.

 

As far as the working with blocking mode only, I would definitely have the policy set to manual mode and not automatic mode. Especially when you traffic that is not necessarily trusted. Automatic will make changes based on the suggestions from learning mode. It stacks up requests based on how many times it has seen a particular request. Manual will require a user to press accept suggestion, where as, automatic will automatically accept it for you. You can see how this could be a vulnerability.

 

In conclusion, use automatic in a trusted environment, in transparent mode to initially build your policy; when you feel you have a solid policy, meaning, not too many false positives or false negatives, move it into blocking and manual mode.

 

If you have further questions,

 

Let me know.

 

Jake