Notices
View All Tags
As of December 31st, AWS will no longer provide support for the Go 1.x runtime in AWS Lambda, as announced in this AWS blog post.
This change will be deployed to all affected Stax-managed Lambda functions before December 31, 2023. No customer action is required for this change and we will inform you when this change has been applied.
For any further questions, please raise a support case.
On 11 September 2023, Stax will be releasing a change to remediate an issue impacting Reserved Instance (RI) recommendations shown within the Reserved Instances tab on the Savings Plans & RIs page. This issue is resulting in some out-of-date RI recommendations being collected from AWS member accounts.
After the change, Stax will only show RI recommendations that are less than 30 days old making the current recommendations and savings opportunities more accurate. Customers may notice a decrease in the **Total Potential Yearly Saving **and a reduction in the number of savings opportunities displayed.
This change does not impact RI recommendations generated by Stax within the AWS management account which are scoped to all accounts in the organization's consolidated billing family. These recommendations cover both the management account and member accounts and are refreshed daily.
As part of our ongoing maintenance and improvement of rules and rule bundles, we are updating rules related to AWS CloudTrail log metric filters. This change will offer a shift towards organization-level CloudTrail configurations, enabling enhanced security and manageability for your resources.
Please be aware that the existing rules will be deprecated in the following bundles:
AWS FTR version 1.0.0
CIS Benchmark from version 1.1.0 to 1.5.0
Organization Rules
S3 Best Practice version 1.0 and version 1.1
Stax Foundation Compliance version 1.0
The deprecated rules are as follows:
Ensure a log metric filter and alarm exist for AWS Config configuration changes,
Ensure a log metric filter and alarm exist for AWS Management Console authentication failures,
Ensure a log metric filter and alarm exist for Management Console sign-in without MFA,
Ensure a log metric filter and alarm exist for changes to Network Access Control Lists (NACL),
Ensure a log metric filter and alarm exist for changes to network gateways,
Ensure a log metric filter and alarm exist for CloudTrail configuration changes,
Ensure a log metric filter and alarm exist for disabling or scheduled deletion of customer-created CMKs,
Ensure a log metric filter and alarm exist for IAM policy changes,
Ensure a log metric filter and alarm exist for route table changes,
Ensure a log metric filter and alarm exist for S3 bucket policy changes,
Ensure a log metric filter and alarm exist for security group changes,
Ensure a log metric filter and alarm exist for unauthorized API calls,
Ensure a log metric filter and alarm exist for usage of root user credentials,
Ensure a log metric filter and alarm exist for VPC changes
The newly introduced rules will take their place with the following rule names respectively:
CloudTrail should have a log metric filter for AWS Config changes,
CloudTrail should have a log metric filter for Console authentication failures,
CloudTrail should have a log metric filter for Console sign-in without MFA,
CloudTrail should have a log metric filter for NACL changes,
CloudTrail should have a log metric filter for Network Gateway changes,
CloudTrail should have a log metric filter for CloudTrail configuration changes,
CloudTrail should have a log metric filter for scheduled deletion of customer-created CMKs,
CloudTrail should have a log metric filter for IAM policy changes,
CloudTrail should have a log metric filter for route table changes,
CloudTrail should have a log metric filter for s3 bucket policy changes,
CloudTrail should have a log metric filter for security group changes,
CloudTrail should have a log metric filter for unauthorized API calls,
CloudTrail should have a log metric filter for root user credentials,
CloudTrail should have a log metric filter for VPC changes
Please note that the check history for the deprecated rules will not be kept.
If you have any questions about this change and what it means for you, please contact support.
As part of the upcoming release to Manage AWS Organizational Units and Service Control Policies in Stax the following changes will be made to the Policies API Policy method's schema implementation. For a detailed outline of these changes, see the release plan here.
Removed: Attachableto is no longer defined in the schema
Removed: Mandatory is no longer defined in the schema
Removed: Public is no longer defined in the schema
Renamed: Policy is now defined as Content in the schema
Changed*:* Status values are now; ACTIVE, CREATE_FAILED, CREATE_IN_PROGRESS, DELETED, DELETE_FAILED, DELETE_IN_PROGRESS, UPDATE_IN_PROGRESS. Previous values; ACTIVE, DELETED, FAILED
Added: AwsId is now defined in the schema
Added: ExternalResource is now defined in the schema
Added: OrganisationAttachment is now defined in the schema
Added: PolicyOwner is now defined in the schema
Added: PolicyType is now defined in the schema
Added: Tags is now defined in the schema
Added: UserTaskId is now defined in the schema
The API documentation for the new Policies schema can be found here, with the release of this feature the Policyv2 schema will be renamed to replace Policy.
If you have questions or concerns regarding the changes, please reach out by raising a support case.
The "Unused Amazon EC2 security groups should be removed" rule is available to help organizations manage their use of security groups.
On 27 June 2023, a fix will be released to correct the outdated logic of this rule which may impact related compliance scores.
The following bundles will be affected:
EC2 Best Practices (version 1.0)
APRA (versions 1.0, 1.1)
The custom organization-level rule, if in use
These changes will be applied automatically by Stax. There will be no impact to service expected as a result of this update.
If you have any questions about this change and what it means for you, please contact support.
As part of Stax Assurance, Amazon GuardDuty is configured for Stax-managed AWS Organizations. In an upcoming release of Stax, advanced configuration of GuardDuty will be possible via the Stax Console and API.
There are several considerations for organizations with GuardDuty configuration in place beyond what Stax configures as part of Stax Assurance. Read Configure Amazon GuardDuty within Stax for more information. Contact your Customer Success Manager if you have any questions regarding this upcoming release.
On 15 May 2023, a change will be released for the listed Rules that check if object-level logging is enabled for S3 buckets.
Currently, S3 buckets in Stax-managed member accounts will fail the check even when the required CloudTrail S3 data event logging is enabled, because Stax follows AWS best practices and configures CloudTrail at the Organization-level, not within every individual member account.
After the change, this Rule will detect when S3 data event logging is enabled on CloudTrail trails configured in member accounts as well as when configured on Organization-level CloudTrail trails.
| Bundle Name | Rule Name |
|---|---|
| Organization Bundle/catalog | Ensure that Object-level logging for write events is enabled for S3 bucket Ensure that Object-level logging for read events is enabled for S3 bucket |
| CIS Benchmark v1.3.0, v1.4.0 & v1.5.0 | CIS 3.10 - Ensure that Object-level logging for write events is enabled for S3 bucket CIS 3.11 - Ensure that Object-level logging for read events is enabled for S3 bucket |
By default, Stax does not configure S3 object-level logging for Stax-managed accounts. An S3 bucket with a high workload could quickly generate thousands of logs in a short amount of time, resulting in increased AWS costs. Find out more about Enabling CloudTrail event logging for S3 buckets and objects.
On 10 May 2023, a fix will be released for Rules that check that RDS instances are publicly accessible via a VPC.
Currently, the listed Rules include a check that incorrectly marks an RDS database as public if the RDS instance in a VPC subnet has a default route CIDR block of 0.0.0.0/0. This check is invalid because the default route must also be configured with an internet gateway as the target to be publicly accessible.
| Bundle Name | Rule |
|---|---|
| CIS Benchmark Version 1.5.0 | CIS 2.3.3 - Ensure that public access is not given to RDS Instances This Rule also checks if the Publicly Accessible flag is disabled. |
| Organization Rules/Rule Catalog | Ensure that public access is not given to RDS Instance via VPC This Rule also checks if the RDS Instance Public Accessible setting is disabled RDS instances in a subnet should not have internet access |
| APRA Version 1.0 | RDS instances should not exist in public subnets |
| RDS Best Practice Version 1.0 | RDS instances in a subnet should not have internet access |
After the change, these Rules will pass if the below** condition is met:**
The RDS instance subnet does not allow public egress via a default route (CIDR block of 0.0.0.0/0) with an internet gateway as the target.
This change may impact the compliance score of the impacted rules.
On 1 May 2023 at 1300 UTC (2 May 2023 at 2300 AEST), the GET /20190206/groups/{group_id} route will return a 404 HTTP status code if the group_id provided has the status of DELETED or does not exist.
Previously, the archived record would be returned for a deleted group and "Groups": [] would be returned if the group did not exist.
On 1 May 2023 at 1300 UTC (2 May 2023 at 2300 AEST), the following changes will be made to the GET /20190206/users API route:
This route will no longer return API tokens. The GET /20190206/api-tokens route should be used instead
This route will no longer return DELETED users by default. The existing behavior was to return all users regardless of their status. To get a list of deleted users, you will need to explicitly request it with the status_filter query string, e.g. /users?status_filter=DELETED
The GET /20190206/users/{user_id} route will return a 404 HTTP status code if the user_id provided has the status of DELETED. Previously, this would return the archived record
If you have questions or concerns regarding the changes, please reach out by raising a support case.