Hi, cyber security fans. After 3 parts devoted to WAF managed rules, I am excited to introduce you to the AWS WAF managed rules configuration methodology. Here is flowchart diagram, that, which I hope will help to understand it better.
Let’s pass together via every algorithm step. So, we are starting from all AWS managed WAF rules. At the next step you have to choose only groups that are suitable for your exact application. For example, in case Flask test app, which I am using as example at my course, where that material comes from, there is no sense to choose PHP or windows rule sets.
We are going further and using logical considerations exclude rules that do not make sense in application context. For example – you may do not block requests if user agent is missing (there is such a rule at common rule set). Then we continue to manage rules reduction by excluding rules that cause false positives after running tests using block mode. Finally we switch all rules at count mode and apply them at production for 1-2 weeks. We are gathering data, and when it would be done – it is time to provide false positive analyzing at WAF logs using Athena.
As we already talked, for bigger applications, it is better to split data for analyzing at smaller parts and send it to different company workers in parallel. After that we have to take some AWS managed group, or some small subgroup of rules in case we have a deal with a common rule set and apply those rules at prod for 1-2 weeks. The time depends on your application. If you feel it can be shorter – then use several days.
Within that time you have to regularly check the WAF logs at false positives and stay in contact with the support department – to be aware of any non standard behavior that can be caused by WAF rules implementation. You need to repeat the current loop until all rule groups would not be activated at block mode.
Unfortunately your job is not finished, you have to continue WAF logs verification. First of all, it is because of rare scenarios that could be bypassed by initial false positives verification. At second, it is worth to do it because you can learn a lot about new attacks that appear in the market. For example, recently I found a strange serialization attack, which I am showing in details at the course. I have never seen such a payload, so it was interesting to understand how it works and test it at other applications. That is why, despite the fact that you can set alarms at WAF metrics, I still strongly recommend to perform manual verification at least once per quarter.
Moreover, it is always better to do it in addition after every major release. As you understand, in case of bigger changes in code, the data structures can be changed a lot also, and that can generate new false positives, though from my experience it appears that it happens very rarely.
What is much more problematic – that is major updates at AWS managed rules by itself. It also does not happen often. Surprise 🙂 Yes, AWS managed rules also have their own release. Hacker’s attacks are constantly improving, new vulnerabilities are appearing, so AWS have a lot of work to adjust AWS WAF managed rules to the new realities. That is why it is very essential to fix the managed rules version, and that is what we have done at terraform code within part 2.
If you will not do it – then AWS will use the last version as default. I can say from my experience that minor updates never created any problems for me. But major updates – it is completely another thing, Unfortunately in that case – it is better to perform all adjustment steps again. Moreover, new rules sometimes appear – so you will have to analyse them separately. In the end of the current lecture I would like to show you one useful aws cli command, that allows you to get versions for WAF AWS managed rules. Here is how it looks:
aws wafv2 list-available-managed-rule-group-versions --scope=REGIONAL --vendor-name AWS --name AWSManagedRulesCommonRuleSetIf you like that material, and want to understand it better – then welcome to my course “DevSecOps: How to secure Web App with AWS WAF and CloudWatch”. As reader of current blog, you may find coupon with discount here. At next step I would propose to turn on AWS managed rules and check how WAF works in action using different malicious requests. That is what I am doing at my course as next step, and that is, unfortunately, is not possible to recreate at paper. So, my proposition is the next one – simply click at button below, paste discount code and let’s have fun together:
