Understanding Stax GuardDuty Findings

Stax's Account Assurance activities may trigger GuardDuty findings from time to time. It's important to review all GuardDuty findings to validate their legitimacy and risk.

Article Tags
On This Page
Determining the Source of a GuardDuty AlertStax Automated Services Has Run an Operation in Your AccountA Stax or Partner Engineer Has Run an Operation in Your AccountFollowing upSee also

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 Mindset.

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 events may be performed by Stax's regular Account Assurance activities.

Determining the Source of a GuardDuty Alert

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.

Stax Automated Services Has 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 Account 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 any of Stax's automation runs an operation in an AWS Account of yours, it will be accompanied by log events referring to the StaxHelper principle. Review the Principal ID of the finding to see this. It will show an AWS Access Key ID (something like AROAXXXX1XXXXXXX0X1XX ), followed by a colon (:), then the StaxHelper descriptor: AROAXXXX1XXXXXXX0X1XX:StaxHelper

The StaxHelper principal is used during the provisioning of Stax AWS Accounts to deploy Stax's required resources into your accounts, as well as during any later executions of Stax's Account Assurance activities. 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), you can see this by evaluating occurrences of the AssumeRolewithSAML CloudTrail event in the us-east-1 region. Stax engineers assume the staxid-admin-role from the staxid SAML provider in your accounts.

The following requestParameters values allow you to review who has accessed the account:

  • roleSessionName is the UUID of the user who accessed the account
  • stax-user-type within principalTags is the type of Stax user: customer is members of your organization, partner refers to your Stax partner, and provider refers to Stax engineers

Why a Stax Engineer Might Access Your Account

Within the Shared Responsibility model, there are typically only two 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.

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 thread without advising you in advance. In these circumstances advice and justification will be provided after the fact.

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.

See also