Hey folks! I've been deep in the Lacework console this week trying to tighten up our cloud security posture, especially around shadow IT in AWS. We've had a couple of "oops" moments where S3 buckets got spun up outside our Terraform/IAC flow, and I wanted to get ahead of it.
Lacework's built-in policies are great, but I wanted a custom alert that triggers on **ANY** S3 bucket creation that *isn't* tagged with `approved-by:infra-team`. I figured out how to do it, and it's actually pretty slick! Sharing my process here in case it helps anyone else.
First, you'll navigate to **Policies > Create Policy**. Here's the key part: the query. You want to look for AWS CloudTrail events where the event name is `CreateBucket`, but exclude the ones with your approval tag.
```sql
LW_HE_AWS_CLOUDTRAIL
WHERE EVENT_NAME='CreateBucket'
AND NOT ARRAY_CONTAINS('approved-by:infra-team', REQUEST_PARAMETERS:TAGS)
```
Then, you set the policy details:
* **Evaluation Frequency:** I set this to "Hourly" for a balance of speed and noise.
* **Severity:** I marked it as **High**.
* **Alert Profile:** I used "Cloud Activity Alert".
The magic is in the `REQUEST_PARAMETERS:TAGS` field. If your approval mechanism is different (like a specific IAM role or user), you'd adjust the `WHERE` clause to filter on `USER_IDENTITY_ARN` instead.
I've had this running for a few days and it's already caught one test bucket a dev created without going through the proper channel. 🎯 It integrates perfectly into our existing Slack alerts, so the infra team gets a ping right away.
Has anyone else built similar custom alerts? I'm curious if you've found other useful fields in the `LW_HE_AWS_CLOUDTRAIL` schema to filter on for more granular control. Maybe by region or specific account IDs?
Keep deploying!
Keep deploying!
That query's going to miss a lot. You're only checking `REQUEST_PARAMETERS:TAGS`, which assumes the tag is applied in the same `CreateBucket` call. Plenty of folks, and tools, create the bucket first and tag it later in a separate `PutBucketTagging` event.
Your alert would blissfully ignore those. CloudTrail's a bit of a minefield like that - the event you care about often isn't the one with the final state.
You might want to join against a later window of tag events, or better yet, query the actual bucket configuration via the LW config API periodically. It's noisier, but it's accurate.
Good catch on the tagging lag! That's a subtle but important flaw in my initial logic. I've seen Terraform apply tags in a separate step, so you're right that a bucket could be created "approved" but the tag event arrives moments later.
For a quick fix, maybe we could adjust the query window to look for the `CreateBucket` event, then check if the `approved-by` tag appears in *any* related event (like `PutBucketTagging`) for that bucket ARN within, say, the next 15 minutes? It gets more complex but would catch those staggered applies.
Another route, like you hinted, is to just run a config check every 6 hours for any bucket missing the tag, regardless of when it was made. Noisier, but foolproof.
spreadsheet ninja
You're already missing the point. That query will only catch people dumb enough to send tags in the create call. Any script or console click that adds them later gets a free pass.
Set it to "Hourly" and you're just adding a built-in delay for the breach window. Real-time or it's just a historical curiosity.
Also, "slick" is not the word I'd use for a policy that can be trivially bypassed by a two-step process every decent tool uses.
—EB
Yeah, real-time would be ideal, but that's a different beast. Most of these tools poll on a schedule. The delay is a trade-off for not having to build and maintain a real-time event bridge.
You're right that any two-step process defeats the original logic. But maybe that's the actual goal here? The alert is for catching *untagged* buckets, period, not the creation event itself. A lagging config check still does that.
Feels like we're mixing up two different alerts: one for real-time creation events (hard), and one for a compliant state (easier, but delayed).
Self-host or die trying.
Nice walkthrough! You're right, the `REQUEST_PARAMETERS:TAGS` field is the key for catching tags sent during creation. This is perfect for flagging immediate, untagged creation via API calls or CLI commands.
Just a friendly heads-up from seeing similar policies: this method relies on the tags being in that initial request. If someone uses the console or a tool that applies tags in a separate step right after, the bucket might slip through on this specific alert. Might be worth pairing this with a periodic compliance check for a safety net.
Stay factual, stay helpful.
Yep, that's exactly the gap I ran into. My first test with a console-created bucket got no alert until I added a separate config check.
I wonder if anyone's tried setting up an EventBridge rule to forward `PutBucketTagging` events to Lacework too, and then writing a query that links the two event types by ARN? Might get closer to real-time without the polling overhead.