LLD003-001 - Continuous Compliance - rules, controls, remediation's

Purpose

The purpose of this document is to outline the low-level design architecture for Continuous Compliance, to set up an active monitoring of AWS Infrastructure on organization’s accounts, that reacts to non-compliant resources configurations

Changelog

Scope

This document defines configurations of two security services:

• AWS Config: specification of rules and conformance packs that will be implemented with custom deployment solution.

• AWS Security Hub: specification of benchmarks, controls and remediation's that will be implemented with custom deployment solution.

Definitions

• Control: set of rules that are a part of AWS Security Hub Benchmark. Might have its representation in AWS Config as a Config Rule.

• Finding: information about detected security issue or potential vulnerability in accounts infrastructure. Findings are generated by AWS Security Hub.

• Security Check: the evaluation of a control against a single AWS resource, and it results in a finding that shows the result of the check.

• Security Standard: predefined set of security best practices and compliance checks designed to help users enhance the security of their AWS environment. Security Standards in AWS Security Hub consists of a set of "controls".

Overview

AWS prepared predefined Security Standards which includes the list of controls in the standard. Each control includes the following information:

• The security category that the control belongs to

• The resource that the control applies to

• If applicable, the AWS Config rule that is used for the control

• Any parameters used by the control

• A description of the control and what it checks

• For standards that are associated with a regulatory framework, the applicable requirements in that framework

• Information on how to remediate a failed check. For example, you might need to change the configuration of a resource.

Security standards and controls

We will use CIS AWS Foundations Benchmark v1.4.0 and AWS Foundational Security Best Practices standards.

CIS AWS Foundations Benchmark v1.4.0 - serves as a set of security configuration best practices for AWS. These industry-accepted best practices provide you with clear, step-by-step implementation and assessment procedures. List of controls with all information, including remediating methods is available here: CIS AWS Foundations Benchmark

AWS Foundational Security Best Practices - a set of automated security checks that detect when AWS accounts and deployed resources do not align with security best practices. The standard is defined by AWS security experts. This curated set of controls helps improve your security posture in AWS, and covers AWS’s most popular and foundational services. This standard consists of aprox. 200 controls: AWS Foundational Security Best Practices (FSBP) standard

Controls to be disabled in case of Multi Region environment

• CIS AWS Foundations Benchmark 3.7 control - This control deals with using AWS KMS to encrypt CloudTrail trail logs. Logs will be centralized so control will be active only in the one account and region where centralized logging take place.

• CIS AWS Foundations Benchmark 1.4-1.10, 1.12, 1.14, 1.16, 1.17, and 3.5 checks - Have to be disabled on all but one Region to save costs. For example 1.4 root account key check should not be performed on all regions.

• CIS AWS Foundations Benchmark 1.7, 4.4-4.14 checks - should be disabled if GuardDuty will be used for anomaly detection.

• AWS Foundational Best Practices controls - in case of global services like IAM some controls should be used only in one Region, if not checks for the same resources will be executed multiple times what will generate additional costs and remediation's duplicates. In order to avoid these issues controls below should be disabled on all Regions except the region that records global resources:

  • [IAM.1] IAM policies should not allow full "*" administrative privileges

  • [IAM.2] IAM users should not have IAM policies attached

  • [IAM.3] IAM users' access keys should be rotated every 90 days or less

  • [IAM.4] IAM root user access key should not exist

  • [IAM.5] MFA should be enabled for all IAM users that have a console password

  • [IAM.6] Hardware MFA should be enabled for the root user

  • [IAM.7] Password policies for IAM users should have strong configurations

  • [IAM.8] Unused IAM user credentials should be removed

  • [IAM.21] IAM customer managed policies that you create should not allow wildcard actions for services

  • [KMS.1] IAM customer managed policies should not allow decryption and re-encryption actions on all KMS keys

  • [KMS.2] IAM principals should not have IAM inline policies that allow decryption and re-encryption actions on all KMS keys

Disabled controls

Some controls will be disabled on clients request or to avoid issues like finding duplication with AWS Config, due to wrong parameters' configuration.

Disabled list:

• [IAM.8] Unused IAM user credentials should be removed - disabled due to wrong parameter value. Instead, rule iam-user-unused-credentials-check will be deployed with parameter maxCredentialUsageAge set to 30 in AWS Config.

