1.) I think you meant 'can move policy directly to blocking mode' -> Sure you could. However, you may want to consider reviewing what entities the ASM has learned and modify policy where false positives may have occurred. I'm not sure what you mean by 'or I need to work on violations manually' -> There will most likely always be some level of fine tuning the policy with regards to violations or false positives. Personally, I wouldn't rely 100% on Automatic Policy Build but then again every environment is different. You can work on (tune) the policy, in Transparent Mode, once the Enforcement period is over.
2.)No. It's not mandatory to create a logging profile but consider if you don't, you won't have any logs to review requests be it only illegal requests or all requests. (Probably a good idea to configure a logging profile for the security policy)
--> The system provides three logging profiles that you can assign to the web applications:
• Log all requests (locally)
• Log illegal request (locally)
• No logging
You can also create a non-system supplied logging profile. (Called a custom profile)
3.) By testing the policy. Before Creating the policy, determine what you want to protect against. This will, in a way, help determine what type of policy you'd like to build and how to build it. (Automatic isn't always the way to go) -
Once you've built your policy, test it. (Lack of a better term, "PEN Test" it) - There are free tools on the internet to assist in some basic tests. Basically test against the rules you've built.
4.)I think you're asking if you should use multiple Attack Signature Sets? Not necessarily but it really depends on what you're trying to protect against. ASM give you the flexibility by providing an extensive list of Attack Signatures. There are organizations who use a very general set of Attack Signatures. There are some organizations that use more. And there are some organizations that go through them with a fine tooth comb and choose only the exact ones they need.
Nimbostratus
