Using iMacros to Expedite ASM Policy Traffic Learning

Building a policy based on DVWA and then using that same policy to product your app is not a good idea for a few reasons. First, unless the back-end server technologies used by your application are the same as DVWA, the attack signatures applied to requests for DVWA are not likely to be the same ones that would make sense for your app. Second, the policy isn't learning attack signatures. It is trying to match its own attack signature sets (assigned by you) to patterns that are detected in traffic and will then alert you when a potentially malicious character string is found. A better approach is for you to build a policy for your application and then configure a trusted IP address from which you send clean traffic. Automated tools such as iMacros would be fine for that--but only send valid requests which mimic legitimate traffic. Depending on the comprehensiveness of your policy, this might take a few hours or several days. After you are satisfied that the policy has learned legitimate behavior (requests for allowed file types, URLs, parameters, etc.) then you can place that policy into production. For penetration testing, you can try using the Kali attack server against your policy. Does this help?

Hi Cameron, one of the most important issues you will face during policy building is handling false positive violations--legitimate requests which trigger a violation. The goal is to end up with a security policy which will block only those requests which are known to be illegitimate, illegal, malicious, etc. This ensures that your legitimate users won't have a bad or degraded experience with your application. To get there you can certainly use iMacros to record interactions and then play them back at ASM. However, if any number of those interactions trigger violations, you will have to review learning suggestions to tune your policy so that false positives are eliminated. By sending only legitimate traffic, from a trusted IP address, you can speed up the rate at which ASM will learn correct behavior and then deploy the policy based on this data. "Trusted" in this context means you're telling ASM that all requests from this client are safe. So if you send a SQL injection from a trusted IP then ASM will assume that future SQL strings of this type, from any other client, are allowed--not good. The goal of my original answer was to reduce the amount of administrative work you will have to do regardless of how you are generating traffic. Here's link to the ASM Operations Guide which can help you sort all of this out.