Requirements - Guidelines for Implementing AWS WAF
ProtectionsGovernanceLogging

Requirements

As a first step towards implementing AWS WAF, AWS recommends that you gather and define the requirements which will make this implementation successful for your business. This section will cover some common WAF requirements.

Protections

After you have identified which threats are applicable for your application, define your baseline criteria for success. These criteria can include passing penetration tests performed by third-party or internal security teams, meeting specific compliance requirements, or simply having coverage for common web vulnerabilities (for example, OWASP Top 10). The sensitivity of the content that your application serves may dictate whether you choose to implement a positive security compared to negative security model (allow compared to deny APIs) when creating your WAF web ACL. If your application does not use a SQL database, you can save WAF capacity units by not adding SQL injection detection rules. AWS recommends that you add WAF rules that are specific to your application’s requirements, because adding unnecessary rules can lead to an increase in false positives. False positives are legitimate requests that are considered by WAF as attacks and may be blocked as a consequence.

For existing applications, you may already have visibility into application usage patterns and be looking to block malicious requests identified from previous incidents and observations. Therefore, you may be looking for protections against a specific attack. If you are already using a WAF implementation, you may have a baseline of the average number of requests blocked by the existing WAF rules. In some cases, you may have visibility into the existing rules implemented and you can implement similar rules in AWS WAF.

Comparing AWS managed rules and Custom rules

Depending on your organization’s resources and security culture, you must decide how to implement AWS WAF. You can deploy out-of-the-box AWS Managed Rules sets, create your own custom rules, or use a combination of both. For most applications, AWS recommends starting with the baseline rule groups and the Amazon IP reputation list from the AWS Managed Rules, then selecting application specific rule groups that match the application’s profile.

For some workloads, advanced protection may be required. In such cases, you might add additional custom rules in addition to existing protection. Managing and implementing your own rules requires that your security and application teams develop skills in creating and managing WAF rules. To help with these workloads, AWS Professional Services or AWS WAF Partners can help you create these rules, perform periodic reviews, and train your teams to develop this expertise.

Governance

You might also have governance requirements to define how to manage and monitor WAF implementations across your organization. In some organizations, WAF configurations are managed centrally by a security team. In this case, the security team must audit and ensure that WAF is configured correctly across resources managed by application teams. In other organizations, WAF configuration and deployment is managed by the application teams so that the WAF rules deployed can be specific to the protected application.

To simplify centralized management of AWS WAF, AWS Firewall Manager allows you to define security policies that automatically deploy WAF across accounts within your AWS Organization. AWS Firewall Manager provides you with visibility to ensure that resources have the appropriate WAF web ACL associated and are within compliance of the WAF policies. To illustrate the possibilities, review the following governance examples:

Example 1: AWS Firewall Manager implementation

In this example, you have autonomous application teams that own WAF configurations with the supervision of a central security team.

  1. The central security team provides and documents generic guidance in the form of best practices for the application teams.

  2. The central security team uses Firewall Manager with a WAF policy to deploy a central web ACL (based on AWS managed baseline rule groups) to each team’s account without automatic remediation. This policy is configured to deploy a copy of the web ACL but not automatically associate it to application resources (for example, CloudFront, Application Load Balancer, Amazon API Gateway). Although this approach does not force the protection on the application teams, it provides the central security team with visibility of which applications have WAF attached to their endpoints.

  3. Application teams can choose to apply the central web ACL as it is, or modify it before application. Their choice is mostly driven by their security requirements and governance.

Diagram showing an example of an AWS Firewall Manager implementation

Example of an AWS Firewall Manager implementation

Example 2: AWS Firewall Manager implementation with two WAF policies

In this example, you have a central security team that manages WAF deployments and rules for applications across your organization.

  1. The central security team creates two Firewall Manager WAF policies with automatic remediation.

    1. One policy uses managed rules for WordPress (as an example of a sample application) for all resources tagged as a WordPress application.

    2. One policy uses Amazon IP reputation list and rate limiting rules for all other HTTP(S) applications.

  2. Application teams tag resources associated with WordPress applications accordingly.

  3. In each AWS account within the organization, Firewall Manager creates two web ACLs, one for each policy. Firewall Manager automatically associates the web ACLs to the appropriate resources as configured by the policy. When this occurs, existing WAF web ACLs associated to those resources are overridden.

  4. The security team can monitor WAF compliance through the Firewall Manager in the AWS Management Console. Firewall Manager allows you to identify if resources have the correct WAF web ACL associated as configured by the Firewall Manager policy. You can also integrate AWS Security Hub with AWS Firewall Manager to detect resources that are not properly protected by WAF rules.

Example 3: AWS Firewall Manager implementation with one centralized WAF policy

In this example, you have a central security team that manages baseline WAF deployments and application teams have the flexibility to create new WAF rules specific to their applications.

  1. The central security team creates one baseline AWS Firewall Manager WAF policy with automatic remediation.

  2. Central policy uses a baseline rule for example, a managed IP reputation rule to deny access to IP addresses with a bad reputation score.

  3. Application teams can then configure application specific policies for WordPress (as an example of a sample application) for all resources tagged as a WordPress application.

  4. In each account within the organization, Firewall Manager creates one web ACL. Firewall Manager automatically associates the web ACLs to the appropriate resources as configured by the policy. When this occurs, existing WAF web ACLs associated to those resources are overridden.

  5. The security team can monitor WAF compliance through the Firewall Manager in the AWS Management Console. Firewall Manager allows you to identify if resources have the correct WAF web ACL associated as configured by the Firewall Manager policy. You can also integrate AWS Security Hub with AWS Firewall Manager to detect resources that are not properly protected by WAF rules.

Logging

WAF logging is a common requirement for security teams to meet their compliance and auditing needs. AWS WAF provides near-real-time logs through Amazon CloudWatch Logs log group, an Amazon Simple Storage Service (Amazon S3) bucket, or an Amazon Data Firehose.

For each inspected request by AWS WAF, a corresponding log entry is written that contains request information such as timestamp, header details, and the action for the rule that matched. AWS WAF does not currently log the request body.

In the logging configuration for your web ACL, you can customize what AWS WAF sends to the logs as follows:

  • Log filtering – You can add filtering to specify which web requests are kept in the logs and which are dropped. You can filter on the rule action and on the web request labels that were applied during the request evaluation. For information about rule action settings, refer to AWS WAF rule action. For information about labels, refer to AWS WAF labels on web requests.

  • Field redaction – You can redact some fields from the log records. Redacted fields appear as XXX in the logs. For example, if you redact the URI field, the URI field in the logs will be XXX. For a list of the log fields, refer to Log Fields.

The Log filtering feature allows you to reduce processing of unwanted logs and only store the logs that you want to analyze. This helps save costs on log delivery and storage. With the field redaction feature, you can remove sensitive fields such as PII data or the session ID from the log files.

You can use logs for debugging and additional forensics by integrating with your Security Information and Event Management (SIEM) or other log analysis tools. By default, logging is not enabled when you create a web ACL. To automate log enabling, you can use AWS Config to configure logging whenever a new WAF web ACL is created.

Diagram showing the automation of logging activation

Automation of logging activation