I'm currently running the Splunk App for AWS and am receiving the data without a problem into its own index in our Splunk environment. I've configured Splunk ES CIM data models to look at our custom AWS index. My issue is that we have a correlation search (Short-lived Account Detected) turned on that is not working with our AWS logs properly. This correlation search came out of the box with Splunk Enterprise Security and works with our Windows Logs without an issue.
The problem is that this correlation search is supposed to show the account that was created and deleted within a short amount of time. But when it comes to our AWS logs, the correlation search generates a notable event that displays the wrong account name. It shows the account that performed the creation and deletion of the short-lived account and we do not want that. (Example shown in image below.)
I've went into the back-end (Linux CLI) to create a props.conf with a field-alias statement in the Splunk_TA_aws local configuration on our Splunk ES server, but the field alias didn't map the "requestParameters.userName" field to the "user" field like I thought it would. I thought that if I had mapped the interesting field to the field that the data model looked for, then it would show up in the notable event. This is the props.conf field alias that I created in the Splunk_TA_aws local configuration on our Splunk ES server:
[aws:cloudtrail] FIELDALIAS-requestParameters.userName-for-aws-cloudtrail = requestParameters.userName AS user
I'm I going about solving this issue the right way? If not, is there a better way to fix this?
@malcolmce and @luongg - thank you for the candid feedback, we're actually working through some updates to both the Auth DM as well as the AWS TA. We'll be sure to provide some guidance on this in the next week or so, but it's certainly a case we will account for as we make the updates.
It doesn't map the field aliases because the AWS app uses calculated fields to generate requestParameters.userName and calculated fields are processed after field aliasing in the search-time operation sequence.
I'm trying to do the same thing as you & having no luck. It seems to me that the AWS addon is CIM compliant in name only, the only thing populated are tags. It doesn't do much good when every other CIM field is "unknown". I'm beginning to wonder if trying to leverage the CIM is even worth it at this point....