Skip to content

Security FAQ⚓︎

How are new releases protected against malicious code and actors?⚓︎

The Landing Zone Accelerator implements a rigorous security review process for code releases. Each code modification undergoes comprehensive peer review, thorough testing and validation processes by the LZA team to detect potential vulnerabilities and malicious code early in the development cycle.

The team maintains strict adherence to AWS security guidelines and best practices throughout the development lifecycle. The solution has proven its reliability and security through multiple successful deployments, supporting organizations with stringent security and compliance requirements.

LZA operates as an open-source project with code publicly available on GitHub, provided "as is" without warranties. Public pull requests and issues are welcome and will be reviewed as time allows. Additionally, customers with an LZA deployment can request additional support through AWS Support.

Customers are responsible for ensuring compliance with their security best practices. Although this solution discusses both the technical and administrative requirements, this solution does not help them comply with the non-technical administrative requirements.

Why can't I disable Security Hub after it has been enabled?⚓︎

Once Security Hub has been activated in your Landing Zone Accelerator (LZA) deployment, it cannot be disabled by setting enable: false or by adding regions to excludeRegions in the security-config.yaml file. This is an intentional design choice by the LZA team.

For security-critical services like Security Hub, the solution intentionally does not disable them once enabled to prevent potential security gaps and data loss. This deliberate approach helps maintain continuous security monitoring and compliance posture across your AWS environment.

Example configuration that will not disable Security Hub once it has been previously enabled:

securityHub:
  enable: false  # This will not disable Security Hub if previously enabled
  regionAggregation: true
  excludeRegions:
    - eu-west-1  # This will not disable Security Hub in excluded regions
  standards:
    - name: AWS Foundational Security Best Practices v1.0.0
      enable: true

While this may limit configuration flexibility, it ensures that critical security monitoring remains active and prevents accidental exposure of your environment to security risks. The LZA team may revisit this approach in future releases based on customer feedback and requirements.

What purpose do the breakGlassUsers in reference/sample-configurations/lza-sample-config/iam-config.yaml serve, and what do I do with them?⚓︎

Break glass access is a recommended best practice for gaining access to the organization management account or sub-accounts when there is a security incident or failure of the Identity Provider (IdP) infrastructure. MFA and password reset on next sign-in policies are enforced for break glass users through the iam-policies/boundary-policy.json and iam-config.yaml settings. It is imperative for the organization management admin to register MFA devices and reset the Landing Zone Accelerator generated passwords before they expire, per the maxPasswordAge (https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAccountPasswordPolicy.html) setting in security-config.yaml. Of equal importance is the protection of the hardware MFA devices and passwords against unauthorized disclosure. This often involves enforcing dual authorization, that is, one trusted individual having access to the password and a different trusted individual having access to the MFA token.