• [EC2.3] Attached Amazon EBS volumes should be encrypted at-rest - disabled on tst and dev environments on client's request.

• [EC2.23] Amazon EC2 Transit Gateways should not automatically accept VPC attachment requests

Not Supported Manual Checks

Security Hub focuses on automated security checks. As a result, Security Hub doesn't support the following requirements of CIS AWS Foundations Benchmark v1.4.0 because they require manual checks of your resources:

• 1.1 – Maintain current contact details

• 1.2 – Ensure security contact information is registered

• 1.3 – Ensure security questions are registered in the AWS account

• 1.11 – Do not set up access keys during initial user setup for all IAM users that have a console password

• 1.18 – Ensure IAM instance roles are used for AWS resource access from instances

• 1.21 – Ensure IAM users are managed centrally via identity federation or AWS Organizations for multi-account environments

• 2.1.4 – Ensure all data in Amazon S3 has been discovered, classified and secured when required

• 5.4 – Ensure routing tables for VPC peering are "least access"

Not Supported Automated Checks

Security Hub doesn't support the following requirements of CIS AWS Foundations Benchmark v1.4.0 that rely on automated checks:

• 1.13 – Ensure there is only one active access key available for any single IAM user

• 1.15 – Ensure IAM users receive permissions only through groups

• 1.19 – Ensure that all the expired SSL/TLS certificates stored in IAM are removed

• 1.20 – Ensure that IAM Access Analyzer is enabled for all Regions

• 2.1.3 – Ensure MFA Delete is enabled on S3 buckets

• 3.10 – Ensure that Object-level logging for write events is enabled for S3 bucket

• 3.11 – Ensure that Object-level logging for read events is enabled for S3 bucket

• 4.1 – Ensure a log metric filter and alarm exist for unauthorized API calls

• 4.2 – Ensure a log metric filter and alarm exist for Management Console sign-in without MFA

