Aligning the Landing Zone Accelerator on AWS with UK National Cyber Security Centre guidance

Landing Zone Accelerator on AWS (LZA) is a solution to automate the deployment of a secure cloud foundation on Amazon Web Services (AWS). With this solution, customers with highly-regulated workloads and complex compliance requirements can better manage and govern their multi-account environment. The solution can be used by customers at different stages of cloud adoption. For example, supporting customers at the beginning of their journey or those that are far along their journey, going all-in on cloud, at enterprise scale. The solution has been designed to be flexible, allowing customers to adapt their landing zone based on their organisational requirements based on their maturity.

This blog post provides technical guidance for UK organisations to implement their landing zone in-line with guidance from the UK National Cyber Security Centre (NCSC) using the LZA.

However, to unlock the full value of cloud, organisations must think holistically about the changes they need to make to be successful. In this first section, we highlight areas that organisations can consider prior to scaling their adoption of the cloud. For customers that are moving beyond their initial experimentation with the cloud, we highly recommend reading the AWS Cloud Adoption Framework (AWS CAF). This will help organisations think about the organisational change and operating model needed to be successful in the cloud.

Best practices for scaling cloud adoption with the Landing Zone Accelerator on AWS

Build the right team

To make sure the solution can be built and operated, the first thing organisations need is a team with the right mix of skills. If you don’t have these capabilities in-house, you can get support either through AWS Professional Services, such as with the regulated landing zone offering, or with AWS Partners who have specific LZA offerings.

However, if you are planning on implementing the solution using your own organisation’s capabilities, we recommend the following skills:

Be clear about what you want to achieve

For organisations that are implementing a landing zone to support workloads beyond small experiments, you should document what outcomes you are trying to enable with the solution. Ideally this will be linked back to a broader business/cloud strategy which defines the business outcomes that should be achieved by adopting the cloud. This helps galvanise disparate teams to aid in consistent decision making, and deliver value truly aligned to an organisation’s mission. These outcomes should be mapped to metrics that help evidence success. For example:

Delivery

• Reduce time to onboard teams/developers to cloud
• Reduce time for workload assurance

Reliability

• Improve visibility into potential resilience weaknesses
• Reduce resilience weaknesses
• Improve availability service level agreements (SLAs)

Security

• Increase visibility into compliance status of cloud resources
• Reduce number of non-compliant resources
• Improve local administrator and central security team visibility of security events
• Reduce incident response resolution time

Operations

• Reduce resource requirements to deliver core platforms to organisation
• Decrease inter-team dependencies
• Increase ownership and responsibility

Identify the workloads that drive value

A landing zone without any workloads delivers no value to the business. This might sound obvious, but it’s surprising how often we see organisations create a foundation without understanding what they will be building in it. The landing zone exists to help your teams deliver workloads more securely, reliably, and efficiently, removing burden from delivery teams, whilst helping the organisation meet its governance and compliance objectives.

Once you have formed the team delivering your cloud foundation, you can use the following guidance to help implement the solution.

Implementing the Landing Zone Accelerator on AWS for UK public sector customers

 With the appropriate skillsets and objectives aligned, UK public sector organisations can use the following guidance to implement the LZA solution and use it to help align their workloads to NCSC guidance.

Review the solution documentation and baseline architecture

First, read through the LZA solution overview and LZA operations guidance.

Then, read through standard configuration architecture to understand the design and make sure it meets your own organizational requirements. The AWS LZA standard configuration helps UK customers better align with NCSC’s guidance on using a cloud securely by deploying AWS architecture, security and services selected with an eye to NCSC principles. Customers can start with this configuration and customise it to meet their specific organizational needs.

Follow the LZA guidance in the Deploy the solution section of the implementation guide.

Once the installation is complete, LZA creates breakglass users as per NCSC guidance. Organisations should consider enabling multi-factor authentication (MFA) to protect these highly privileged accounts. In the LZA management account, follow the AWS documentation enabling MFA for users, to add MFA to breakGlassUser01 and breakGlassUser02 and the root user in the management account.

