The Stax Accounts service has been uplifted to improve core operating processes.

This change decreases the time taken to provision new Stax-managed AWS accounts, and improves the reliability of this process. Additionally, the Security Foundation Account now manages Amazon GuardDuty members via AWS Organizations, instead of individually by invitation. This change to the Amazon GuardDuty configuration is in alignment with the latest AWS offerings and recommended best practices.

You don't need to do anything to take advantage of these improvements. Next time you create a new AWS account using the Stax Console, API, or SDK, the upgraded Accounts service will be utilized.

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

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

This system update lays the foundation for upcoming feature releases.

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.

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

This system update lays the foundation for upcoming feature releases.

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.

Stax has released an update to the definition of the Rule CIS 2.1.2 - Ensure S3 Bucket Policy allows HTTPS requests. This update better aligns Stax's implementation of the Rule to the definition from Version 1.3.0 of the CIS AWS Foundations Benchmark.

The CIS Benchmark dictates that policies should require HTTPS access specifically for the s3:GetObject action. Previously, Stax's implementation would check for the _, or "wildcard", action. This required that the policy enforce HTTPS for all actions, rather than just _s3:GetObject as specified in the CIS Benchmark. With the updated Rule definition, a bucket with the appropriate policy (as per the CIS benchmark document) on specific action s3:GetObject that would have previously deemed as non-compliant* will now correctly be considered compliant.

To ensure continuity for Rule compliance timelines, Stax has populated the history for this Rule using the updated definition.

If you observe buckets that were previously non-compliant now showing as compliant, it is likely that they were previously marked as non-compliant due to the stricter definition implemented by Stax.

For any questions around this change, or if you need assistance understand how the change applies to your buckets, please raise a support case.

Stax account tags are now applied to cost and compliance data in Stax. This enriched data allows you to organize, view, and group your resources using account tags to better meet your business needs.

As a result of Stax's improvement to propagate account tags to AWS accounts, these tags are now available in Stax's cost and compliance data. This means they can be used with Views on the Dashboard, Cost, Data and Rules pages of Stax. Within 24 hours of adding or modifying an account tag, the tag will be applied to all of that account's resources represented in Stax's cost and compliance data. Tags added via Stax take the format of stax:user:<tag_key>.

If you're subscribed only to the Stax Cost & Compliance module, you can make use of this feature by tagging AWS account resources directly. Tags will propagate to all resources in cost and compliance data in the same <tag_key> format as they appear in AWS.

While changes made to account tags directly within AWS will be represented in cost and compliance data, it is recommended that changes are made to Stax-managed account tags from within Stax using the console, API, or SDK.

Account tags in Stax will now propagate to the AWS account in AWS Organizations.

Since inception, Stax has permitted assigning tags to Stax-managed accounts. Those tags will now be propagated to the underlying AWS account. Tags will be in the format of stax:user:<tag_key>.

In addition to any tags you create, Stax assigns other tags to Stax-managed AWS accounts, including:

• stax:organisationid (The identifier for your Stax tenancy, in UUID format)
• stax:accounttypeid (The identifier for the account's Account Type, in UUID format)
• stax:accounttypename (The name of the account's Account Type)
• stax:accountname (The name of the account)

It is important to note that changes made to account tags directly within AWS will not be reflected in Stax, so it is recommended that you make changes to account tags from within Stax using the console, API, or SDK.

Stax will update its account bootstrap process from July 1, 2021. After this time, the AWS account alias will no longer be generated or modified.

For existing accounts that already have an alias, the alias will remain unchanged.

This does not prevent you from creating an account alias at a later stage.

Advanced Routing for Stax Networks allows for modification of Transit Gateway and VPC subnet route tables using prefix lists.

This new feature allows for configuration of route table entries in both Networking Hubs or VPCs directly. These entries can direct traffic to other VPCs, VPNs, on-premises networks, or black holes.

To get started, see Advanced Routing in the docs. You'll need to have at least one Stax Networking Hub already in place.

Stax has updated a series of rules detecting publicly open S3 buckets to improve the logic around checking for permissions.

Previously, the given rules would require explicit matches of a policy with either the action of s3:GetObject or s3:PutObject, meaning policies which allowed s3:*, or an array of actions, wouldn't be considered correctly for the purposes of compliance.

This potentially resulted in false negatives for the affected rules, whereby a bucket wouldn't be considered to be publicly open when it had a directly attached policy, and a previously-invalid policy. This does not affect reporting for buckets where public access block was enabled, or where global grants were given.

The list of affected rules is as follows:

• S3 allows action to any principal in Organization Rules
• S3 Buckets should not be Publicly Open for Writes in Organization Rules
• S3 Buckets should not be Publicly Open for Reads in Organization Rules
• S3 Buckets should not be Publicly Open for Writes in S3 Best Practices, versions 1.0 and 1.1
• S3 Buckets should not be Publicly Open for Reads in S3 Best Practices, versions 1.0 and 1.1

Below is an example policy that would previously incorrectly pass these rules, but now will fail appropriately:

json { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowAccessToMyBucket", "Effect": "Allow", "Principal": "*", "Action": [ "s3:GetObject", "s3:PutObject" ], "Resource": "arn:aws:s3:::hello-world-this-is-a-bucket/*", } ] }

If you see previously existing buckets now showing as noncompliant, it is possible that they were previously ignored by this edge case. For any questions around this change, or if you need assistance understand how the change applies to your buckets, please raise a support case.

Stax has added additional Stax Networks code examples to the Python SDK.

Check out the Python SDK to get started.