Stax's user and group APIs have been updated to enable more comprehensive management and recreation of deleted resources.

Previously when a user was deleted from Stax, the email address was unable to be reused to invite a new user and a suport case was required. Users can now be invited with the same email address as a previously deleted user.

Additionally, once a user is deactivated in Stax, they can now be deleted from the Stax console. Previously, deletion was only supported in the API and SDK. This option is available by clicking the vertical ellipsis (⋮) next to the deactivated user's details.

Previously when a group was deleted from Stax, the group name was unable to be reused to create a new group with the same name. Any groups deleted from 13 October 2021 onwards can have their name reused for creation of new groups. For any groups deleted prior to this date, raise a support case to have the change applied to it retroactively.

An update has been applied to the Stax Identity Service to improve performance and reliability.

The update implements security and stability updates to the underlying software as well as laying the foundation for upcoming feature releases. No functional changes have been introduced.

These changes have been applied automatically by Stax during the advertised maintenance window. There is no impact to service expected as a result of this upgrade. Should you experience any issues, please raise a support case.

To ensure you receive notice of upcoming changes to Stax, make sure you're subscribed to the status page.

When the UserCreateEvent, UserUpdateEvent, and UserDeleteEvent events occur, Stax Events now includes the user's status in the userStatus property.

See the Security Events Schema documentation for this property's expected values.

An update has been applied to Stax Workloads to improve performance and reliability:

• Fixed an issue where the Workloads API would accept a Catalog Item Version from a different Catalog Item resulting in the Workload being created/updated with a Version from an incorrect Catalog. If an invalid Catalog Item Version is used, the API will now return a 400 "Bad Request" response, along with an error payload detailing the error.

These changes have been applied automatically by Stax. There is no impact to service expected as a result of this upgrade. Should you experience any issues, please raise a support case.

Stax now supports daily Compliance notifications, in addition to the existing daily Cost notifications. These notifications allow you to retrieve a proactive summary of your organization's compliance posture based on Rules configured in the Compliance module.

This new notification shows:

• Count of new high priority rules failing since the day before

• Count of new high priority resources failing since the day before

• A list of high priority resource changes since the day before

This notification can be received by all supported channels for Notifications. To get started, see Create a Notification.

On the Data page, the new Marketplace Product property can be used to filter and group records by whether or not they are AWS Marketplace purchases. This is particularly useful when comparing AWS consumption in Stax to that which appears on your AWS invoice, and when considering chargeback/showback models internally. This information was previously only available when exporting data from the Data page using the Export Data button. Read more.

Additionally, a number of minor improvements have been made to the Data page:

• Common properties such as Kind, Account, Region, etc. have been moved to the top of the property list when configuring filters or groupings

• When grouping data, the Sum of Usage Cost field has been renamed to Total Usage Cost. Sum of Financial Cost has been renamed to Total Financial Cost

• Formatting of negative numbers has been improved

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.

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.