109 posts tagged with "Changed"

As announced on 17 January 2024, Stax has implemented a change in Stax-managed AWS Config to restrict the recording of global resources, such as IAM users, groups, roles, and customer-managed policies, to your Stax Installation Region only.

This change aligns with AWS Config best practices recommending the recording of global resources in a single region to prevent redundant copies of IAM configuration items across all regions.

Importantly, this change will not affect customer compliance with the CIS AWS Foundations Benchmark v1.2.0 and later control - “Ensure AWS Config is enabled in all regions”. The CIS AWS Benchmark’s Audit procedure specifies that recording of global resources is only required in one region. For more details, refer to the CIS AWS Benchmark.

Impact of change

• Customers can expect a reduction in the number of redundant copies of IAM configuration items stored in every region.

• Customers using the CIS AWS Foundations Benchmark v1.2.0 and v1.4.0 in AWS Security Hub may observe a change in the compliance status of control: [Config.1] AWS Config should be enabled. This adjustment is attributed to the rule mandating the recording of global resources in all regions. For more information and guidance on suppressing findings for this control manually or through an automation rule, please visit the following AWS guides:

- AWS Config Rules and Global Resource Types

- Security Hub controls that you might want to disable

On 23 January 2024, Stax will implement a change to restrict the recording of global resources, such as IAM users, groups, roles, and customer-managed policies, to your Stax Installation Region.

This change aligns with AWS Config best practices recommending the recording of global resources in a single region to prevent redundant copies of IAM configuration items across all regions. Additionally, this change may help customers in reducing their AWS Config costs.

Importantly, this change does not affect customer compliance with the CIS AWS Foundations Benchmark v1.2.0 and later control - “Ensure AWS Config is enabled in all regions”. The CIS AWS Benchmark’s Audit procedure specifies that including global resources related to IAM resources is required in only one region. For more details, refer to the CIS AWS Benchmark.

Impact of change

• After the change, customers can expect a reduction in the number of redundant copies of IAM configuration items stored in every region.
• Customers using the CIS AWS Foundations Benchmark v1.2.0 and v1.4.0 in AWS Security Hub may observe a change in the compliance status of control: [Config.1] AWS Config should be enabled. This adjustment is attributed to the rule mandating the recording of global resources in all regions. For more information and guidance on suppressing findings for this control manually or through an automation rule, please visit the following AWS guides: - AWS Config Rules and Global Resource Types - Security Hub controls that you might want to disable

A number of Rule names have been updated to improve usability and standardize rule names across all Rule Bundles. To find out more, visit the Stax Compliance module guide.

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.

Stax has released a new version of the Cost & Compliance module's service and billing roles, version 33. The following permissions have been added to the roles:

• backup:Describe*
• backup:Get*
• backup:List*
• cloudtrail:List*
• waf-regional:Get*
• waf-regional:List*

If your AWS accounts are Stax-managed, then you don't need to take any action. Stax will automatically update this role in the coming days.

If you're subscribed only to the Stax Cost & Compliance module, you will need to apply the update yourself.

For any questions about this change, or if you need assistance deploying the updated role, please raise a support case.

Stax has released a new version of the Cost & Compliance module's service and billing roles, version 32. The following permissions have been added to the roles:

• backup:GetBackupSelection

• backup:ListBackupPlans

• backup:ListBackupSelections

If your AWS accounts are Stax-managed, then you don't need to take any action. Stax will automatically update this role in the coming days.

If you're subscribed only to the Stax Cost & Compliance module, you will need to apply the update yourself.

For any questions about this change, or if you need assistance deploying the updated role, please raise a support case.

Default subscription preferences have changed for new users invited to Stax. After joining Stax, new users will now only be subscribed to the Weekly Summary, Wastage Report and New Rule Releases notification types. Users can then manage their notifications and make changes to their preferences.

As announced on 19th April 2023, the GET /20190206/groups/{group_id} route now returns 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.

As announced on 6th April 2023, the following changes were made to the GET /20190206/users API route:

1. This route no longer returns API tokens. The GET /20190206/api-tokens route should be used instead
2. This route no longer returns DELETED users by default. The previous 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
3. The GET /20190206/users/{user_id} route now returns a 404 HTTP status code if the user_id provided has the status of DELETED. Previously, this would return the archived record

The Rule*** S3 enforces object encryptionhas been renamed to *** ***Ensure all S3 buckets employ server-side encryption-at-rest, ***in the S3 Best Practices and Organization bundles. This change helps to align the rule name across different bundles making it easier for customers to search for this rule across bundles.

It's important to note that the name of the rule has not been changed in the CIS Benchmark bundle to align with the standard's specification.