Summary
We wanted to notify you about an issue that has been identified with the AWS Secure Environment Accelerator (ASEA). For this issue to apply, Identity and Access Management (IAM) roles needed to be defined for a specific account in the ‘workload-account-configs’ section of the configuration and more than one account must exist within that account's organizational unit (OU). In this situation, this issue can cause the custom role to be created in all accounts in the specified account’s OU. This issue does NOT exist for accounts created in the 'mandatory-account-configs' section of the ASEA configuration file.
A review of the ‘workload-account-configs’ section of your configuration file can provide the best visibility for whether the issue applies to you:
- Do you have any custom roles defined in any ‘workload-account-configs’?
- Is there more than one account defined in the OU?
If the issue exists in your deployment, you can resolve the issue by upgrading to the latest ASEA release version (v1.5.3). If you are currently on this version, no further action needs to be taken.
AWS encourages all customers to keep their ASEA deployment up-to-date, planning for upgrades between quarterly and semi-annually. While a best practice and good security hygiene, it also simplifies unplanned patching.
FAQs
What is the risk of the issue?
Depending on the trust policy associated with the role this may allow a) users within a deployed account to elevate their privileges or b) allow users in account A who have been authorized to access data in account B, to assume this role in other accounts within the same organizational unit (assuming they know the 12 digit account number of an impacted account). In no event would this permit access from account and role combinations not already defined by you in a trust policy.
What do we need to do?
If the issue exists in your deployment, customers can resolve the issue using one of the two following methods:
- Upgrade to the latest ASEA release (v1.5.3) - AVAILABLE
- The upgrade will mitigate this issue.
- Customers on version v1.3.8 or higher can go directly to version 1.5.3.
- NOTE: the upgrade from v1.3.x to v1.5.x is considered a major upgrade
- Customers on versions lower than v1.3.8 will need to upgrade to v1.3.9 first before upgrading to v1.5.3.
- Manual Remediation
- Remove all ‘roles’ definitions from the 'workload-account-configs' section of the ASEA configuration file and re-run the State Machine.
- WARNING: this may break anything that relies on these roles, which will then need to be manually re-created (i.e. SIEM and cyber sensor roles, other custom roles created by customers, etc.).
In both cases the ASEA Phase1 CodeBuild log should be reviewed to ensure no roles failed to be deleted. This could occur if customers manually modified roles, creating dependencies which block deletion.
How was this issue discovered?
It was brought to our attention by an organization using a number of custom roles within their deployment.
When was this discovered?
When discovered, AWS promptly began working on a solution which led to this advisory.
Summary
We wanted to notify you about an issue that has been identified with the AWS Secure Environment Accelerator (ASEA). For this issue to apply, Identity and Access Management (IAM) roles needed to be defined for a specific account in the ‘workload-account-configs’ section of the configuration and more than one account must exist within that account's organizational unit (OU). In this situation, this issue can cause the custom role to be created in all accounts in the specified account’s OU. This issue does NOT exist for accounts created in the 'mandatory-account-configs' section of the ASEA configuration file.
A review of the ‘workload-account-configs’ section of your configuration file can provide the best visibility for whether the issue applies to you:
If the issue exists in your deployment, you can resolve the issue by upgrading to the latest ASEA release version (v1.5.3). If you are currently on this version, no further action needs to be taken.
AWS encourages all customers to keep their ASEA deployment up-to-date, planning for upgrades between quarterly and semi-annually. While a best practice and good security hygiene, it also simplifies unplanned patching.
FAQs
What is the risk of the issue?
Depending on the trust policy associated with the role this may allow a) users within a deployed account to elevate their privileges or b) allow users in account A who have been authorized to access data in account B, to assume this role in other accounts within the same organizational unit (assuming they know the 12 digit account number of an impacted account). In no event would this permit access from account and role combinations not already defined by you in a trust policy.
What do we need to do?
If the issue exists in your deployment, customers can resolve the issue using one of the two following methods:
In both cases the ASEA Phase1 CodeBuild log should be reviewed to ensure no roles failed to be deleted. This could occur if customers manually modified roles, creating dependencies which block deletion.
How was this issue discovered?
It was brought to our attention by an organization using a number of custom roles within their deployment.
When was this discovered?
When discovered, AWS promptly began working on a solution which led to this advisory.