As per the NCSC, alerting should also be configured to warn administrators when the accounts are used. To do this, update the security-config.yaml with the following guidance.

Under the “metrics” key add:

        # Monitor for the use of breakglass accounts
        - filterName: BreakglassAccountUsageMetricFilter
          logGroupName: aws-controltower/CloudTrailLogs
          filterPattern: "{ ($.userIdentity.userName = \"breakGlassUser0*\") && ($.userIdentity.invokedBy NOT EXISTS) && ($.eventType != \"AwsServiceEvent\") }"
          metricNamespace: LogMetrics
          metricName: BreakglassAccountUsage
          metricValue: "1"

Under the “alarms” key add:

        # Log metric filter and alarm for breakglass account usage
        - alarmName: BreakglassAccountUsage
          alarmDescription: Alarm for usage of "breakglass" accounts
          snsTopicName: Security
          metricName: BreakglassAccountUsage
          namespace: LogMetrics
          comparisonOperator: GreaterThanOrEqualToThreshold
          evaluationPeriods: 1
          period: 300
          statistic: Sum
          threshold: 1
          treatMissingData: notBreaching

Implement the standard configuration template

Once the solution has been deployed, we recommend you use git to clone the AWS CodeCommit repository locally so you can start to customise the solution’s configuration files. Follow the guidance here to connect to CodeCommit.

We recommend reading the sections using the configuration files and configuration file best practices in the implementation guide before editing the configuration.

Once you are familiar with the process, you can add the standard configuration to the repository you cloned and edit them as described below.

AWS Organizations Organizational Unit setup

To deploy workload accounts, we recommend you first define your first AWS Organizations organizational unit structure. You can review the section on organizing workload oriented Organizational Units (OUs) in the whitepaper, “Organizing you AWS environment using multiple account” for more details. Once you have defined your structure, follow the details under Adding an Organizational Unit (OU) in the performing administrator tasks section in the implementation guide. Once complete, define your new organizational units in the organization-config.yaml.

If you are unsure of exactly what organisation structure you require, we have provided a starting point to enforce some proposed good practices, like enforcing separation between development and production AWS accounts. You can also review additional NCSC guidance on the topic of organizational structure. You can add the following section to your organization-config.yaml. This will enforce separation between core environment services (such as security and logging) development and production workloads and shared environment services (such as active directory).

organizationalUnits:
  - name: Security
  - name: Infrastructure
  - name: Workloads
  - name: Workloads/Development
  - name: Workloads/Production
  - name: Sandbox

Account deployment

To deploy your accounts, you first need to update the accounts-config.yaml configuration to update the email address for the two shared accounts, “network” and “shared services.” For example:

workloadAccounts:
- name: SharedServices
  description: The SharedServices account
  email: lza-shared-svcs@example.com
  organizationalUnit: Infrastructure
- name: Network
  description: The Network account
  email: lza-network@example.com
  organizationalUnit: Infrastructure

Then, define the additional workload accounts to meet your organisation’s requirements. You can read further guidance from NCSC on workspaces for further context.

If you are not in a position to decide at this point, we have provided a starting point to enforce some sensible good practices. You can add the following section to your accounts-config.yaml. This will add three additional workload accounts to your AWS environment.

workloadAccounts:
- name: Sandbox-XXX
  description: Sandbox Development account for XXX
  email: lza-sandbox-XXX@example.com
  organizationalUnit: Sandbox
- name: Workload-Development-Project-XXX
  description: Development workload account for project XXX
  email: lza-developement-workload-XXX@example.com
  organizationalUnit: Workloads/Development
- name: Workload-Production-Project-XXX
  description: Production workload account for project XXX
  email: lza-production-workload-XXX@example.com
  organizationalUnit: Workloads/Production

Validate your compliance framework

