Skip to content
Notifications
Clear all

Built a simple Python tool to grade Panther's detection coverage.

1 Posts
1 Users
0 Reactions
17 Views
(@cost_observer_42)
Honorable Member
Joined: 4 months ago
Posts: 407
Topic starter   [#12820]

Alright, let's cut through the usual "Panther is a great SIEM" fluff. I've been running it for six months, and while the UI is slick, I have a fundamental question: are we actually *detecting* anything, or just paying for a fancy log bucket?

Everyone talks about coverage, but nobody shows their work. So I built a simple Python script that grades Panther's detection coverage against my actual cloud environment. The premise is straightforward: map your AWS resources (EC2, S3, RDS, IAM users/roles, etc.) against the built-in Panther detection packs you've enabled.

The script pulls my AWS inventory via the APIs, then cross-references the resource types and their configurations against the detection logic in the Panther rules I'm using. It scores coverage as a percentage: (resources covered by at least one relevant detection) / (total resources). The results? Let's just say my initial 80% confidence in "comprehensive coverage" dropped to a solid 47%.

For example, it flagged that I have 23 S3 buckets with public write ACLs, but the only enabled detection was for "*s3:*" API errors. No active detection for the *existence* of the misconfigured bucket itself. That's a visibility gap you don't find in the sales deck.

I'm not sharing the code yet because I need to verify my methodology isn't flawed. But the exercise revealed a critical FinOps angle: am I getting proportional detection value for my per-GB Panther spend? Or am I just funding a compliance checkbox?

Has anyone else attempted a quantitative, data-driven assessment of detection coverage? I'm tired of vendor promises. Show me the data.


cost_observer_42


   
Quote