AWS WAF Essentials: Securing Your SaaS Services Against Cyber Threats

When you build public APIs or cloud-based applications, malicious actors will eventually attempt to disrupt and damage your customers’ experience.

These attacks, known as distributed denial of service attacks (

However, bots don’t always launch full-scale attacks. They access sites for various reasons, including indexing (think about the Google search engine), which makes them “good” bots.

A bad bot is a computer program that either tries to steal data by scraping data or probing for vulnerabilities in preparation for an incoming attack. Luckily, we can protect ourselves from malicious bots while allowing the “good” bots to do their work. If you want to learn more about good and bad bots, check out CloudFlare’s .

AWS Web Application Firewall (WAF) Introduction

AWS WAF is a web application firewall that lets you monitor or block the HTTP(S) requests forwarded to your protected web application resources. You can protect the following resource types:

• Amazon CloudFront distribution




• Amazon API Gateway REST API




• Application Load Balancer




• AWS AppSync GraphQL API




• Amazon Cognito user pool




• AWS App Runner service




• AWS Verified Access instance

As you can see from the list above, AWS WAF can protect both your container-based and Serverless services.

To understand how WAF provides an extra layer of security, we first need to understand how it works. Let’s see how we can configure WAF to protect our SaaS service.

ACL and Rules

To use WAF with your AWS resources (as defined above), create a WAF access control list (ACL), define its rules, and associate the ACL with the resource you wish to protect.

The associated resources forward incoming requests to AWS WAF for inspection by the web ACL. In your web ACL, you create rules to define traffic patterns to look for in requests and to specify the actions to take on matching requests. —

Another important notion to remember is that rules have priority. WAF examines traffic from the top priority to the bottom, and when a rule matches its conditions, it performs the defined action, whatever it may be.

Lastly, you can enable CloudWatch metrics for your WAF rules. I suggest you enable them as they provide valuable insight into whether they make a difference (know what and why you’re paying for!). For more information, check the AWS and always consult with a security expert.

Now that we have the basics out of the way let’s head over to my tips and tricks section, which discusses working with WAF and using it in an enterprise SaaS environment.

AWS WAF Tips & Tricks

In this section, I will provide insights and tips I’ve gathered using AWS WAF in my organization. The tips span team ownership, organizational governance, logs, and debugging issues in production and ongoing WAF ACL maintenance.

Ownership

Security experts, whether they are internal security architects or external security advisors, play a crucial role in analyzing your service’s attack vector and constructing the set of ACL rules. The security architect also has the task of monitoring the overall adoption of WAF across the organization and the rules metrics over time (are they making an impact? do they match?).

Developers, on the other hand, are responsible for translating these rules into AWS CDK or Terraform IaC templates (more on that in the second post of the series). The developers will deploy the WAF ACL, associate it with their service resource (API Gateway), and add custom rules if needed.

If there’s a WAF issue, customers are unable to connect to the service, etc., developers can view the WAF logs and traffic and resolve the incident with the help of the security architects.

This approach is a good balance between governance and team independence.

Governance

Speaking of governance, in the next post, we will discuss how to manage these rules in a centralized manner. Meanwhile, it’s recommended to use a CDK construct or a Terraform template as a black-box architectural pattern containing all the recommended rules and deploy them across the organization. You can read more about this concept in my AWS.com article with Anton Aleksandrov “

However, my preferred option is option number three, using a local CloudWatch group, as it is simple and allows the developers to use CloudWatch insights and tools to debug the WAF logs on their account, so no special permissions are required. If you choose this option, set log retention time to 7–14 days at max to reduce log storage costs.

For more information, check out AWS

While I’d rather add maximum security and build the perfect ACL with all the rules possible, it’s not possible due to the 5000 WCU limit. You need to find the correct balance between security coverage and overall WCU. Try to use AWS-managed rules as much as possible, as they are more WCU-optimized and well-maintained.

Another critical issue is the cost. WAF is expensive as you pay for rules, ACLs, and traffic volume that goes through the ACL. For more details, check out the pricing calculator.

Summary

In this post, I introduce the AWS Web Application Firewall and explain why you should use it. We also covered the basics of ACLs and rules. Lastly, I shared some crucial tips that I’ve learned from using and updating WAF in a large enterprise.

In the next post in the series, I will provide AWS CDK code for WAF deployment and associate it with an API Gateway.

In that third post, we will review AWS Firewall Manager and how it allows the organization to manage AWS Application Web Firewall ACLs at scale.