Open terrancedejesus opened 2 months ago
cc @jamiehynds
cc @eyalkraft @tehilashn
I'd like to follow-up with a specific ask here:
For events that include a role.name
as part of the request_parameters
, it would be hugely beneficial to pull this out into a separate field. Similar to how target.user_name
and related.user
are created as separate fields for events targeting another user. I've come across this with 'sts:assumeRole' and 'iam:AttachRolePolicy' event actions. There is no easy way to track what role.name
is being targeted for those actions. This is necessary for threat hunting and alert triage purposes so that the targeted or referenced role.name
can be compared against subsequent events with the same user.name
. This will allow analyst to track the behaviors following potential compromise of an IAM role. I've attached a screenshot and events for a scenario where a highly privileged IAM poicy was attached to a role (captured as roleName
in request_parameters
), then that same role was assumed (captured in the role.arn
of request_parameters
), then that same assumed role did a follow-up action (captured under user.name
field). It would be nice to be able to follow these behaviors by comparing a role.name
field to that user.name
field.
Hey @terrancedejesus, I'm looking into the cloudtrail integration (from another perspective) and I saw this issue.
Regarding this point:
Since the value of these fields are nested JSON objects, querying the data requires us to rely on wildcard searches which is not ideal for efficacy or performance
Don't the flattened
fields aws.cloudtrail.flattened.response_elements
and aws.cloudtrail.flattened.request_parameters
enable you to query without relying on string processing and wildcards?
I've been doing it and it seems to suffice my needs. I wonder if it also fulfils your needs.
Below you can see a query I've done:
event.dataset: "aws.cloudtrail" and event.action: "AssumeRole" and aws.cloudtrail.flattened.response_elements.assumedRoleUser.assumedRoleId: "AROA2IBR2EZTCIK7YJG3E:TrustedAdvisor_704479110758_65cf4c6f-b374-4c58-8ea8-2285b3af904e"
Overview
In the AWS integration, most of our detections, rely on the following fields.
event.dataset
event.provider
event.action
event.outcome
aws.cloudtrail.request_parameters
aws.cloudtrail.response_elements
The creation of this issue is to focus on the
aws.cloudtrail.request_parameters
andaws.cloudtrail.response_elements
field. Most of the activity we actively capture with the AWS integrations are API requests, whereevent.provider
represents the AWS service (i.e. EC2, Lambda, S3, etc.) andevent.action
contains the API request (i.e. CreateRole, PutBucketPolicy, etc.). In theaws.cloudtrail.request_parameters
andaws.cloudtrail.response_elements
fields we have more context about the request and response. However, this field is currently a keyword field type or flattened (aws.cloudtrail.flattened.request_parameters
).Challenges
There are a ideal outcomes that would enable better threat detection rules and their respective queries:
request_parameters
.aws.cloudtrail.request_parameters
. It is not a consistent problem that I have ran into, but depends on the request itself. For example, when PEM file contents are sent with other parameters. Note that often we wildcard for values in here simply because they are not parsed out.The challenging part of this is the randomness of the values in
request_parameters
. There is no consistent data structure, but I believe it is highly dependent on theevent.provider
and the AWS resource the API request is being sent to. For example, forec2.amazonaws.com
we can expect to haveinstanceId
in this field nearly on every request.I understand that this may be a difficult hurdle, but overcoming it would improve the efficacy and performance of our rules for AWS. I am happy to give access to my environment or anything else required for investigation into this. There may be some custom analyzer options here, but I will be honest in stating my lack of understanding when it comes to data ingestion and the analyzers for each integration.
Thank you in advance!