• 4.3 – Ensure a log metric filter and alarm exist for usage of root account (this is similar to automated requirement 1.7 – Eliminate use of the 'root user for administrative and daily tasks, which is supported in Security Hub)

• 4.15 – Ensure a log metric filter and alarm exists for AWS Organizations changes

• 5.2 – Ensure no security groups allow ingress from 0.0.0.0/0 to remote server administration ports

Deployment

Deployment of Security Hub will be executed using custom AWS Security Hub Solution. Solution consists of few steps that needs to be done in order to implement AWS Security Hub, its resources and remediations:

1. write a configuration template for the organization that specifies:

   • which controls and standards are enabled/disabled (per-account)

   • which remediations are active for which controls

   • and, optionally, rules for automatic suppression of findings based on tags/finding details/resource ids

2. run the Terragrunt solution on global repository

Solution will be deployed on all accounts except “Sandbox” accounts. Aggregator is not planned due to lack of permissions for delegated administrator of AWS Security Hub service.

Solution consists of a few terraform modules. The main module takes care of activation of standards and suppressing controls. The rest of the modules are responsible for remediation's. Each module is one remediation type. Solution supports adding new remediations as modules in the future.

Overview

AWS Config is a service that allows for the evaluation and audit of AWS resources. It continuously monitors the configurations of resources and evaluates their compliance with policies using selected rules.

AWS Config solution will be responsible for deployment of 6 conformance packs:

1. OperationalBestPracticesForSecurityServices

2. OperationalBestPracticesForEncryptionAndKeys

3. OperationalBestPracticesForStorageServices

4. AdditionalSecurityComplianceChecks

5. ISO27001ConformancePack

6. TagEnforcingConformancePack

Descriptions of rules can be found here: Rules List

Conformance Packs and Rules

Rules in these conformance packs are supplementary to controls in AWS Security Hub Benchmarks.

Each Conformance Pack consists of a set of rules. Some rules require defining parameters.

Additional AWS Config Custom Rules

As requested, additional custom rule will be created:

• CheckSNSEmailSubscriber - This rule checks if the domain of email subscribers for an SNS Topic matches the parameter provided in the form of a regular expression. For example, using the regex pattern ^.*?tameshi\.pl$ will validate if the subscribers' email addresses originate from the tameshi.pl domain.

Rule will be included in AdditionalSecurityComplianceChecks conformance pack.

Deployment

Due to AWS Config requirements to use Cloudformation templates for Conformance Packs definitions, the whole solution is written in CloudFormation with terraform and terragrunt used as a wrapper. Solution uses universal template that will be applied on all accounts except “Sandbox” accounts.

Solution will be deployed with Terragrunt on global repository.

Changing and applying modified templates will result in conformance packs redeployment.

SES Email Notification Remediation

We will use automatic remediations in form of SES email notification for Security Hub controls:

• CIS AWS Foundations Benchmark v1.4.0:

  • [IAM.3] Ensure access keys are rotated every 90 days or less

  • [EC2.6] Ensure VPC flow logging is enabled in all VPCs

• AWS Foundational Security Best Practices:

  • [DynamoDB.3] dax-encryption-enabled

  • [ELB.1] alb-http-to-https-redirection-check

  • [EFS.1] efs-encrypted-check

  • [ES.1] elasticsearch-encrypted-at-rest

  • [EC2.3] encrypted-volumes

  • [Opensearch.1] opensearch-encrypted-at-rest

  • [Opensearch.3] opensearch-node-to-node-encryption-check

  • [RDS.3] rds-storage-encrypted

  • [RDS.4] rds-snapshots-encrypted

  • [Redshift.2] redshift-require-tls-ssl

  • [Redshift.10] redshift-cluster-kms-enabled

  • [S3.4] s3-bucket-server-side-encryption-enabled

  • [SNS.1] sns-encrypted-kms

  • [SSM.4] ssm-document-not-public

We will use automatic remediations in form of SES email notification for findings originating from AWS Config rules:

• TagEnforcingConformancePack - all rules within conformance pack

• OperationalBestPracticesForEncryptionAndKeys - all rules within conformance pack

List of rules in conformance packs available here: Conformance Packs Description

Unused Credentials Remediation

We will deploy rule iam-user-unused-credentials-check twice - one with parameter checking if credentials were unused for past 30 days, and second rule with parameter checking if credentials were unused for past 60 days. First rule is prepared for future notifications, while second rule will trigger Lambda Function, through EventBridge rule, responsible for deactivating credentials unused for more than 60 days

Findings to OpenSearch Remediation

Every time there is a new finding in Security Hub, EventBridge notices it and passes findings data to Amazon Kinesis Data Firehose. Kinesis then gathers new findings for specified amount of time (5 minutes), compresses data and sends them to centralised S3 bucket for Opensearch ingestion. Using Kinesis instead of simple Lambda Function for this remediation has its advantages. The first one is data aggregation. Most new findings will show up during deployment of application/infrastructure, since most rules evaluates new resources and changes in already existing ones. It means that most findings show up in first few minutes after deployment. Lambda Function would have to separately upload each new finding to S3 Bucket, while Kinesis gathers them for few minutes, then compresses them together and puts a whole batch as a single object in a bucket. This results in lower amount of data and fewer operations to monitor. Kinesis also automatically scales, while with Lambda there would be possibility of hitting concurrency limit during big deployments and would require additional monitoring and fine tuning.

Security Hub

A security check is the evaluation of a control against a single AWS resource, and it results in a finding that shows the result of the check. You are charged per number of checks per account per region. You are only charged once for a check when controls that are shared across different standards are evaluated against the same resource.

AWS Security Hub ingests findings from various AWS services and partner products. Finding ingestions include both new findings and updates to existing findings. You are not charged for finding ingestion's associated with Security Hub' s security checks. You are charged based on the number of other findings sent to Security Hub per account per region each month. Security Hub offers a perpetual free tier of 10,000 findings per account per Region per month.

AWS Config

You pay $0.003 per configuration item recorded in your AWS account per AWS Region. A configuration item is recorded whenever a resource undergoes a configuration change or a relationship change. The resource could be an AWS, third-party, or custom resource. Additionally, you pay for every executed evaluation of configuration item.

A conformance pack evaluation is defined as an evaluation of a resource by an AWS Config rule within the conformance pack. Every rule deployed in AWS Config, that is not managed by Security Hub, will be a part of Conformance Pack.

Additional costs might be added for AWS Lambda Functions. Custom AWS Config rules use Lambda Functions for resources evaluation.