ASM policy building with automatic versus manual suggestions

Because applications vary greatly in complexity, and because different applications are vulnerability to different threats, you have options for finding the best balance of protection and policy maintenance for your organization. Think of ASM as the ultimate toolkit for securing your application--and in the same way that you wouldn't use all the tools in a Swiss army knife at once, you won't deploy ASM with all its features at once either. Some administrators know in advance that they have little time for managing security policies. This is why the "automatic" deployment scenario exists. In this scenario, over time, ASM will make all the decisions about which violations should be blocked, or which violations should be allowed (because maybe they're not violations after all), without any human intervention. This is the recommended deployment scenario, and is listed first in the Deployment Wizard. The second method is to create policy manually, or use templates. If you choose the manual method, and then select None, you are telling ASM that you want full control of the security policy building process. This means that nothing will happen automatically.If you use a template, such as Rapid Deployment, you can secure your application from the vast majority of common vulnerabilities by relying on the sophisticated attack signatures, evasion detection, and RFC-compliance offered by that template. This is a good foundation for any security policy. But it will not offer the same level of protection as a policy which secures each file type, each parameter, each URL, etc., that might be exploitable in your app. These elements must be learned and secured over time--either automatically, or by an informed administrator. A good place to start is the free "Getting Started with ASM" course on F5 University.

Hi Mate,

Since you are new in ASM jungle, i suggest you to go for automatic policy creation. This will provide you a balanced ASM policy without any additional work.

As Erik said, you can start learning with F5 university videos and that would be a place good start.

-Jinshu

There is Enforcement Readiness Period with default value 7 days. Does it mean it takes 7 days for ASM to learn the application? Do I need to keep the application running with traffic in order for ASM to learn? Because this is not a production environment so it does not have traffic.

This period is intended to observe enough traffic (requests for entities such as file types, URLS, parameters,) to help you sort out false positive violations from actual threats. During this period, entities and attack signatures are in a mode called "staging" which prevents legitimate requests which triggered a violation from getting blocked. After 7 days, entities are ready to be enforced if no violations have been seen by ASM. If the entity (or attack signature) is enforced, and the policy is in blocking mode, then the next requests that triggers a violation related to it will be blocked. It is recommended that you run traffic (ideally from a trusted IP address) in order to expedite the learning process. If that is impossible, you will have to manually review violations (you can do it from the Enforcement Readiness Summary screen), or configure high enough thresholds for requests from different IP addresses and/or sessions to let the automatic policy builder do it for you. If you are using the Rapid Deployment template, most of your violations will be related to attack signatures or RFC violations.

Thanks Erik. In Virtual Server -> Security tab, there is Application Security Policy drop down. This is where I made changes to test out different policies. In Virtual Server -> Resources tab, on the bottom there is Policies. Even I removed the policies manually, the value with prefix "asm_auto_l7_policy" will be auto populated. I try to figure out what's the relations between two?

Thanks Erik. In Virtual Server -> Security tab, there is Application Security Policy drop down. This is where I made changes to test out different policies. In Virtual Server -> Resources tab, on the bottom there is Policies. Even I removed the policies manually, the value with prefix "asm_auto_l7_policy" will be auto populated. I try to figure out what's the relations between two?

As soon as you enable ASM, you will see a default "asm_auto_l7_policy" in the policies list. This default "Layer 7" policy contains a default rule which forwards all traffic to a single application security policy which you can select. If you have more than one policy, each for protecting different parts of an application for example, you have that option to manually assign a L7 policy to the virtual server as a resource. Alternatively, you can assign security policies to the virtual server from the Security tab.

Thanks. For the policy attack signature, should I select all the checkboxes manually as in attachment? Only few checkboxes are checked by default.

The recommendation is to only use those attack signatures that are relevant to your OS/DB/environment. So if you've got Linux/PHP/MySQL, there's no need to use OWA attack signatures. Having said that, it's not uncommon for admins to select all of the signatures because they don't know what they're trying to protect. ASM is remarkably efficient, but there is a penalty for forcing it track strings indicating that a signature has been hit. When you ran the Deployment Wizard, you arrived at the Attack Signature configuration screen about midway through. That's where you first assign attack signatures to your policy. The generic attack signature set (keeps away script kiddies and common SQL or cross-site scripting patterns) is applied to all policies by default.

Thank you so much Erik. It make sense. I am reading the events and learning events (accept or ignore), is there a good way to test if it is legitimate or attack to avoid false positives and false negatives? I am thinking the response code is a good indicator, but the response code is all 200? Any advices? thanks!!