I work at CyberArk, a cybersecurity company, as an R&D Product Security Architect, where security is not just a job but a mindset. Security concepts are constantly on my mind, inspiring me to write this blog to share my knowledge and practical solutions.
Managing consistent security policies across multiple AWS accounts is a complex challenge for many organizations. When each team independently manages its web application firewall (WAF) ACL rules, misconfigurations can arise, leading to inconsistencies and potential vulnerabilities.
In this post, you will learn how AWS Firewall Manager addresses these challenges by enabling organizations to set up, manage, and enforce Web Application Firewall ACLs and rules across all accounts from a single, centralized location. This approach simplifies governance and strengthens security across the organization.
I will also provide an AWS CDK code to get you started with the Firewall manager.
Guest Writer Introduction
Yaron Ben Ezra is an R&D Product Security Architect at CyberArk.
You can follow Yaron on his LinkedIn Page.
Table of Contents
The Challenge of Managing AWS WAF
AWS WAF is a powerful tool for protecting web applications from threats like SQL injection, cross-site scripting (XSS), and other vulnerabilities. However, deploying and associating WAF ACLs with services such as API Gateways or CloudFront distributions introduces governance challenges in a multi-account, multi-team environment:
Who defines these rules?
Who ensures they are consistently applied across all accounts?
When individual teams manage WAF rules independently, inconsistencies and misconfigurations can occur. Some teams might quickly implement updates, while others delay or misconfigure settings. This decentralized approach can lead to security gaps and inefficiencies, making it harder to maintain a robust security posture.
If you want to learn more about AWS WAF, check out Ran's post about it.
The Solution: AWS Firewall Manager
AWS Firewall Manager simplifies the process of managing WAF ACL rules and other security policies across multiple AWS accounts. It provides centralized control over security policies, including AWS WAF, AWS Shield, and VPC security groups, enabling organizations to ensure consistency and minimize misconfigurations.
When enabling AWS Firewall Manager, AWS requires you to enable AWS Config. AWS Config allows you to assess, audit, and evaluate the configurations of your AWS resources. While AWS states that enabling AWS Config is necessary, the service will still function without it. The policy will be created, and the rules will be deployed; however, without AWS Config, you’ll lose visibility into deployments and won’t have metrics available for your rules. For organizations looking to maintain comprehensive oversight, enabling AWS Config is strongly recommended.
With Firewall Manager, administrators can define, deploy, and monitor security policies from a single account. This unified approach streamlines operations, enhances compliance, and strengthens security across the organization.
By adopting AWS Firewall Manager, we transitioned from a fragmented, team-driven approach to a centralized governance model. This shift eliminated inefficiencies, reduced risks, and allowed us to respond quickly to emerging threats.
From Chaos to Clarity
AWS Firewall Manager has been instrumental in helping us maintain a consistent and robust security posture. By centralizing governance, we ensured that security measures were reliable, adaptable, and consistently applied across all accounts.
Governance isn’t just about creating rules—it’s about building a framework that makes security scalable and effective. AWS Firewall Manager is a game-changer for organizations looking to simplify security management and enhance their protection.
AWS Firewall Manager in Action
Let's take a look at the following AWS organization. Let's assume that every OU is managed by a different team in the company.
Above you can see the AWS organization managing Two Organizational Units (OU):
OU Y managing accounts: 111111111111, 222222222222.
OU X managing accounts: 333333333333.
And one AWS account 444444444444
In the old approach, before using Firewall Manager, each team defined its own WAF ACL and ensured it was deployed on its accounts. As discussed before, this led to inconsistency and poor governance.
Let's create a centralized WAF ACL with a Firewall manager.
In this image, you can see that I enabled the AWS Firewall Manager in the organization. When enabled, you were asked to select an admin account to manage the FM. In my case, I used the management account (you can select a different account). From there, I deployed the WAF with my ACL rules.
What happened next was quite impressive - the Firewall Manager created instances of the centralized WAF ACL in the OUs automatically and transparently!
With the implementation of centralized WAF ACLs, teams are now required to associate their services, such as API Gateways and CloudFront distributions, with the organization-wide ACL. This association ensures that all applications benefit from a baseline level of protection.
The beauty of this approach is its transparency—any updates or changes to the centralized ACL are seamless for the teams, as they are applied automatically. Furthermore, teams retain flexibility: they can add custom rules specific to their applications. These rules are automatically integrated into the middle rules section of the ACL, allowing for customization without compromising the overall security posture. More on that in the next section.
Firewall Manager Security Policy
Now that we understand the basics of FM, let's take a look at its security policy features.
A set of ACL rules and guidelines designed to protect an organization’s data, systems, and resources from unauthorized access, misuse, and threats. It defines security standards, procedures, and responsibilities, ensuring consistent protection and compliance across the organization.
With it, we can create rules, specify which accounts or organizational units (OUs) to deploy them to and select the resources and regions where the WAF rules should apply.
Selecting the Global region for the security policy is used for setting WAF on resources like CloudFront while choosing a specific region allows you to associate WAF with resources such as API Gateway, ALB, and App Runner in that region.
Policy rules
The policy rules define specific security checks and actions for incoming web traffic. They filter, block, or allow requests based on conditions like IP addresses, geographic locations, request rate limits, or specific patterns in the request.
In AWS Firewall Manager, when creating a WAF security policy, you can define a Web ACL with three distinct phases for rule evaluation: PreProcess Rule Groups, and PostProcess Rule Groups. In addition, every team can add its own set of rules when the team associates a resource with the Web ACL and rule evaluation occurs after the first rule group (PreProcess) and before PostProcess rule group. Let's go over the Rule evaluation process in detail.
Rule Group Evaluation Phases
First Rule Group (PreProcess Rule Groups):
Purpose: Contains rules that are evaluated first, before any Teams-defined rules.
Example: These can include centrally defined rules that enforce organization-wide policies, such as blocking known malicious IPs or applying rate-based rules.
Managed by: The Firewall Manager policy owner (typically the organization’s security team).
Action: Rules here have priority over all other rules, including Teams-defined rules.
Teams Rules (Middle):
Purpose: These are rules created by individual teams in their accounts to address specific requirements not covered by the organization-wide policy. They don't alter other team's ACLs.
Example: A specific account might add a rule allowing traffic from a trusted partner IP from a certain country to use its particular application.
Managed by: Individual AWS accounts under the organizational policy.
Action: Evaluated after PreProcess Rule Groups and before PostProcess Rule Groups.
Last Rule Group (PostProcess Rule Groups):
Purpose: Contains rules that are evaluated last, after any teams-defined rules.
Example: These can include cleanup or catch-all rules, such as blocking all remaining traffic that doesn’t match allowed patterns or blocking all traffic from a certain country.
Managed by: The Firewall Manager policy owner.
Action: These rules take precedence only after teams-defined rules have been evaluated.
In the picture above, you can see the last rule for blocking traffic (“POSTFMManaged-BlockCountryRuleGroup”) from specific countries. This rule is defined by the organization. However, in this account, there was a need to allow specific customers from the blocked countries to access and use an app. To achieve this, the “CustomerExcludeCountryRulesGroup” rule was created in the account, allowing a set of IPs from those customers to use the app in the member account.
WAF Logging Recommendations
In the security policy, there is a section that allows you to define where you would like to save the WAF logging and how whether it is via a central S3 bucket or the Kinesis Data Firehose delivery stream:
Centralizing logging to one location can be beneficial for governance. However, disabling the centralized logging option may be better if you have different systems where you want to send logs, such as DataDog. Instead, individual teams can enable logging within their accounts. This approach provides greater flexibility when choosing log destinations.
Pros and Cons of Centralized WAF Management
Pros
Consistency: Ensures that security policies are applied uniformly across all accounts and services.
Efficiency: Reduces the administrative overhead of managing individual WAF ACLs.
Scalability: Makes it easier to maintain security as the organization grows.
Customization: Allows teams to add their own rules without interfering with global rules.
Transparency: Updates to the ACL are applied automatically, minimizing manual intervention.
Cons
Initial Setup Complexity: Centralizing WAF management and ensuring all teams comply may require significant initial effort.
AWS CDK Code
In the code below you can a CDK configuration that you can deploy on an admin account.
It will create "pre" and "post" rules in the WAF ACL.
Summary
AWS Firewall Manager simplifies the management of WAF rules and security policies across multiple accounts, addressing challenges like decentralized governance, inconsistent rule implementation, and potential security gaps. Centralized control ensures consistent security practices, faster deployment of policies, and improved compliance across the organization.
With features like rule evaluation phases, flexibility for teams-specific configurations, and centralized or customizable logging options, AWS Firewall Manager empowers organizations to maintain robust and efficient security standards while accommodating diverse application needs.