The Stax Accounts API has been uplifted to expose the AWS account Canonical user ID.

This change extends the Stax Accounts API to display the AwsAccountCanonicalUserId.

(https://support.stax.io/hc/en-us/articles/4453778959503-About-Accounts)

Stax has introduced support for the Center for Internet Security's Amazon Web Services Foundations Benchmark version 1.4.0. This introduces the following changes over the previous iteration, version 1.3.0:

Three new rules were added to the Benchmark:

• 2.1.3: Ensure MFA Delete is enabled on S3 buckets
• 2.1.4: Ensure all data in Amazon S3 has been discovered, classified and secured when required (This rule cannot be automatically checked by Stax, see below for more details)
• 2.3.1: Ensure that encryption is enabled for RDS instances

One rule changed category:

• 2.1.5: Ensure that S3 Buckets are configured with 'Block public access (bucket settings)' was moved from Identity and Access Management to Storage.

The Rule Bundle cannot validate all components of the Benchmark, so the following items must be evaluated manually:

• 1.1: Maintain current contact details
• 1.2: Ensure security contact information is registered
• 1.3: Ensure security questions are registered in the AWS account
• 1.18: Ensure IAM instance roles are used for AWS resource access from instances
• 1.21: Ensure IAM users are managed centrally via identity federation or AWS Organizations for multi-account environments
• 2.1.4: Ensure all data in Amazon S3 has been discovered, classified and secured when required
• 5.4: Ensure routing tables for VPC peering are "least access"

To enable this new version of the Bundle, see Keep Bundles Up To Date. If you have automatic updates enabled, no action is required.

Stax has introduced new functionality on the Policies page which lets you attach Policies to Account Types or detach Policies. In addition, you can now see which Account Types have Policies attached. These changes make it easier to adjust Policy attachments and discern which Policies are in use.

Stax is improving the way it helps you to manage unused IAM credentials in line with the CIS AWS Foundations Benchmark item 1.3 – Ensure credentials unused for 90 days or greater are disabled in your Stax-managed AWS accounts. A managed AWS Config Conformance Pack will be deployed into these accounts. This replaces the existing AWS Lambda function previously performing this task.

This Conformance Pack evaluates all IAM users' passwords and active IAM access keys. If a credential has been inactive for greater than 90 days, the remediation action will revoke those credentials. Specifically, the IAM user's password will be deleted, and active access keys will be disabled.

Previously, a bug existed in the AWS Lambda function performing this task which meant credentials that had never been used would not be deleted/disabled.

The Conformance Pack comprises the following AWS-managed Config Rule and associated remediation configuration:

• Config Rule Identifier: IAM_USER_UNUSED_CREDENTIALS_CHECK

Checks if your AWS Identity and Access Management (IAM) users have passwords or active access keys that have not been used within the specified number of days you provided

• Remediation Configuration: AWSConfigRemediation-RevokeUnusedIAMUserCredentials

The AWSConfigRemediation-RevokeUnusedIAMUserCredentials runbook revokes unused AWS Identity and Access Management (IAM) passwords and active access keys. This runbook also deactivates expired access keys, and deletes expired login profiles. AWS Config must be enabled in the AWS Region where you run this automation

The Conformance Pack will be located in each Stax-managed AWS account, within the AWS Region of your Stax Installation. It will replace the existing AWS Lambda function, entitled stax-DisableUnusedCredentials, which will be deleted.

Once the Conformance Pack is deployed into an AWS account, it will trigger an evaluation of all IAM users in that account. Any non-compliant IAM users will be remediated immediately. This means that any unused passwords or access keys that have not been used for more than 90 days since creation will be deactivated immediately.

These changes will be implemented for Stax-managed AWS Organizations during the week beginning 20 September 2021. If you have any questions or concerns in advance of this, please contact your Customer Success Manager or raise a support case.

Stax has introduced filtering and sorting to the Permission Sets and Permission Set Assignment views.

This makes it easier to find relevant Permission Sets or Assignments.

• By default Permission Sets are filtered to show only those with a status of Active, and are shown in descending order by Created Date
• Multiple Permission Set filters can be added or removed for the Created By and Status properties
• By default Permission Set Assignments are filtered to show only those with a status of Deployment Complete and are shown in descending order by Created Date
• Multiple Permission Set Assignment filters can be added or removed for the Account Type, Created By, Group, and Status properties
• Both Permission Sets and Permission Set Assignments can be sorted by clicking on the relevant column heading

To get started, see Permission Sets in the docs.

Stax now supports using /31 CIDR blocks when using Stax to create virtual interfaces for use with for AWS Direct Connect.

Previously, only CIDR blocks of size /30 or larger could be used for virtual interfaces.

To make use of this change, enter a CIDR block of size /31 when creating a virtual interface.

Stax has introduced changes to Stax Workloads API endpoints to improve support for pagination.

This makes it easier to deal with large volumes of Workloads and Workload Catalog Items when using the Stax API.

• Fixed pagination on the Fetch Workloads API endpoint. This endpoint now correctly returns all matching results based on filters and accurately reports the correct total number of results: stax-au1 stax-us1 stax-eu1
• Added pagination on the Fetch Catalog Items API endpoint. This endpoint now supports pagination in a consistent manner with the rest of the Workloads API endpoints: stax-au1 stax-us1 stax-eu1

These changes have been applied automatically by Stax. Should you experience any issues, please raise a support case.

Improvements have been released to Stax's Accounts API endpoints with a focus on account alias management, AWS account ID filtering, and pagination.

• Account Alias management: The Accounts API endpoints (stax-au1 stax-eu1 stax-us1) now support creating and updating account aliases for Stax-managed AWS accounts. This is enabled by way of the AwsAccountAlias request parameter. Account aliases must comply with AWS requirements.
• AWS account ID filtering: The Accounts API endpoints (stax-au1 stax-eu1 stax-us1) now support filtering AWS accounts by their AWS account ID. The previous behaviour required that filtering be performed based on the Stax UUID for accounts. This is enabled by way of the aws_account_id_filter request parameter.
• Pagination improvements: A bug impacting pagination of the Fetch Accounts API endpoint has been fixed. Previously, a GET request to the Fetch Accounts (stax-au1 stax-eu1 stax-us1) endpoint would return some pages of empty results when a filter was applied. With this resolution, empty results are removed from responses and only resources identified by the filter are returned.

(https://support.stax.io/hc/en-us/articles/4453778959503-About-Accounts)

The security foundation account has been delegated as the AWS Firewall Manager administrator for Stax-managed AWS Organizations.

This change means that the security foundation account can now be used to centrally manage Firewall Manager policies.

For organizations where the AWS Firewall Manager administrator role has already been delegated to an account other than the security foundation account, this configuration remains unaltered. Should there be a requirement to change the AWS Firewall Manager administrator delegated account from its existing account to the security foundation account, please raise a support case.

Stax has deprecated its automatic CloudFormation template validation for Workload Catalog items.

When deploying a Workload Manifest file, Stax will validate the structure of the Manifest, ensure that all CloudFormation templates are reachable, and that the CloudFormation templates themselves are valid JSON or YAML. It will no longer query AWS's Validate Template API to validate the CloudFormation template(s) when a manifest is uploaded.

This feature has been deprecated as, in some instances, it prevented deployment of sophisticated Workloads and templates that relied on specific AWS account and region combinations.

The API endpoints affected are:

• Create Workload Catalog Item: stax-au1 stax-us1 stax-eu1
• Update Workload Catalog Item: stax-au1 stax-us1 stax-eu1

Consider leveraging the AWS CLI/API directly when developing CloudFormation templates to ensure their validity.

These changes have been applied automatically by Stax. Should you experience any issues, please raise a support case.