For my first non-intro entry into this blog, I’d like to discuss the idea of data events (or data plane operations or data plane actions) in cloud environments, what they are, and the importance of them during alert triage and/or security incidents. Chances are I’ll probably use data events and data plane events interchangeably from here on out, but for all intents and purposes they are the same thing.
I’m quite the SMA (subject matter amateur) with AWS, so we’ll focus on AWS for this post (once I reach SMA level in GCP I may visit that. I’m not sure I have the constitution for Azure, but we’ll see 🤣). Amazon defines a data events as events that provide information about the resource operations performed on or in a resource.
These events are logged by AWS CloudTrail , which is an AWS service dedicated to recording events that happen within your AWS account(s). AWS has a litany of services that generate these data plane events and these events can be very high volume, depending on the service and how it’s deployed. It is for this reason that these events are not enabled by default and have to be enabled by the customer.
An example of a data event in AWS would be an object-level event, like GetObject:
{
"eventVersion": "1.11",
"userIdentity": {
"type": "AWSAccount",
"principalId": "",
"accountId": "anonymous"
},
"eventTime": "2025-06-09T02:13:42Z",
"eventSource": "s3.amazonaws.com",
"eventName": "GetObject",
"awsRegion": "us-east-1",
"sourceIPAddress": "xxx.xxx.xxx.xxx",
"userAgent": "[Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/137.0.0.0 Safari/537.36]",
"requestParameters": {
"bucketName": "phoe.live",
"Host": "phoe.live",
"key": "favicon.ico"
},
"responseElements": null,
"additionalEventData": {
"bytesTransferredIn": 0,
"x-amz-id-2": "uQdWd/PH8Re76zh+KDdMxyxv6Ospz7eioQ6XID3liv5SgVsUDaQUZSqhwUSwTL6nSxzGMTGmdTs=",
"bytesTransferredOut": 15406
},
"requestID": "FM10FZZ68GD002DP",
"eventID": "bb3e16ea-e9b6-3d14-b929-008229b5cf8b",
"readOnly": true,
"resources": [
{
"accountId": "012345678910",
"type": "AWS::S3::Bucket",
"ARN": "arn:aws:s3:::phoe.live"
},
{
"type": "AWS::S3::Object",
"ARN": "arn:aws:s3:::phoe.live/favicon.ico"
}
],
"eventType": "AwsApiCall",
"managementEvent": false,
"recipientAccountId": "012345678910",
"sharedEventID": "368cc3a6-8893-4c99-9e6c-a181381d7e10",
"eventCategory": "Data",
"tlsDetails": {
"clientProvidedHostHeader": "phoe.live"
}
},
Of course I sanitized the log a bit, but you can get the drift. The requestParameters that you see here will tell you what was accessed in the bucket. The bucketName should be self explanatory. The key is the object that was returned. GetObject is only one of a few object-level events data events recorded. ListOjects is another object-level event that is recorded from the data plane.
As mentioned above, these events record events happening on or to a resource. I can’t tell you how many occasions during my work day we get alerts detailing possible S3 Exfiltration and they can’t be investigated since S3 data events aren’t configured for the customer account. I get it, there’s a cost. Sometimes a very steep one. However, ransomware is starting to make its transition from being an exclusively on-premise threat to being a dual-threat on-premise and in the cloud. Fog Security has several fantastic write ups on cloud-native ransomware and good proactive moves you can make to prevent becoming a victim.
Going back to the 2 data plane events above, I’ve seen in a few data exfiltration incidents (those where data events are being captured) the ListObjects event prior to the GetObject event. Occasionally I’ve seen a HeadObject event mixed in there as well prior to the actual GetObject action. Actions like s3 sync use a collection of object-level API actions to perform the sync tasks, namely GetObject along with PutObject, CopyObject, and DeleteObject (there’s also a pluralized version of DeleteObject, DeleteObjects that’s leveraged for deleting multiple objects in a single API call. Really key to look for in ransomware investigations).
So you’re getting the idea of how important Data Events are, yes? If your data matters, and it should matter, then you’ll need visibility into who and what is accessing it.
If your pockets are deep, sure thing! Enable data events for everything 💸💸💸! However, it’s more preferable enable data events on key resource, such as critical databases or S3 buckets storing crown jewels. It should go without saying that super busy databases or S3 buckets that don’t house critical data you can probably forgo data actions on those to keep that poor credit card from melting. The most of the cloud dance is building vs. budget. Figure out what your log retention requirements are and manage the lifecycle of your data to optimize your costs. Can’t very well secure anything if you’re broke.
So to sum it all up: