Application team example: Creating an AWS Config rule - AWS Prescriptive Guidance

Application team example: Creating an AWS Config rule

The following are some controls from the Security Hub Foundational Security Best Practices (FSBP) security standard that the application or development team might be responsible for:

For this example, the application team is addressing a finding for FSBP control EC2.19. This control checks whether unrestricted incoming traffic for the security groups is accessible to the specified ports that have the highest risk. This control fails if any of the rules in a security group allow ingress traffic from 0.0.0.0/0 or ::/0 for those ports. The documentation for this control recommends deleting the rules that allow this traffic.

In addition to addressing the individual security group rule, this is a great example of a finding that should result in a new AWS Config rule. By using the proactive evaluation mode, you can help prevent the deployment of risky security group rules in the future. Proactive mode evaluates resources before they have been deployed so that you can prevent misconfigured resources and their associated security findings. When implementing a new service or a new functionality, application teams can run rules in proactive mode as part of their continuous integration and continuous delivery (CI/CD) pipeline to identify noncompliant resources. The following image shows how you can use a proactive AWS Config rule to confirm that the infrastructure defined in an AWS CloudFormation template is compliant.

A proactive AWS Config rule checking an AWS CloudFormation template for compliance

Another important efficiency can be gained in this example. When an application team creates a proactive AWS Config rule, they can share it in a common code repository so that other application teams can use it.

Each finding associated with a Security Hub control contains details about the finding and a link to the instructions for remediating the issue. Although cloud teams might encounter findings that require manual, one-time remediation, when appropriate, we recommend building proactive checks that identify issues as early as possible in the development process.