[Rule Tuning] `First Time Seen AWS Secret Value Accessed in Secrets Manager`
terrancedejesus opened this issue · comments
Link to rule
Description
This rule was reported to noisy in that the new term values assigned may not be as static and rotate often, meaning the concept of first occurrence is rather expected.
The intent of the rule is to identify programmatic access to AWS SecretsManager from a potentially compromised principal account. Therefore, global alert telemetry indicates that AWS lambda, Boto, and the AWS SDK are all common for these alerts as expected.
The adjustment that may need to be made and tested is what New Terms values are supplied.
value = ["aws.cloudtrail.user_identity.access_key_id", "aws.cloudtrail.request_parameters"]
Instead, we should review if the following is more appropriate as the principal policy would set in AWS and remain persistent across services such as EC2; not to mention it is used to specify access to SecretsManager and KMS.
value = ["aws.cloudtrail.user_identity.session_context.session_issuer.principal_id", "aws.cloudtrail.user_identity.access_key_id", "aws.cloudtrail.request_parameters"]
Example Data
Update 03-07-2024
I took some time to properly setup some AWS infrastructure and settings to emulate this behavior. Below captures this research/analysis and includes context as to how we can reduce false-positives and volume. Note that AWS entities created and used for these events have been removed.
Below shows a screenshot of the telemetry gathered from within the stack. The important context to highlight are the various techniques used to access the secret test from the SecretsManager.
The purpose of this was to review the values of aws.cloudtrail.user_identity.session_context.session_issuer.principal_id and user.id. principal.id is tied directly to the IAM role which is assigned to each EC2 instance where it provides permissions to access SecretsManager.
The AWS SDK (boto3), native AWS CLI and AWS Lambda were used to access the same secret. With IAM roles principal.id, they will change per AWS service when created, thus they are the same across the EC2 instances, but different in AWS lambda. This is the same for user.id, however these are unique to the service entity, specific lambda, EC2 instance, etc. and thus allow for better efficacy regarding this rule.
Python Script using boto3 to access secret where access permission is dependent on IAM role assigned to EC2 instance it's running on
Code used to access secrets with AWS SDK (boto3)
IAM role setup for EC2 instances to access secrets in SecretsManager - note this is service specific and thus not accessible via AWS Lambda
EC2 instance created with IAM role assigned
AWS Lambda used to access secrets - note that a different IAM role had to be created and scoped to AWS lambdas for this
Successful lambda test to access secret
AWS lambda creation with IAM role assigned
Native AWS CLI used to access secret