LZA currently enables a number of compliance standards in the AWS Security Hub service. For many customers, this is not a requirement. For UK customers, we recommend reviewing the standards that are enabled and selecting the ones that are appropriate to meet your organisation’s compliance objectives. For customers that haven’t yet decided, we would recommend only enabling the AWS best practices compliance standard. This can be achieved by setting the other compliance standards to enable: false, in the security-config.yaml. For example:

      - name: PCI DSS v3.2.1
        # https://docs.thinkwithwp.com/securityhub/latest/userguide/securityhub-pci-controls.html
        enable: false
        controlsToDisable:
          - PCI.IAM.3
          - PCI.S3.3
          - PCI.EC2.3
          - PCI.Lambda.2
      - name: CIS AWS Foundations Benchmark v1.4.0
        # https://docs.thinkwithwp.com/securityhub/latest/userguide/securityhub-cis-controls.html
        enable: false
        controlsToDisable:
          - CIS.1.17
          - CIS.1.16
      - name: NIST Special Publication 800-53 Revision 5
        # https://docs.thinkwithwp.com/securityhub/latest/userguide/nist-standard.html
        enable: false
        controlstoDisable: []

Password policy

The LZA standard configuration implements a password policy for AWS Identity and Access Management users that differs from the NCSC guidance. To remediate this, we recommend altering the password policy in the security-config.yaml, to the following and using the password policy guidance from NCSC:

iamPasswordPolicy:
  allowUsersToChangePassword: true
  hardExpiry: false

Implement the changes

Once you have finished editing your files, commit them and push the changes back to AWS CodeCommit. You can then re-run the configuration pipeline to implement the architecture.

Basic operations for the LZA solution for UK public sector customers

LZA enables a shift in philosophy for many organisations, giving broader self-service access to the cloud, to empower teams to make use of technology to deliver business value at pace. This is because LZA introduces many guardrails (not blockers) that enable security and compliance to get the visibility they need to assess and mitigate security contraventions, offering more freedom to users. Carefully considering the operating model that will govern the use of LZA is key. We recommend you read the AWS whitepaper on building a cloud operating model to help plan this activity.

This section offers some simple considerations for operating LZA while you establish and mature your broader organisation’s cloud operating model.

Advice for customers procuring a managed service

Many customers outsource their landing zone operations to an AWS partner or AWS managed services. In these cases, customers can also consider the following items when agreeing the contract under-pinning the service management.

• SLA management for business as usual (BAU) tasks and ad-hoc changes that meet the business’s needs.
• Time and materials for ad-hoc support requests and changes that fall outside of the agreed statement of works.

Landing zone operations personas

While there isn’t a mandated team structure to support a landing zone, the following is a list of common personas that can have a significant part to play in the operational activities required to support the solution.

• Administrators – responsible for making configuration changes to the LZA based on the needs of the business. This persona will work closely with the other personas to codify their requirements into the LZA configuration and deploy the changes.
• Security – responsible for monitoring and responding to security events generated within the platform.
• Networks – responsible for network design, monitoring, and configuration changes.
• Finance – responsible for reporting on budget utilisation and spend/cross charging across the organisation.
• Project teams – consumers of the landing zone created and supported by the previous personas.

Common landing zone operational activities

This section is not an exhaustive list of all the activities that may be required to support your landing zone and deliver value across the organisation. However, this section gives an indication of the activities that can be factored in when thinking about your landing zone operations.

Maintenance and changes to LZA (Administrators)

Security

Finance

Project teams

Beyond operating within the parameters defined in the onboarding documentation and training, project teams should be looking for ways to improve working practices across the organisation. They should be highlighting points of friction and opportunities for innovation with the landing zone operating team. This enables a culture of continual improvement to be adopted, helping the organisation make use of cloud more effectively.

Conclusion

UK public sector bodies look to the NCSC for guidance on how to build securely in public cloud. This blog post has explained some of the fundamentals required to deploy and operate the LZA in a manner that meets NCSC guidance. By following this guidance, UK public sector organisations can rapidly implement a secure AWS foundation that aligns to the NCSC guidance on using a cloud securely, enabling them to unlock the value of cloud.

The Landing Zone Accelerator on AWS is an open-source solution developed by AWS to help regulated customers get started using the AWS Cloud. The solution comes at no additional cost; customers only pay for the cloud services they use as part of the solution. We recommend that customers start exploring the value of the AWS Cloud by following the guidance outlined in this blog post.