-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[filebeat][aws][cloudtrail] accessKeyId should be searchable #18866
Comments
Pinging @elastic/siem (Team:SIEM) |
👍 That's probably the best approach. It might also be helpful to use a multi-field mapping (keyword+text) on the |
A string representation of the following fields was stored. Changing to an object which is more easily searched. - request_parameters - response_elements - additional_eventdata - service_event_details Closes elastic#18866
A string representation of the following fields was stored and indexed as keyword. Changing to a flattened object which is more easily searched. - request_parameters - response_elements - additional_eventdata - service_event_details Closes elastic#18866
A keyword representation of the following fields was stored. Adding text multi_fields so it can be searched more easily. - request_parameters - response_elements - additional_eventdata - service_event_details Closes elastic#18866
Coded up 3 options
|
The option put forth in #19020 would work best in my scenario because I only expect to need keyword-style searches. I was also concerned about mapping explosion, so I ran some tests on logs in my environment and came to a similar conclusion about magnitude (about 70-70 new mappings). However a more serious concern is that in some other places I've seen AWS logs emit different types for the same field name (I think from EventBridge, not GuardDuty) so the first option would carry an additional risk of potential data loss, especially as AWS continues to evolve the schemas of their emitted logs. |
New PR #19121 up that has both flattened & text multi_field. This will be backwards compatible but should offer the most flexibility. |
AWS cloudtrail events have the following fields where the subfields are highley variable: requestParameters, responseElements, additionalEventData and serviceEventDetails. multi_fields added to following fields - aws.cloudtrail.request_parameters - aws.cloudtrail.response_elements - aws.cloudtrail.additiona_eventdata - aws.cloudtrail.service_event_details flattened version of the fields are stored here: - aws.cloudtrail.flattened.request_parameters - aws.cloudtrail.flattened.response_elements - aws.cloudtrail.flattened.additiona_eventdata - aws.cloudtrail.flattened.service_event_details Closes elastic#18866
AWS cloudtrail events have the following fields where the subfields are highley variable: requestParameters, responseElements, additionalEventData and serviceEventDetails. multi_fields added to following fields - aws.cloudtrail.request_parameters - aws.cloudtrail.response_elements - aws.cloudtrail.additiona_eventdata - aws.cloudtrail.service_event_details flattened version of the fields are stored here: - aws.cloudtrail.flattened.request_parameters - aws.cloudtrail.flattened.response_elements - aws.cloudtrail.flattened.additiona_eventdata - aws.cloudtrail.flattened.service_event_details Closes #18866
AWS cloudtrail events have the following fields where the subfields are highley variable: requestParameters, responseElements, additionalEventData and serviceEventDetails. multi_fields added to following fields - aws.cloudtrail.request_parameters - aws.cloudtrail.response_elements - aws.cloudtrail.additiona_eventdata - aws.cloudtrail.service_event_details flattened version of the fields are stored here: - aws.cloudtrail.flattened.request_parameters - aws.cloudtrail.flattened.response_elements - aws.cloudtrail.flattened.additiona_eventdata - aws.cloudtrail.flattened.service_event_details Closes elastic#18866 (cherry picked from commit d16ecc9)
AWS cloudtrail events have the following fields where the subfields are highley variable: requestParameters, responseElements, additionalEventData and serviceEventDetails. multi_fields added to following fields - aws.cloudtrail.request_parameters - aws.cloudtrail.response_elements - aws.cloudtrail.additiona_eventdata - aws.cloudtrail.service_event_details flattened version of the fields are stored here: - aws.cloudtrail.flattened.request_parameters - aws.cloudtrail.flattened.response_elements - aws.cloudtrail.flattened.additiona_eventdata - aws.cloudtrail.flattened.service_event_details Closes #18866 (cherry picked from commit d16ecc9)
AWS cloudtrail events have the following fields where the subfields are highley variable: requestParameters, responseElements, additionalEventData and serviceEventDetails. multi_fields added to following fields - aws.cloudtrail.request_parameters - aws.cloudtrail.response_elements - aws.cloudtrail.additiona_eventdata - aws.cloudtrail.service_event_details flattened version of the fields are stored here: - aws.cloudtrail.flattened.request_parameters - aws.cloudtrail.flattened.response_elements - aws.cloudtrail.flattened.additiona_eventdata - aws.cloudtrail.flattened.service_event_details Closes elastic#18866
Describe the enhancement:
I'm using Filebeat with the aws module to ingest AWS CloudTrail logs into Elastic Cloud. This works mostly okay, except some of the most interesting pieces of data are not searchable. I am particularly interested in the
AssumeRole
event emitted by AWS CloudTrail (a full example is shown below). In this event, the fieldaws.cloudtrail.response_elements
contains a stringified object, which unfortunately makes the contents opaque and impossible to search for in Kibana.What would be super helpful is if
credentials.accessKeyId
andcredentials.sessionToken
were made searchable. Maybe this is possible by changing the tokenizer used on this field, but more likely it seems like it would require parsing this JSON and capturing those into new sub-fields.Here is the line of code where the event body is stringified:
https://github.com/elastic/beats/blob/v7.7.0/x-pack/filebeat/module/aws/cloudtrail/ingest/pipeline.yml#L132
Describe a specific use case for the enhancement or feature:
I am attempting to use Elastic Cloud as a SIEM, and indeed Elastic is positioning itself as a SIEM offering. However, this gap in functionality effectively makes it impossible for me to use Elastic to track down the person that performed a specific action, which makes it substantially less useful as a SIEM.
Example
AssumeRole
event fromaws.cloudtrail
:The text was updated successfully, but these errors were encountered: