AWS CloudTrail is far from perfect but it has been battle tested as much as any SaaS audit log out there.
Who: userIdentity.arn
What: requestParameters.*, responseElements.*
When: eventTime
Where: sourceIPAddress, sourceVpce, userAgent
Why: userIdentity.issuer/rolesession
How: eventName, eventSource
Baller move is to include internal ops actions in your log.
Main thing is to think of it as a product rather than an a feature. People don't want 10 different audit logs...everything should flow through it. With CloudTrail this extensibility comes through the requestParameters/responseElements sections. Most of the schema is fixed but in these sections its service-specific.
In terms of integration, push audit via webhook or various cloud event/message brokers is ideal, but at bare minimum the customer needs to be able to ingest that data wholesale to integrate with their security stack.
I would agree, CloudTrail is a pretty good example. The who what where when why is a good starting point. We're building audit logs as a service and our event format looks similar: https://apptrail.com/docs/applications/guide/event-format
AWS CloudTrail is far from perfect but it has been battle tested as much as any SaaS audit log out there.
Who: userIdentity.arn
What: requestParameters.*, responseElements.*
When: eventTime
Where: sourceIPAddress, sourceVpce, userAgent
Why: userIdentity.issuer/rolesession
How: eventName, eventSource
Baller move is to include internal ops actions in your log.
Main thing is to think of it as a product rather than an a feature. People don't want 10 different audit logs...everything should flow through it. With CloudTrail this extensibility comes through the requestParameters/responseElements sections. Most of the schema is fixed but in these sections its service-specific.
In terms of integration, push audit via webhook or various cloud event/message brokers is ideal, but at bare minimum the customer needs to be able to ingest that data wholesale to integrate with their security stack.