Rule configuration and management – Security Compliance with AWS Config, AWS Security Hub, and Automated Remediation

Rule configuration and management

Once a rule is selected, several settings can be adjusted to define the way it will be evaluated:

• Rule parameters: Most AWS-managed and custom rules can be configured with specific parameters that define their behaviors and the conditions under which they evaluate resources. For example, the AWS-managed rule checking for ACM certificate expiration can be set with a specific number of days after which a certificate will be considered expired.
• Rule triggers: All rules can be configured as either proactive, change-triggered, or periodic. Proactive rules are deployed when a new resource is about to be deployed. Change-triggered rules are evaluated when a configuration change affecting an existing resource is detected. Periodic rules run on a defined schedule such as every hour to check compliance.
• Rule scope: Similar to the recording scope of the initial setup but operating at a distinct level, the rule scope determines the specific resources each rule assesses for compliance. It can target certain resource types or resources with specific tags. This targeted approach ensures compliance checks are both relevant and efficient, focusing on appropriate resources for each rule.
• Remediation: Config can take various remediation actions when a resource is found to be non-compliant with a rule. This can include fully automated remediation or manual remediation that still requires human intervention.

Crafting rules using Guard

AWS CloudFormation Guard (cfn-guard) allows the creation of custom rules using a Domain-Specific Language (DSL), enabling you to define compliance policies in a more intuitive and readable format. Unlike traditional methods requiring complex scripting or Lambda functions, Guard simplifies the process by allowing Policy-as-Code (PaC) definitions that can be embedded directly within the rule without the need to use a separate Lambda function. This approach streamlines the creation of custom rules, making them easier to manage and understand.

To ensure the reliability and safety of these rules, it is critical to test them in a non-production environment before deployment. This precautionary step verifies their functionality and confirms they will not disrupt normal operations when implemented in a live setting.

Consider a scenario where you want to ensure that all your EC2 instances are not only using specific instance types but also have encrypted EBS volumes and specific security group settings. A Guard policy for this could be as follows:
rule secure_ec2_compliance {
    let applicable_instances = %configuration where resourceType == ‘AWS::EC2::Instance’
    applicable_instances {
        configuration.instanceType in [‘t2.micro’, ‘t2.small’]
        configuration.blockDeviceMappings[*].ebs.encrypted == true
        configuration.securityGroups[*].any { sg => sg.groupName == ‘secure-communication’ }
    }
}

In this example, the policy checks for the following:

1. EC2 instances being of type t2.micro or t2.small for cost optimization.
2. All EBS volumes attached to these instances are encrypted, ensuring data security.
3. Instances are associated with a security group named secure-communication, indicating a specific configuration for secure data transmission.