Skip to main content

Understanding Stax GuardDuty Findings

Reviewing Amazon GuardDuty findings (centralized in your foundation security account) on a regular basis is a key step to safely operating in the cloud. It is important to have an understanding of what is occurring in your AWS environment, and who is taking those actions. This is a key principle of the Shared Responsibility Model.

From time to time, you may notice actions taken in your Stax-managed AWS Accounts that you don't recognize. These most commonly surface in Amazon GuardDuty. It's important to review all unexpected and unknown activities in your account. Some of these activities may be performed by the Stax Assurance process or by Stax engineers.

Determining the source of a GuardDuty finding​

First, you'll need to review the payload of the GuardDuty finding. You can do this in the GuardDuty console or by using the AWS CLI.

GuardDuty findings that have been triggered by Stax-related activity will occur because of two reasons:

  • Stax automated services have run an operation in your account

  • A Stax or partner engineer has run an operation in your account

Both of these scenarios result in Stax identifiers appearing within GuardDuty findings, which will help you to attribute the GuardDuty finding to a Stax activity.

Stax Automated Services Have Run an Operation in Your Account​

Stax is a managed platform with processes that regularly run in your accounts to help ensure security and compliance. These include both Stax Assurance actions, and Stax's evergreen operations that ensure new features are made available to you in a timely, secure, and well-architected fashion.

In the event that Stax automation runs an operation in an AWS Account of yours, the GuardDuty finding will contain a reference to the StaxManagement role (see the documentation for more details). This is an IAM role that is used by Stax to perform maintenance and updates in your Stax accounts. Consequently, the GuardDuty finding will contain the below identity attributes which indicate the finding is related to Stax activities:

"userType": "AssumedRole",
"userName": "StaxManagement",

This is an expected finding as part of Stax's operations, but you should still review it carefully to ensure activities are expected.

A Stax or Partner Engineer Has Run an Operation in Your Account​

In the event that a Stax or Partner Engineer has accessed an AWS Account of yours (for example, after receiving your consent as part of resolving a support case), a GuardDuty finding may be triggered with the tile Unusual console login was seen for principal [UUID]. To determine if this finding can be attributed to a Stax or partner engineer, you can follow the below steps to cross check the GuardDuty finding with the AWS CloudTrail log.

  1. Navigate to the AWS CloudTrail console within the AWS Account that the activity took place in

  2. Select the us-east-1 region

  3. Select Event History in the CloudTrail left-hand menu

  4. Select Event name in the dropdown list of Lookup attributes

  5. Type AssumeRoleWithSAML in the search box

  6. Enter a time range that matches the GuardDuty finding

You will then need to find the CloudTrail log that matches the time and date of the GuardDuty finding. When reviewing CloudTrail logs, the sessionContext section will contain a reference to the stax-admin-admin-role if the activity was performed by a Stax or partner engineer. Specifically, the log will contain the below attributes:

"arn": "arn:aws:iam::<AWSAccountID>:role/stax-admin-admin-role",
"userName": "stax-admin-admin-role"

Why a Stax Engineer Might Access Your Account​

Within the Shared Responsibility model, there are typically only four reasons whereby a Stax Engineer might access your account:

Investigation of a Support Case: After you raise a support case requesting assistance, a Stax Engineer may need to access your account. Before this can occur, they will first require consent in writing from an admin level user of your tenancy. This should be provided as a response within the support case. The role is deployed for a maximum length of 120 min before being automatically deleted.

Security Threat Investigation and Response: In rare circumstances it may be necessary for a Stax Engineer to access your account to investigate a potential security threat without advising you in advance. In these circumstances advice and justification will be provided after the fact. The role is deployed for a maximum length of 120 min before being automatically deleted.

During Scheduled Maintenance: In rare circumstances it may be necessary for a Stax Engineer to access your account during scheduled maintenance. Under these circumstances advice and justification will be provided after the fact. The role is deployed for a maximum length of 120 min before being automatically deleted. To be notified of scheduled maintenance, subscribe to updates on the Stax status page.

During an Incident: In rare circumstances it may be necessary for a Stax Engineer to access your account during an ongoing incident. Under these circumstances advice and justification will be provided after the fact.

Stax Onboarding: A Stax Engineer may need to access your account during account onboarding. Before this can occur, we will first require consent in writing from an admin level user of your tenancy. The role is automatically deleted after 7 days.

Stax Offboarding: A Stax Engineer may need to access your account during account offboarding. Before this can occur, they will first require consent in writing from an admin level user of your tenancy. This should be provided as a response within the support case. The role is deployed for a maximum length of 120 min before being automatically deleted.

Following up​

Should you have further queries about activities in your account, don't hesitate to raise a support case to have Stax provide any additional context you may require. Make sure you provide either an export of the GuardDuty finding or of the CloudTrail event.