Stax has released an update requiring Amazon Elastic Block Store (EBS) volume encryption in management accounts in all regions supported by Stax. This is to comply with CIS AWS Foundations Benchmark v1.4 control 2.2.1.

Stax uses the default aws/ebs encryption key. You can modify the default encryption key as required in the AWS Console.

Stax Networks now supports the EBS Interface VPC Endpoint for VPCs that are part of a Networking Hub.

You can enable the EBS Interface VPC Endpoints for new and existing Networking Hubs using the Stax Console, API, or SDK. See Manage Networking Hubs for more.

The results page for any given rule now supports searching of resources.

Enter a value into the search box then press enter to search the results. You can search by any field displayed in the table of results.

Stax has released a new Config Aggregator named stax-assurance-<stax_organization_id> in your security foundation account. It is an organizational aggregator with the intention of deprecating the current multi-account aggregator juma-assurance-<security_aws_account_id>, to simplify the configuration and management. You will find the aggregator in the AWS region according to your Stax Installation region.

For organizations where the security foundation account is not set up as the organization's delegated administrator account for AWS Config (with service principal config.amazonaws.com), this aggregator will not be created.

During the week beginning 29 November 2021, Stax will start the process of removing the aggregator juma-assurance-<security_aws_account_id> from your security foundation account.

Update: The juma-assurance-<security_aws_account_id> aggregator removal work has been completed for all Stax tenancies.

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

• Added a new default tag stax:organisation_alias to Workloads CloudFormation stacks

• Fixed an issue where Stax Workloads could be deployed to Stax-managed AWS accounts that are not active. If the account is not active, the Workloads API will now return a 400 "Bad Request" response, along with an error payload detailing the error.

• Fixed an issue where the Workloads Catalog could display a failed Catalog Version as the latest Catalog Version available for deployment. The Workloads Catalog will now only show the latest active Catalog Version, or null, if no active Catalog Versions are available. If trying to deploy a Workload Catalog with no latest version, 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 update. Should you experience any issues, please raise a support case.

Following the delegation of FMS administrator account, Stax has now configured an SNS topic in each supported region in the security foundation account. These topics will allow you to subscribe to receive notifications of possible DDoS attacks.

The topic ARNs are found by logging in to the foundation security account's AWS console, then browsing to the FMS settings page. To receive notifications, navigate to the AWS SNS console, locate the topic, then configure appropriate subscriptions.

For organizations where the AWS Firewall Manager administrator account is delegated to an account other than the security foundation account, this configuration will not be applied to your own delegate.

Stax has introduced new compliance Rules functionality that supports adding a reason to explain why a given Rule has been disabled.

This change helps provide your organization with greater oversight and visibility of disabled Rules.

To get started, see Disabling a Rule in Stax.

When creating networks using Stax Networks, several CloudFormation stacks are created for provisioning these resources. To allow for easier downstream consumption of resources created as part of these deployments, Stax has added additional outputs to the CloudFormation stacks.

The following fields have been added to both VPC and Transit VPC stacks:

• IGWId (Internet Gateway ID)

The following fields have been added to Transit VPC stack only:

• NATGatewayOne

• NATGatewayTwo

• NATGatewayThree

These outputs are created under certain conditions:

• The IGWId output is only created if Internet Gateway is enabled

• NATGatewayOne is only created if NAT Gateway is enabled

• NATGatewayTwo and NATGatewayThree are only created if redundant NAT is enabled

From 1 November 2021, some Australian organizations with an account ownership model whereby a reseller owns either the management account, or all accounts, will notice changes to cost data in Stax. This change is the first of many planned to make it easier for organizations utilizing a resell agreement to effectively manage and consolidate their Stax and AWS bills.

After this date, tax charges that appear as Tax or Tax Refund line items will no longer be available in Financial Mode on the Stax Cost and Data pages. Impacted customers will be able to view all tax charges on their AWS consumption bill from Stax or their reseller.

This change does not apply to organizations where all AWS accounts are customer-owned.

Version 1.4.0 of stax2aws has been released. This update contains the following changes:

• Increased the number of roles a user can be assigned to. In previous versions of stax2aws users may have encounterd an error too many roles - SAML assertion is greater than 100kb. Upgrading to version 1.4.0 or greater of stax2aws resolves this error.

• Account names (as configured in Stax) are now displayed alongside the account info. Previously the AWS IAM Account Alias was displayed, however relying on this information restricted the number of roles a user could have access to (See above). It also inhibited the user experience when accounts did not have an IAM Alias set. Stax2aws now integrates closely with Stax and will display the Stax account name for all roles.

• Default session duration changed to 1 hour (3600 seconds). In line with best practice the default session duration has been adjusted to be 1 hour. This can be increased at log in time by passing the session's desired duration (in seconds) with the new --session-duration parameter. This value can be up to the max-session-duration of the IAM Role being assumed. Providing a value for the --profile parameter will save the provided session duration for future executions.

• Apple Silicon and M1 support. stax2aws is now available natively for M1 Mac users.