Just finished a pretty deep dive into Panther's detection-as-code setup, specifically for spotting weird S3 access patterns. While their built-in S3 rules are a solid foundation, I found the real power is in tailoring detections to your own org's "normal."
Here's the workflow I landed on. The goal was to catch access that's anomalous in *context*—like a user account suddenly downloading gigabytes from a bucket it only ever listed, or access from a new city for a critical financial data bucket.
First, I mapped out what "normal" looks like for our high-value buckets. This meant reviewing CloudTrail logs in Panther's Data Explorer to baseline things like typical source IP ranges, user agents, and the ratio of `GetObject` to `ListBucket` calls. This context is key for writing a meaningful detection.
The detection itself hinges on a Python function. I started with Panther's `panther-s3-activity` helper to parse the event, then added logic to compare the event against my baseline. For example, I check if the `userIdentity.arn` is making a `Read` operation on a bucket tagged `Env: Production` and `DataClassification: Restricted`, but the `sourceIPAddress` isn't in our known corporate CIDR block. The function returns `True` if the event matches all those anomalous conditions.
The trickiest part was tuning the alert title and description to be actionable. Instead of just "Anomalous S3 Access," the alert now specifies the bucket, user, and the specific anomaly (e.g., "Restricted bucket accessed from unfamiliar ASN"). This makes triage much faster.
Has anyone else built similar contextual S3 rules? I'm curious how you're weighting different risk factors—like, is a new geography for an admin account always a `SEVERE`, or do you factor in time of day? Also, any pitfalls with managing false positives as you add more buckets to the monitoring scope?
✌️
✌️
You're overcomplicating it. Panther's cool, but that's a lot of upfront work to baseline "normal" for every high-value bucket.
Most of my team's weird S3 hits come from our own misconfigured IAM or scripts, not external threats. I'd rather set up a cheap CloudWatch Alarm on `GetObject` volume spikes and call it a day for 80% of cases.
Baselining user agents? Good luck with our data science team. Their Jupyter notebooks spawn new random ones every Tuesday.
CloudWatch alarms are fine for basic volumetric spikes, but they're useless for context. A sudden `GetObject` spike from a new AWS region is a very different risk than the same spike from your VPC. That's the gap.
Your data science team's random user agents are exactly why you need a baseline. You flag on the *absence* of their known chaotic patterns. If their service account stops generating its usual noise, that's the signal.
Treating internal misconfig as a non-threat is how exfiltration happens. A script with over-permissive IAM is a prime internal threat vector.