In the ASM Demo Youtube series, the host uses these iMacros (think a selenium web driver) in order to fire off a bunch of SQL injection and other types of attacks at the site (DVWA) which he is building an ASM policy for. This expedites ASM policy learning among other benefits. My question is relatively simple:
While I am building the policy ultimately for my companies own proprietary app, is it possible to build the policy against something like the DVWA where I can use iMacros to speed up the learning and fire a bunch of attacks at it to learn, and then after it has picked up some nuances of attack signatures and things like that, can I then apply the policy to my companies' app and move it off of the DVWA where the iMacros were tested on. Will something like this work?
Also, any idea where to download some iMacros that are security oriented (as I am not sure I would be confident in covering all of my bases for different attacks that I would like to have ran against the policy to learn before going live in production, and if there were some scripts already out there (commercial is fine) that would be helpful too!
Thanks in advance for any advice!
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.
Cheers man! Thanks for your help and taking the time to go through this with me. It is very much appreciated.
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?
Thank you for your response. The first part about the efficacy of using DVWA and it being an unsuitable substitute for policy building absolutely makes sense. I think that was rather silly on my part now that I think about it.
However the second part of what you are suggesting does not make much sense to me. I guess I don't understand the utility of sending only valid traffic (say, in rapid fashion via something like iMacros to expedite the process).
I should mention that the whole idea for using iMacros to do this is not my own - the F5 ASM Demo training series posted on YouTube (which is a great source of ASM knowledge btw) is where that concept was introduced to me -- and in their demonstration of policy-building (comprehensive, automatic, manual, etc, etc) the gentleman is using DVWA but is simulating things like SQL injection and other malicious traffic to guide the policy building and to prompt the ASM to generate policy suggestions which he would then either accept, deny, or ignore thereafter.
I guess the question is what sorts of advantages would providing only legitimate traffic to the application (NOT DVWA :) ) enable versus how they go about the process of building ASM policies in the training videos?
Thanks again for your help!