Adam Divall

Walkthrough Guides and Other Useful Information on AWS

AWS Landing Zone Accelerator - Part 6: Security

2025-03-07 22 min read Walkthroughs Adam Divall

Welcome back to our deep dive into the AWS Landing Zone Accelerator (LZA)!

In the previous five parts of this series, we’ve covered a lot of ground:

In this sixth installment, we’ll shift our focus to a critical aspect of any well-architected cloud environment: Security. We’ll explore how the LZA helps you establish a secure baseline for your AWS workloads, but we’ll also go beyond the LZA’s default security configuration. I’ll explain the rationale behind some of our decisions to use custom solutions instead of relying solely on the LZA’s native security features, giving you a deeper understanding of how to tailor your security posture to your specific needs. Get ready to dive into the world of security best practices and learn how to fortify your AWS environment!

While the LZA provides a solid foundation for security in your AWS environment, it does have some limitations. For example, the LZA’s implementation of Amazon GuardDuty is currently quite limited.

  • GuardDuty: The LZA enables GuardDuty, but only for S3 and EKS audit logs protection. It doesn’t enable protection for other crucial services like EC2, RDS, or Lambda, nor does it configure all the available threat intelligence feeds or enable advanced features like malware protection.

Additionally, at the time of writing this blog post, the LZA lacks native support for Amazon Inspector. This means you cannot configure Inspector scans or integrate them with other security tools like AWS Security Hub directly through the LZA.

Furthermore, the LZA’s configuration of AWS IAM Access Analyzer could be enhanced. Currently, it only sets up an analyzer with an Organization Zone of Trust. This analyzer helps you identify resources that are shared with external entities. However, it doesn’t configure an additional analyzer with an Account Zone of Trust for each member account. Account-level analyzers are useful for identifying resources shared with other accounts within the same organization, which can be important for detecting unintended access or privilege escalation.

However, the LZA offers powerful customization options to address these limitations. Specifically, the AWS Security Reference Architecture (SRA) provides a wealth of security best practices and pre-built solutions that can be easily integrated into your LZA environment. This allows you to extend the LZA’s security capabilities and tailor them to your specific needs.

For example, you can use the SRA to:

  • Enhance GuardDuty coverage: Enable GuardDuty for additional services and configure advanced features like malware protection.
  • Implement Inspector: Deploy and configure Inspector to perform vulnerability scans and integrate with Security Hub for centralized management.
  • Configure account-level Access Analyzers: Set up Access Analyzers with Account Zones of Trust to monitor resource sharing within your organization.

By leveraging the SRA and the LZA’s customization capabilities, you can overcome these limitations and build a comprehensive security posture for your AWS environment.

Security Reference Architecture (SRA)

The AWS Security Reference Architecture (SRA) is a valuable resource for improving the security of your AWS environment. It provides best practices and guidance aligned with AWS’s recommendations, helping you reduce the risk of security breaches and data loss.

The SRA offers various resources, including diagrams, practical tips, and code examples to simplify the implementation of security measures. These examples help address specific limitations within the LZA, such as:

  • Threat detection (using Amazon GuardDuty): Continuously monitor your AWS accounts for malicious activity, going beyond the LZA’s basic configuration.
  • Automated patch management (using AWS Systems Manager Patch Manager): Keep your EC2 instances and other resources updated with the latest security patches, addressing the LZA’s lack of comprehensive patch management capabilities.
  • Vulnerability scanning (using Amazon Inspector): Regularly scan your systems to identify and address security vulnerabilities, supplementing the LZA’s limited vulnerability scanning features.
  • Configuring alternative AWS account contacts: Ensure you can be reached in case of security incidents or other critical events, improving upon the LZA’s basic contact configuration.

These are just a few examples of how the SRA can enhance the LZA’s security features. The SRA provides a wide range of solutions and best practices that can be tailored to your specific needs, helping you build a robust and comprehensive security posture in your AWS environment.

Update the LZA configuration:

  • Open the customizations-config.yaml file in your local copy of the aws-accelerator-config repository.
  • Update the customizations section and make sure it looks something like this:
customizations:
  cloudFormationStacks:
    - name: SRACommonPrerequisitesManagementAccountParameters
      description: Deploy SRA Common Prerequisites Management Account Parameters
      deploymentTargets:
        accounts:
          - Management
      regions:
        - eu-west-1
      template: custom-config-templates/sra-common-prerequisites-management-account-parameters.yaml
      runOrder: 1
      terminationProtection: true
      parameters:
        - name: pGovernedRegions
          value: ct-regions
        - name: pSecurityAccountId
          value: "{{account Audit}}"
        - name: pLogArchiveAccountId
          value: "{{account LogArchive}}"
    - name: SRACommonPrerequisitesMainSSM
      description: Deploy SRA Common Prerequisites Main
      deploymentTargets:
        accounts:
          - Management
      regions:
        - eu-west-1
      template: custom-config-templates/sra-common-prerequisites-main-ssm.yaml
      runOrder: 2
      terminationProtection: true
      parameters:
        - name: pSRASolutionVersion
          value: "v1.3"
    - name: SRAGuardDuty
      description: Deploy GuardDuty organization
      deploymentTargets:
        accounts:
          - Management
      regions:
        - eu-west-1
      template: custom-config-templates/sra-guardduty-org-main-ssm.yaml
      runOrder: 3
      terminationProtection: true
      parameters:
        - name: pAutoEnableS3Logs
          value: 'true'
        - name: pAutoEnableKubernetesAuditLogs
          value: 'true'
        - name: pAutoEnableMalwareProtection
          value: 'true'
        - name: pEnableRdsLoginEvents
          value: 'true'
        - name: pEnableRuntimeMonitoring
          value: 'true'
        - name: pEnableEksAddonManagement
          value: 'true'
        - name: pEnableEcsFargateAgentManagement
          value: 'true'
        - name: pEnableEc2AgentManagement
          value: 'true'
        - name: pEnableLambdaNetworkLogs
          value: 'true'
    - name: SRAIamAccessAnalyzer
      description: Deploy Iam Access Analyzer organization
      deploymentTargets:
        accounts:
          - Management
      regions:
        - eu-west-1
      template: custom-config-templates/sra-iam-access-analyzer-main-ssm.yaml
      runOrder: 3
      terminationProtection: true
    - name: SRAInspector
      description: Deploy Inspector organization
      deploymentTargets:
        accounts:
          - Management
      regions:
        - eu-west-1
      template: custom-config-templates/sra-inspector-org-main-ssm.yaml
      runOrder: 3
      terminationProtection: true
      parameters:
        - name: pScanComponents
          value: "EC2, ECR, LAMBDA, LAMBDA_CODE"
        - name: pEcrRescanDuration
          value: "LIFETIME"
    - name: SRAPatchManagement
      description: Deploy Patch Management organization
      deploymentTargets:
        accounts:
          - Management
      regions:
        - eu-west-1
      template: custom-config-templates/sra-patch_mgmt-org-main-ssm.yaml
      runOrder: 3
      terminationProtection: true
      parameters:
        - name: pPatchMgmtMaintWindow1TZ
          value: "Europe/London"
        - name: pPatchMgmtMaintWindow2TZ
          value: "Europe/London"
        - name: pPatchMgmtMaintWindow3TZ
          value: "Europe/London"
    - name: SRAAlternativeContacts
      description: Deploy AWS Alternative Contacts
      deploymentTargets:
        accounts:
          - Management
      regions:
        - eu-west-1
      template: custom-config-templates/sra-account-alternate-contacts-main-ssm.yaml
      runOrder: 3
      terminationProtection: true
      parameters:
        - name: pBillingEmail
          value: '<E-Mail Address of Billing Contact>'
        - name: pBillingName
          value: '<Name of Billing Contact>'
        - name: pBillingPhone
          value: '<Telephone Number of Billing Contact>'
        - name: pBillingTitle
          value: '<Job Title of Billing Contact>'
        - name: pOperationsEmail
          value: '<E-Mail Address of Operations Contact>'
        - name: pOperationsName
          value: '<Name of Operations Contact>'
        - name: pOperationsPhone
          value: '<Telephone Number of Operations Contact>'
        - name: pOperationsTitle
          value: '<Job Title of Operations Contact>'
        - name: pSecurityEmail
          value: '<E-Mail Address of Security Contact>'
        - name: pSecurityName
          value: '<Name of Security Contact>'
        - name: pSecurityPhone
          value: '<Telephone Number of Security Contact>'
        - name: pSecurityTitle
          value: '<Job Title of Security Contact>'
    - name: SRAAwsConfigCT
      description: Deploy AWS Config Management Account
      deploymentTargets:
        accounts:
          - Management
      regions:
        - eu-west-1
      template: custom-config-templates/sra-config-management-account-main-ssm.yaml
      runOrder: 3
      terminationProtection: true

This configuration defines a set of CloudFormation stacks that will be deployed as customisations within the AWS Landing Zone Accelerator (LZA). These stacks leverage solutions from the AWS Security Reference Architecture (SRA) to enhance the security posture of the AWS environment.

The following provides a summary of the included stacks and their security purpose:

  • SRACommonPrerequisitesManagementAccountParameters: Deploys common parameters required by other SRA solutions. This includes specifying the AWS Regions to be governed and the account IDs for the Security and Log Archive accounts. This stack is a prerequisite for deploying other SRA solutions, as it sets up essential parameters used by those solutions.
  • SRACommonPrerequisitesMainSSM: Deploys the core components of the SRA framework, including IAM roles and policies necessary for other SRA solutions to function correctly. This stack is also a prerequisite, as it lays the foundation for the SRA and enables other security services to operate effectively. It’s important to note that many SRA solutions rely on Systems Manager parameters, which are implemented by this stack.
  • SRAGuardDuty: Deploys and configures Amazon GuardDuty for enhanced threat detection across a wider range of AWS services, including S3, Kubernetes, RDS, EKS, ECS, EC2, and Lambda. It also enables malware protection and runtime monitoring. This comprehensive configuration helps identify and respond to potential security threats across your AWS environment. It’s also a prerequisite for deploying Amazon Detective, which we’ll cover later, as Detective relies on GuardDuty findings for its analysis.  
  • SRAIamAccessAnalyzer: Deploys and configures AWS IAM Access Analyser to identify resources shared with external entities or other AWS accounts within the organisation. This helps manage access and prevent unintended privilege escalation.
  • SRAInspector: Deploys and configures Amazon Inspector for vulnerability scanning of various components like EC2, ECR, and Lambda. This helps identify and remediate security weaknesses in your applications and infrastructure.  
  • SRAPatchManagement: Deploys and configures AWS Systems Manager Patch Manager for automated patching. This ensures that your EC2 instances and other supported resources are up-to-date with the latest security fixes, reducing the risk of vulnerabilities.
  • SRAAlternativeContacts: Configures alternative contacts for AWS accounts to ensure that AWS can reach the appropriate personnel in case of security incidents or other events. This improves communication and response times in critical situations.
  • SRAAwsConfigCT: Deploys AWS Config in the management account to track resource configurations and changes, enabling compliance monitoring and security analysis. This helps maintain an accurate inventory of resources and detect any deviations from security standards. In my opinion, just like enabling CloudTrail in an AWS Account/Org, Config should be enabled in every account. This provides valuable insights not only into who made a change but also what they changed and how the configuration was modified. This comprehensive approach to tracking changes is essential for maintaining a secure and well-managed AWS environment. However, it’s important to note that AWS Control Tower itself doesn’t enable AWS Config in the management account by default. This seems to contradict other AWS best practices and the recommendations of AWS security experts, as I’ve observed in discussions with AWS service teams during Customer Advocacy/Feedback calls.

This approach strengthens the overall security posture and addresses some of the LZA’s limitations, demonstrating how the SRA can be used to customise and enhance security in AWS. By incorporating these SRA solutions, you can build a more robust and comprehensive security framework for your AWS environment.

Going into the specific details of each SRA solution is beyond the scope of this post. However, it’s important to remember that the parameters I’ve used in the customizations-config.yaml file can be adjusted to fit your specific requirements. You can tailor the configuration to enable or disable specific features, modify settings, and adjust the scope of the security services deployed. This flexibility allows you to align the SRA solutions with your organization’s security policies and risk tolerance.

Save your changes:

  • Include the necessary SRA Modules YAML files alongside your CloudFormation code to provision the infrastructure for the varying SRA Modules (e.g., custom-config-templates/sra-account-alternate-contacts-main-ssm.yaml).
  • Use these commands to save your changes and update the LZA configuration:
git add .
git commit -m "Adding the Security Reference Architecture"
git push

Managing Security Settings with the Landing Zone Accelerator

AWS Security Hub

AWS Security Hub is a service that gives you a central view of your security posture across your AWS accounts. It automatically checks for security issues, gathers alerts from different sources, and helps you monitor compliance with security standards. It can also automate responses to security alerts, like sending notifications or fixing issues.

Amazon Macie

Amazon Macie is a service that helps you find and protect sensitive data in your AWS accounts, like personal information or financial data. It scans your storage, checks your security settings, and helps you follow data privacy rules. This way, you can understand and reduce risks to your sensitive data.

Amazon Detective

Amazon Detective helps you analyze and investigate security issues in AWS. It automatically gathers data from different sources and uses it to create a visual map of your security setup. This helps you understand security alerts, see how different parts of your AWS environment are connected, and investigate potential threats.

AWS Audit Manager

AWS Audit Manager helps you keep track of your AWS usage to make sure you’re following security and compliance rules. It automatically collects the information you need for audits, which saves you time and effort. This makes it easier to show that you’re meeting standards, reduces the risk of problems, and makes audits less of a hassle.

Default EBS Volume Encryption

EBS Default Volume Encryption automatically encrypts any new storage volumes you create in AWS, protecting your data even if someone steals the physical disks. This helps keep your sensitive data secret, makes sure you’re following compliance rules, and improves your overall security.

S3 Block Public Access

S3 Block Public Access is a security feature that prevents anyone from publicly accessing your S3 buckets, even if they have a direct link. This helps prevent accidental data exposure, improves security, and helps you meet compliance requirements. It’s important because it protects against data breaches and leaks. You can block public access at the account level for all buckets or at the bucket level for more specific control.

IAM Password Policies

IAM password policies are your backup plan for strong passwords in AWS. They set rules for things like length, complexity, and reuse, making it harder for attackers to guess passwords. While we prefer using IAM Identity Center and Single Sign-On with providers like Microsoft Entra ID, these policies act as a safety net for situations where those methods aren’t used.

Update the LZA configuration:

  • Open the customizations-config.yaml file in your local copy of the aws-accelerator-config repository.
  • Update the centralSecurityServices section and make sure it looks something like this:
centralSecurityServices:
  delegatedAdminAccount: Audit
  ebsDefaultVolumeEncryption:
    enable: true
    excludeRegions: []
  s3PublicAccessBlock:
    enable: true
    excludeAccounts: []
  scpRevertChangesConfig:
    enable: true
  snsSubscriptions: []
  macie:
    enable: true
    excludeRegions: []
    policyFindingsPublishingFrequency: FIFTEEN_MINUTES
    publishSensitiveDataFindings: false
  auditManager:
    enable: true
    excludeRegions: []
    defaultReportsConfiguration:
      enable: true
      destinationType: S3
    lifecycleRules:
      - enabled: true
        abortIncompleteMultipartUpload: 7
        expiration: 365
        noncurrentVersionExpiration: 365
  detective:
     enable: true
     excludeRegions: []
  guardduty:
    enable: false
    excludeRegions: []
    s3Protection:
      enable: false
      excludeRegions: []
    eksProtection:
      enable: false
    exportConfiguration:
      enable: false
      overrideExisting: false
      destinationType: S3
      exportFrequency: FIFTEEN_MINUTES
  securityHub:
    enable: true
    regionAggregation: true
    excludeRegions: []
    standards:
      - name: AWS Foundational Security Best Practices v1.0.0
        enable: false
      - name: PCI DSS v3.2.1
        enable: false
      - name: PCI DSS v4.0.1
        enable: false
      - name: CIS AWS Foundations Benchmark v1.2.0
        enable: false
      - name: CIS AWS Foundations Benchmark v1.4.0
        enable: false
      - name: CIS AWS Foundations Benchmark v3.0.0
        enable: false
      - name: NIST Special Publication 800-53 Revision 5
        enable: false
accessAnalyzer:
  enable: false
iamPasswordPolicy:
  allowUsersToChangePassword: true
  hardExpiry: false
  requireUppercaseCharacters: true
  requireLowercaseCharacters: true
  requireSymbols: true
  requireNumbers: true
  minimumPasswordLength: 15
  passwordReusePrevention: 24
  maxPasswordAge: 180

This LZA configuration customises various security services, disabling some through the security-config.yaml file to avoid conflicts with the enhanced security measures implemented via the customizations-config.yaml file. This approach leverages the SRA to address certain LZA limitations, resulting in a more robust security posture.

Specifically, this configuration:

  • Enables encryption for EBS volumes, enhancing data protection.
  • Blocks public access to S3 buckets, improving security posture.
  • Sets up automated reversion of insecure SCP changes, maintaining a strong security baseline.
  • Enables Macie, Audit Manager, and Detective for security monitoring and analysis.
  • Disables GuardDuty and Access Analyser to avoid conflicts with SRA implementations that provide more comprehensive configurations for these services.
  • Enforces a strong password policy for IAM users.

Save your changes:

  • Use these commands to save your changes and update the LZA configuration:
git add .
git commit -m "Updating the LZA Security Config"
git push

CloudWatch Metrics and Alarms

CloudWatch Metrics and Alarms are key for monitoring your AWS environment. Metrics track the performance of your resources, while alarms notify you or take action when things go wrong. They’re useful for keeping an eye on security services, spotting suspicious activity, responding to incidents quickly, and making sure you’re following security rules.

Update the LZA configuration:

  • Open the security-config.yaml file in your local copy of the aws-accelerator-config repository.
  • Update the cloudWatch section and make sure it looks something like this:
cloudWatch:
  metricSets:
    - regions:
        - eu-west-1
      deploymentTargets:
      accounts:
        - Management
      metrics:
        # CIS 1.7 – Avoid the use of the "root" account
        - filterName: RootAccountUsage
          logGroupName: aws-controltower/CloudTrailLogs
          filterPattern: '{$.userIdentity.type="Root" && $.userIdentity.invokedBy NOT EXISTS && $.eventType !="AwsServiceEvent"}'
          metricNamespace: LogMetrics
          metricName: RootAccount
          metricValue: "1"
        # CIS 4.4 – Ensure a log metric filter and alarm exist for IAM policy changes
        - filterName: IAMPolicyChangesMetricFilter
          logGroupName: aws-controltower/CloudTrailLogs
          filterPattern: "{($.eventName=DeleteGroupPolicy) || ($.eventName=DeleteRolePolicy) || ($.eventName=DeleteUserPolicy) || ($.eventName=PutGroupPolicy) || ($.eventName=PutRolePolicy) || ($.eventName=PutUserPolicy) || ($.eventName=CreatePolicy) || ($.eventName=DeletePolicy) || ($.eventName=CreatePolicyVersion) || ($.eventName=DeletePolicyVersion) || ($.eventName=AttachRolePolicy) || ($.eventName=DetachRolePolicy) || ($.eventName=AttachUserPolicy) || ($.eventName=DetachUserPolicy) || ($.eventName=AttachGroupPolicy) || ($.eventName=DetachGroupPolicy)}"
          metricNamespace: LogMetrics
          metricName: IAMPolicyChanges
          metricValue: "1"
        # CIS 4.5 – Ensure a log metric filter and alarm exist for CloudTrail configuration changes
        - filterName: CloudTrailChangesMetricFilter
          logGroupName: aws-controltower/CloudTrailLogs
          filterPattern: "{($.eventName=CreateTrail) || ($.eventName=UpdateTrail) || ($.eventName=DeleteTrail) || ($.eventName=StartLogging) || ($.eventName=StopLogging)}"
          metricNamespace: LogMetrics
          metricName: CloudTrailChanges
          metricValue: "1"
        # CIS 4.6 – Ensure a log metric filter and alarm exist for AWS Management Console authentication failures
        - filterName: ConsoleAuthenticationFailureMetricFilter
          logGroupName: aws-controltower/CloudTrailLogs
          filterPattern: '{($.eventName=ConsoleLogin) && ($.errorMessage="Failed authentication")}'
          metricNamespace: LogMetrics
          metricName: ConsoleAuthenticationFailure
          metricValue: "1"
        # CIS 4.7 – Ensure a log metric filter and alarm exist for disabling or scheduled deletion of customer created CMKs
        - filterName: DisableOrDeleteCMKMetricFilter
          logGroupName: aws-controltower/CloudTrailLogs
          filterPattern: "{($.eventSource=kms.amazonaws.com) && (($.eventName=DisableKey) || ($.eventName=ScheduleKeyDeletion))}"
          metricNamespace: LogMetrics
          metricName: DisableOrDeleteCMK
          metricValue: "1"
        # CIS 4.8 – Ensure a log metric filter and alarm exist for S3 bucket policy changes
        - filterName: S3BucketPolicyChangesMetricFilter
          logGroupName: aws-controltower/CloudTrailLogs
          filterPattern: "{($.eventSource=s3.amazonaws.com) && (($.eventName=PutBucketAcl) || ($.eventName=PutBucketPolicy) || ($.eventName=PutBucketCors) || ($.eventName=PutBucketLifecycle) || ($.eventName=PutBucketReplication) || ($.eventName=DeleteBucketPolicy) || ($.eventName=DeleteBucketCors) || ($.eventName=DeleteBucketLifecycle) || ($.eventName=DeleteBucketReplication))}"
          metricNamespace: LogMetrics
          metricName: S3BucketPolicyChanges
          metricValue: "1"
        # CIS 4.9 – Ensure a log metric filter and alarm exist for AWS Config configuration changes
        - filterName: AWSConfigChangesMetricFilter
          logGroupName: aws-controltower/CloudTrailLogs
          filterPattern: "{($.eventSource=config.amazonaws.com) && (($.eventName=StopConfigurationRecorder) || ($.eventName=DeleteDeliveryChannel) || ($.eventName=PutDeliveryChannel) || ($.eventName=PutConfigurationRecorder))}"
          metricNamespace: LogMetrics
          metricName: AWSConfigChanges
          metricValue: "1"
        # CIS 4.10 – Ensure a log metric filter and alarm exist for security group changes
        - filterName: SecurityGroupChangesMetricFilter
          logGroupName: aws-controltower/CloudTrailLogs
          filterPattern: "{($.eventName=AuthorizeSecurityGroupIngress) || ($.eventName=AuthorizeSecurityGroupEgress) || ($.eventName=RevokeSecurityGroupIngress) || ($.eventName=RevokeSecurityGroupEgress) || ($.eventName=CreateSecurityGroup) || ($.eventName=DeleteSecurityGroup)}"
          metricNamespace: LogMetrics
          metricName: SecurityGroupChanges
          metricValue: "1"
        # CIS 4.11 – Ensure a log metric filter and alarm exist for changes to Network Access Control Lists (NACL)
        - filterName: NetworkACLChangesMetricFilter
          logGroupName: aws-controltower/CloudTrailLogs
          filterPattern: "{($.eventName=CreateNetworkAcl) || ($.eventName=CreateNetworkAclEntry) || ($.eventName=DeleteNetworkAcl) || ($.eventName=DeleteNetworkAclEntry) || ($.eventName=ReplaceNetworkAclEntry) || ($.eventName=ReplaceNetworkAclAssociation)}"
          metricNamespace: LogMetrics
          metricName: NetworkACLChanges
          metricValue: "1"
        # CIS 4.12 – Ensure a log metric filter and alarm exist for changes to network gateways
        - filterName: NetworkGatewayChangesMetricFilter
          logGroupName: aws-controltower/CloudTrailLogs
          filterPattern: "{($.eventName=CreateCustomerGateway) || ($.eventName=DeleteCustomerGateway) || ($.eventName=AttachInternetGateway) || ($.eventName=CreateInternetGateway) || ($.eventName=DeleteInternetGateway) || ($.eventName=DetachInternetGateway)}"
          metricNamespace: LogMetrics
          metricName: NetworkGatewayChanges
          metricValue: "1"
        # CIS 4.13 – Ensure a log metric filter and alarm exist for route table changes
        - filterName: RouteTableChangesMetricFilter
          logGroupName: aws-controltower/CloudTrailLogs
          filterPattern: "{($.eventName=CreateRoute) || ($.eventName=CreateRouteTable) || ($.eventName=ReplaceRoute) || ($.eventName=ReplaceRouteTableAssociation) || ($.eventName=DeleteRouteTable) || ($.eventName=DeleteRoute) || ($.eventName=DisassociateRouteTable)}"
          metricNamespace: LogMetrics
          metricName: RouteTableChanges
          metricValue: "1"
        # CIS 4.14 – Ensure a log metric filter and alarm exist for VPC changes
        - filterName: VPCChangesMetricFilter
          logGroupName: aws-controltower/CloudTrailLogs
          filterPattern: "{($.eventName=CreateVpc) || ($.eventName=DeleteVpc) || ($.eventName=ModifyVpcAttribute) || ($.eventName=AcceptVpcPeeringConnection) || ($.eventName=CreateVpcPeeringConnection) || ($.eventName=DeleteVpcPeeringConnection) || ($.eventName=RejectVpcPeeringConnection) || ($.eventName=AttachClassicLinkVpc) || ($.eventName=DetachClassicLinkVpc) || ($.eventName=DisableVpcClassicLink) || ($.eventName=EnableVpcClassicLink)}"
          metricNamespace: LogMetrics
          metricName: VPCChanges
          metricValue: "1"
        # Custom – Ensure a log metric filter and alarm exist for Breakglass User Access
        - filterName: BreakglassAccountUsageMetricFilter
          logGroupName: aws-controltower/CloudTrailLogs
          filterPattern: '{ ($.eventName="ConsoleLogin" || $.eventName="AssumeRole") && $.userIdentity.userName="BreakGlassAdminUser" }'
          metricNamespace: LogMetrics
          metricName: BreakglassAccountUsage
          metricValue: "1"
  alarmSets:
    - regions:
        - eu-west-1
      deploymentTargets:
        accounts:
          - Management
    alarms:
        # CIS 1.7 – Avoid the use of the "root" account
      - alarmName: CIS-1.7-RootAccountUsage
        alarmDescription: Alarm for usage of "root" account
        snsTopicName: Security
        metricName: RootAccount
        namespace: LogMetrics
        comparisonOperator: GreaterThanOrEqualToThreshold
        evaluationPeriods: 1
        period: 300
        statistic: Sum
        threshold: 1
        treatMissingData: notBreaching
        # CIS 4.4 – Ensure a log metric filter and alarm exist for IAM policy changes
      - alarmName: CIS-4.4-IAMPolicyChanges
        alarmDescription: Alarm for IAM policy changes
        snsTopicName: Security
        metricName: IAMPolicyChanges
        namespace: LogMetrics
        comparisonOperator: GreaterThanOrEqualToThreshold
        evaluationPeriods: 1
        period: 300
        statistic: Average
        threshold: 1
        treatMissingData: notBreaching
        # CIS 4.5 – Ensure a log metric filter and alarm exist for CloudTrail configuration changes
      - alarmName: CIS-4.5-CloudTrailChanges
        alarmDescription: Alarm for CloudTrail configuration changes
        snsTopicName: Security
        metricName: CloudTrailChanges
        namespace: LogMetrics
        comparisonOperator: GreaterThanOrEqualToThreshold
        evaluationPeriods: 1
        period: 300
        statistic: Sum
        threshold: 1
        treatMissingData: notBreaching
        # CIS 4.6 – Ensure a log metric filter and alarm exist for AWS Management Console authentication failures
      - alarmName: CIS-4.6-ConsoleAuthenticationFailure
        alarmDescription: Alarm exist for AWS Management Console authentication failures
        snsTopicName: Security
        metricName: ConsoleAuthenticationFailure
        namespace: LogMetrics
        comparisonOperator: GreaterThanOrEqualToThreshold
        evaluationPeriods: 1
        period: 300
        statistic: Sum
        threshold: 1
        treatMissingData: notBreaching
        # CIS 4.7 – Ensure a log metric filter and alarm exist for disabling or scheduled deletion of customer created CMKs
      - alarmName: CIS-4.7-DisableOrDeleteCMK
        alarmDescription: Alarm for disabling or scheduled deletion of customer created CMKs
        snsTopicName: Security
        metricName: DisableOrDeleteCMK
        namespace: LogMetrics
        comparisonOperator: GreaterThanOrEqualToThreshold
        evaluationPeriods: 1
        period: 300
        statistic: Sum
        threshold: 1
        treatMissingData: notBreaching
        # CIS 4.8 – Ensure a log metric filter and alarm exist for S3 bucket policy changes
      - alarmName: CIS-4.8-S3BucketPolicyChanges.
        alarmDescription: Alarm for S3 bucket policy changes
        snsTopicName: Security
        metricName: S3BucketPolicyChanges
        namespace: LogMetrics
        comparisonOperator: GreaterThanOrEqualToThreshold
        evaluationPeriods: 1
        period: 300
        statistic: Average
        threshold: 1
        treatMissingData: notBreaching
        # CIS 4.9 – Ensure a log metric filter and alarm exist for AWS Config configuration changes
      - alarmName: CIS-4.9-AWSConfigChanges
        alarmDescription: Alarm for AWS Config configuration changes
        snsTopicName: Security
        metricName: AWSConfigChanges
        namespace: LogMetrics
        comparisonOperator: GreaterThanOrEqualToThreshold
        evaluationPeriods: 1
        period: 300
        statistic: Sum
        threshold: 1
        treatMissingData: notBreaching
        # CIS 4.10 – Ensure a log metric filter and alarm exist for security group changes
      - alarmName: CIS-4.10-SecurityGroupChanges
        alarmDescription: Alarm for security group changes
        snsTopicName: Security
        metricName: SecurityGroupChanges
        namespace: LogMetrics
        comparisonOperator: GreaterThanOrEqualToThreshold
        evaluationPeriods: 1
        period: 300
        statistic: Sum
        threshold: 1
        treatMissingData: notBreaching
        # CIS 4.11 – Ensure a log metric filter and alarm exist for changes to Network Access Control Lists (NACL)
      - alarmName: CIS-4.11-NetworkACLChanges
        alarmDescription: Alarm for changes to Network Access Control Lists (NACL)
        snsTopicName: Security
        metricName: NetworkACLChanges
        namespace: LogMetrics
        comparisonOperator: GreaterThanOrEqualToThreshold
        evaluationPeriods: 1
        period: 300
        statistic: Sum
        threshold: 1
        treatMissingData: notBreaching
        # CIS 4.12 – Ensure a log metric filter and alarm exist for changes to network gateways
      - alarmName: CIS-4.12-NetworkGatewayChanges
        alarmDescription: Alarm for changes to network gateways
        snsTopicName: Security
        metricName: NetworkGatewayChanges
        namespace: LogMetrics
        comparisonOperator: GreaterThanOrEqualToThreshold
        evaluationPeriods: 1
        period: 300
        statistic: Sum
        threshold: 1
        treatMissingData: notBreaching
        # CIS 4.13 – Ensure a log metric filter and alarm exist for route table changes
      - alarmName: CIS-4.13-RouteTableChanges
        alarmDescription: Alarm for route table changes
        snsTopicName: Security
        metricName: RouteTableChanges
        namespace: LogMetrics
        comparisonOperator: GreaterThanOrEqualToThreshold
        evaluationPeriods: 1
        period: 300
        statistic: Average
        threshold: 1
        treatMissingData: notBreaching
        # CIS 4.14 – Ensure a log metric filter and alarm exist for VPC changes
      - alarmName: CIS-3.14-VPCChanges
        alarmDescription: Alarm for VPC changes
        snsTopicName: Security
        metricName: VPCChanges
        namespace: LogMetrics
        comparisonOperator: GreaterThanOrEqualToThreshold
        evaluationPeriods: 1
        period: 300
        statistic: Sum
        threshold: 1
        treatMissingData: notBreaching
        # Custom – Ensure a log metric filter and alarm exist for Breakglass User Access
      - alarmName: BreakGlass-Login-Alert
        alarmDescription: Triggers when a BreakGlass user logs in via ConsoleLogin or AssumeRole
        snsTopicName: Security
        metricName: BreakglassAccountUsage
        namespace: LogMetrics
        comparisonOperator: GreaterThanOrEqualToThreshold
        evaluationPeriods: 1
        period: 300
        statistic: Sum
        threshold: 1
        treatMissingData: notBreaching

This LZA configuration uses CloudWatch to monitor security events in the Management account, focusing on the eu-west-1 region. It sets up metrics to track potentially risky actions from CloudTrail logs, based on CIS security benchmarks, and triggers alarms when these actions occur. This provides real-time alerts for security teams and enhances the LZA’s security monitoring, enabling proactive incident response and compliance. It also includes a custom alarm for monitoring Breakglass account access.

Save your changes:

  • Use these commands to save your changes and update the LZA configuration:
git add .
git commit -m "Adding CloudWatch Metrics and Alarms"
git push

Prowler

Prowler is an open-source security tool that provides comprehensive security assessments of AWS environments. It evaluates cloud infrastructure against various security frameworks and best practices, helping identify potential vulnerabilities and misconfigurations.

Prowler offers the following benefits:

  • Comprehensive Checks: Prowler performs a wide range of security checks across various AWS services and configurations.
  • Customisable: It can be tailored to assess specific security frameworks, such as CIS benchmarks, NIST standards, or PCI DSS requirements.
  • Easy to Use: Prowler is simple to deploy and configure.
  • Cost-Effective: It offers a cost-effective alternative to implementing and managing numerous AWS Config rules.

Prowler will be scheduled to conduct regular security assessments across all accounts, specifically scanning for compliance based on your specific needs. Any failed checks will be published to AWS Security Hub for centralised monitoring and remediation.

Update the LZA configuration:

  • Open the customizations-config.yaml file in your local copy of the aws-accelerator-config repository.
  • Update the customizations section and make sure it looks something like this:
customizations:
  cloudFormationStacks:
    - name: ProwlerVpc
      description: Deploy custom Prowler Vpc
      deploymentTargets:
        accounts:
          - Audit
      regions:
        - eu-west-1
      template: custom-config-templates/prowler-vpc.yaml
      runOrder: 2
      terminationProtection: true
      parameters:
        - name: pVpcCidr
          value: "{{prowler-vpc-cidr}}"
        - name: pGLCTSolutionVersion
          value: "1.0.0"
    - name: ProwlerReposAndPipeline
      description: Deploy custom Prowler Repos And Pipeline
      deploymentTargets:
        accounts:
          - Audit
      regions:
        - eu-west-1
      template: custom-config-templates/prowler-pipeline.yaml
      runOrder: 3
      terminationProtection: true
      parameters:
        - name: pCodeCommitRepositoryName
          value: Prowler
        - name: pECRRepositoryName
          value: prowler
        - name: pGLCTSolutionVersion
          value: "1.0.0"
    - name: ProwlerInfra
      description: Deploy the infrastructure for running Prowler as a Fargate container
      deploymentTargets:
        accounts:
          - Audit
      regions:
        - eu-west-1
      template: custom-config-templates/prowler-infra.yaml
      runOrder: 4
      terminationProtection: true
      parameters:
        - name: pHomeRegion
          value: eu-west-1
        - name: pSchedule
          value: "cron(5 0 * * ? *)"
        - name: pProwlerContainerUri
          value: "{{account Audit}}.dkr.ecr.eu-west-1.amazonaws.com/prowler:latest"
        - name: pStandardProwlerReports
          value: "{{standard-prowler-reports}}"
        - name: pAdditionalProwlerReports
          value: "{{additional-prowler-reports}}"
        - name: pAdditionalProwlerReportsOUs
          value: "{{additional-prowler-reports-ou}}"
        - name: pGLCTSolutionVersion
          value: "1.0.0"
  • Open the replacements-config.yaml file in your local copy of the aws-accelerator-config repository.
  • Add the following section and make sure it looks something like this:
  - key: prowler-vpc-cidr
    type: String
    value: 192.168.0.0/24
  - key: standard-prowler-reports
    type: String
    value: "nist_csf_1.1_aws"
  - key: additional-prowler-reports
    type: String
    value: "pci_3.2.1_aws"
  - key: additional-prowler-reports-ou
    type: String
    value: "Production"

This configuration deploys Prowler security assessments within the AWS Landing Zone Accelerator (LZA), specifically in the “Audit” account within the eu-west-1 region. It sets up the necessary infrastructure through three CloudFormation stacks:

  • ProwlerVpc: Creates a dedicated VPC for Prowler.
  • ProwlerReposAndPipeline: Sets up CodeCommit repositories and a CodePipeline for building and deploying the Prowler container.
  • ProwlerInfra: Deploys the infrastructure to run Prowler as a Fargate container, including scheduling, container configuration, and report settings.

Essentially, this automates the deployment of Prowler, allowing for scheduled security checks across the AWS environment, with the resulting reports customisable based on defined parameters.

Save your changes:

  • Include the necessary SRA Modules YAML files alongside your CloudFormation code to provision the infrastructure for the varying SRA Modules (e.g., custom-config-templates/sra-account-alternate-contacts-main-ssm.yaml).
  • Use these commands to save your changes and update the LZA configuration:
git add .
git commit -m "Adding Prowler"
git push

Wrapping Up

That concludes our in-depth exploration of security within the AWS Landing Zone Accelerator (LZA)! We’ve covered a wide range of topics in this post, from addressing the LZA’s security limitations and leveraging the SRA to enhancing security configurations and implementing powerful tools like Prowler.

By incorporating these security best practices and customizations, you can establish a robust security foundation for your AWS environment, ensuring the confidentiality, integrity, and availability of your critical assets.

Conclusion

This concludes our comprehensive exploration of the AWS Landing Zone Accelerator (LZA)! We’ve journeyed through various aspects of setting up a well-governed and secure AWS environment, from establishing your organisation and configuring accounts to implementing robust security measures and automating key processes.

Throughout this series, we’ve highlighted the LZA’s strengths in providing a solid foundation for your AWS deployments, while also acknowledging its limitations and offering solutions to address them. By combining the LZA’s capabilities with thoughtful customisations and best practices, you can create a truly tailored and optimised environment for your workloads.

Remember that the LZA is a powerful tool, but it’s not a one-size-fits-all solution. It’s essential to understand your specific requirements, security posture, and compliance needs to effectively leverage the LZA and build a cloud environment that meets your unique objectives.

I hope this series has provided you with valuable insights and guidance on your journey to mastering the LZA. Feel free to reach out with any questions or feedback.

Control Tower Landing Zone
© 2025 by Adam Divall
Bilberry Hugo Theme