Open pbnj-dragon opened 3 weeks ago
@pbnj-dragon in general I really like this addition, my only hesitation is that requestParameters
can sometimes be quite large. Here are some stats for a 24 hour CloudTrail log sample:
{ "avg_length": 140.80603, "avg_num_elements": 1.830889, "max_length": 10109, "max_num_elements": 15, "min_length": 11, "min_num_elements": 1 }
I'm checking internally to see if we have a recommended maximum for alert context, but curious if there are specific sub-fields or eventNames within CloudTrail that we could narrow this down to.
Hi @arielkr256 ,
but curious if there are specific sub-fields or eventNames within CloudTrail that we could narrow this down to.
It's less about particular sub-fields and more about the full context associated with the event.
We are trying to provide the full context in the alert that is sent out of Panther (e.g. Jira Alert Destination). Without that context, the alert is inactionable. For a "Public RDS Restore" alert, for example, users are presented with basic info (e.g. region, event name, event source, AWS account ID, source IP address, user agent, user/caller identity), but no info about the resource itself that the alert is about (e.g. db instance identifier, db snapshot identifier, db subnet group, db port, ...etc), all of which is in the requestParameters
.
Closes #1401
Background
requestParameters
contains critical information for incident responders that should be surfaced as part of the alert context.Changes
requestParameters
to the dict returned byaws_rule_context()
helper functionTesting