Cloud Security Services: AWS Config Implementation

The goal of this document is to outline the process of enabling and implementing the AWS Config service and assigning ownership to the Security Engineering team. By doing so, the Security Engineering team will be responsible for managing and improving the AWS Config service in all AWS accounts within Ebury. This will allow us to effectively track resource misconfigurations and ensure compliance with our security policies.

  • AWS Config: helps to assess, audit, and evaluate the configuration changes made to AWS resources. It is an essential component to enhance our security posture in the cloud. It helps in maintaining compliance and security by providing a detailed inventory of resources while keeping track of changes over time.

How AWS Config is currently deployed on Ebury:

  • Manually provisioned. AWS Config has been enabled manually in some of our AWS Accounts. This is not scalable because it's time-consuming, prone to human errors, lacks visibility, and monitoring.
  • Partially enabled. AWS Config is only active in a few accounts, this results in inconsistent configurations and compliance violations, making it difficult to manage and secure our infrastructure.
  • Legacy configuration and Config rules. We have a legacy, manual, deployment of Config in some accounts, which leads to inaccurate compliance reporting, security vulnerabilities, and challenges in managing our infrastructure.

Scope

The scope of this document covers all AWS accounts owned by our organisation.

Reference Documents

Reference Document Location
GCP Assessment Jira Epic SECENG-368
AWS Assessment Jira Epic SECENG-195
Cloud Action Plan slide deck SecEng Action Plan

Problem Description

AWS Config has been manually implemented and partially configured in some AWS Accounts, as detailed in the table below. This leaves multiple accounts vulnerable to security threats caused by misconfigurations and non-compliance issues.
Account ID Status
159260103493 (ebury-prod) Manually Enabled
523154097190 (ebury-dev) Manually Enabled
944075062774 (Service Desk) Manually Enabled
195854999501(SecEng) Manually Enabled
907607523182 Manually Enabled
373850043215 (Reporting) Disabled
201507213925 Disabled
225945698003 (EMP Dev) Disabled

This manual implementation and management is not a scalable solution, it is time-consuming to manage, prone to human error and lacks consistency with regards deploying Config Rules.

Leaving this service partially enabled will expose us to the following risks:

  1. Lack of visibility into resource configuration changes: Without AWS Config, it is difficult to track changes made to AWS resources, which can lead to unauthorised changes or configuration drifts.
  2. Compliance issues: Ebury requires a detailed inventory of resources and must track changes over time. Without AWS Config, it is difficult to achieve compliance which could lead to potential audit failures.
  3. Security threats: AWS Config provides continuous monitoring of AWS resources for security threats such as unauthorised access, misconfigured resources, or policy violations. Without AWS Config, it is difficult to identify and mitigate security threats on time.

Background

Our organisation has been using AWS for several years now, and owns multiple AWS accounts used by various teams and departments. Over time, the number of AWS resources has grown, and it has become increasingly challenging to maintain a comprehensive inventory of resources and track changes over time. This has led to potential compliance and security issues, as it is difficult to identify unauthorised changes or security threats.

Solution

AWS Config has no dependencies on other services, which makes it a great starting point to develop it to monitor our AWS resources. Its self-contained nature means that it can be used to review changes in configurations and relationships between AWS resources, without affecting existing production services.

Organisational model

To facilitate this we must define an organisation-wide Config model where all AWS Config services across all Ebury’s AWS accounts are centralised in one master account.

We are going to create an aggregator to collect configuration and compliance data from the organisation in AWS Organizations and all the accounts in that organisation that have AWS Config enabled.

To implement the previous solution, Security engineering will open a request to SRE/DP teams to resolve the following actions:

  • Activate and verify AWS Config at the AWS Organization level.
  • Delegate the Config Master Account for operation and aggregation: the Security Account (779359621929) is the currently delegated master account for AWS Config.

Once the previous tasks are resolved, the Security account is the delegated master account for AWS Config. Security Engineering will take ownership to implement the following changes:

  • Create a data aggregator on the delegated account: Creating an aggregator on the Security account allows us to take an approach of centralising our rules so that they’re deployed automatically to all other accounts in the Organisation. These changes will be deployed using Terraform modules versioned on the appropriate GitHub repositories, maintained by the Security Engineering team.

After the data is collected from the accounts, we can aggregate the findings into the Security Account account where the aggregator is created.

Aggregator View

Rule Implementation

Conformance Packs (Set of rules) will be created to cover our entire AWS environment scope through the Security account (Delegated Master Account). This will ensure consistency across all of our accounts. Security Engineering is responsible for the development and maintenance of these rules.

AWS Config rules and Conformance Packs are deployed to monitor and track AWS changes, and the remediation actions triggered are oriented to generate alerts and notifications to the Security Engineering team, which means there are no possible disruptions or cause outages to production systems

Monitoring and alerts

Using AWS Config rules we can trigger notifications by invoking other AWS services such as AWS Lambda, AWS SNS, or AWS Systems Manager to notify the stakeholders about risky changes on the AWS resources. Security engineering is going to centralise all the notification developments with these services in the AWS Security account.

For example, AWS Config can be set up to send alerts to an SNS topic whenever a configuration change occurs. This allows for more advanced processing of the notifications, such as analyzing the changes for security purposes or trigger alerts.

Data aggregation is centralised in the Security account but AWS Config needs a service-linked role in each account where it is deployed. This service-role policy need the following permissions:

  • Write permissions on the Security s3 bucket, to collect logs.
  • Permissions to publish into an SNS topic for monitoring systems.
  • Use the AWS managed policy AWS_ConfigRole, to record the AWS resource configurations.

The service-linked role policy changes are requested by the Security engineering team through a ticket or by developing a Terraform template on the Terraform-Global repository, which must then be reviewed and approved by the existing code owners of the corresponding Terraform repository.

Remediation process

When a rule is triggered due to a detected risk, the first step is to identify the root cause. This assessment is done by the Security Engineering team. This may involve reviewing the configuration settings of the affected resource or analyzing logs and other relevant data to define the severity of the specific findings.

The second step involves the notification, based on the identified cause of the risk. The Security Engineering team will raise the appropriate remediation action, which may involve updating configuration settings, modifying access controls, or applying a patch or update.

The last step involves the remediation action applied by the resource/service owner, the follow-up will be done through the open remediation ticket and will be checked by the Security team with the automatic re-evaluation of the AWS Config rule.

Overall, an effective remediation process is well-defined, repeatable, and aligned between Security and the Technology teams.

Development and deployment process

The AWS Config implementation will be deployed using Terraform modules versioned on the appropriate GitHub repositories, maintained by the Security Engineering team. The provisioning of the AWS accounts with these terraform modules will be done by Security Engineering using a PR-based process that aligns with Ebury’s existing infrastructure development practices. All PRs will be tested before production rollout in an appropriate development account prior to the production rollout (Security Engineering AWS account).

Alternatives

The alternative is that we continue as we are with partial and manually deployed security services, having AWS Config disabled on multiple accounts, as well as the lack of understanding and processes to manage the service. This will give us inconsistent results, lack of visibility and being prone to errors.

Caveats

While it is beneficial for the Security Engineering team to have ownership and permissions on AWS Config, some caveats should be considered:

  1. Stakeholders should understand that they may have limited visibility into AWS Config, as this tool is primarily used by the security engineering team. Security Engineering will report on the security KPIs to give visibility of the progress as well as the existing security risks.
  2. Stakeholders should understand AWS Config should be integrated with other security tools and services within the AWS environment, addressed in future blueprints.
  3. New policies will be created to evaluate the misconfigurations and controls of the AWS accounts.
  4. Cloud costs will be slightly increased as a result of the enablement or improvement of this tool.

Operation

The Security Engineering team will be the owner of the aforementioned security service, including the deployment of this service to monitor and improve the cloud environment security posture. In addition, the Security Engineering team will assist and request other teams to apply security policies and changes on the configurations through Pull Request on Terraform repositories or via tickets.

Security Impact

  • Improved security: We will be able to effectively observe, configure and maintain the security service to ensure that our cloud configuration is secure.
  • Increased customisation: We will be able to customise the service to meet the specific security requirements of our organisation.
  • Better alignment with security policies: We will be able to ensure that the security service is aligned with our organisation's security policies.
  • Greater agility: We will be able to quickly deploy and configure this service to detect new security threats and vulnerabilities.

Performance Impact

This service improvement does not impact the performance of other Cloud services or procedures.

Developer Impact

This service improvement does not impact the development of other Cloud services or procedures.

Deployment

The Security Engineering team will follow an overtime multi-phased approach, enabling the service on the pending accounts, customising and creating new detection rules and creating procedures to notify and monitor resource changes, non-compliant resources and misconfigured resources.

Dependencies

IAM permissions to take ownership of AWS Config should be granted to Security Engineering team-specific members for this service. These permissions should be granted for all the Ebury accounts. Existing processes for granting permissions to cloud resources will be followed upon approval of this RFC.

The Security Engineering team will deploy, maintain and develop the service in all the accounts, and thus will require access permissions on AWS Config on all the accounts.

It should be noted not all members of the Security Engineering team will require such a level of access.

SRE/PC teams will take the actions needed to delegate the AWS Config master account at the Organisation level to the Security Account (779359621929). These tasks are detailed in the “Organisational model” section.

References