Thoughts on the Fusion detection rules - do they ever generate useful incidents?

Oh man, that specific "resource deployment + execution" alert has burned me too. I completely get the frustration.

But I've found they work better for me when I scope them tightly to high-risk identities or resources. We tuned one down to only fire for service principals with high permissions, and that cut the noise by maybe 80%. We got a legit incident last month where a compromised user session spun up a container and started crypto mining within it - Fusion connected those two alerts that we'd have viewed separately.

The defaults are way too broad. Have you tried adjusting the entity filters on the ones giving you the most grief? The ML bit needs a much smaller sandbox to play in.

Ha, I could've written this post myself six months ago. That exact rule gave me a full-blown eye twitch. My team started calling them "Fusion confusions."

But I'll push back a tiny bit: they *can* catch stuff, just not in the default "spray and pray" mode. You have to weaponize them against your specific risk profile. For us, it was S3. We created a custom version scoped only to sensitive data buckets. The first real hit? A weird sequence where a user's access key got leaked, something downloaded a bunch of files, and then a new EC2 instance spun up in a different region minutes later. Individually, those alerts were buried. Together, it was a clear story.

The trick is to stop thinking of them as out-of-the-box magic and start treating them like expensive, fussy query builders. Feed them only the scariest entities you've got. Otherwise, yeah, it's just alert fatigue with a fancy ML sticker on it.

Ever tried pairing one with a custom analytics rule as the source? That's where the magic (or at least, less noise) happens.

Yeah, that exact scenario is a classic, and I totally feel your pain. The promise of connecting dots is so compelling, but the initial wave of false positives just drains analyst energy. I think you've put your finger on the core issue: the default rules are built for a generalized, high-risk attack pattern, but most of our environments are full of legitimate, noisy activity that fits that same pattern perfectly.

Your dev-plus-Lambda example is spot-on. The logic sees "deploy" then "execute" and rings the bell, but in a modern cloud setup, that's just Tuesday. It sounds like you're already doing the right thing by questioning the signal-to-noise ratio. A lot of folks just mute them entirely, which is a shame because, as others are starting to mention, they *can* be tuned into something valuable. But expecting them to work straight out of the gate is a sure path to disappointment.

Have you looked at the specific low-fidelity alerts that are feeding into these Fusion incidents for you? Sometimes, tuning those source alerts first - making them a bit more precise - can dramatically clean up the Fusion output without having to rebuild the whole rule.

The default entity mapping is way too noisy for most active AWS environments. They're built to find an attacker in a generic enterprise, not a dev in a CI/CD pipeline.

Your Terraform/Lambda example is the textbook case of why they fail out of the box. You can't treat scheduled automation as a high-risk sequence. The ML needs a constrained scope to be useful, like others have said.

Try disabling the broad ones and start from zero with a custom rule scoped to a single high-value service principal or crown jewel resource. Otherwise you're just training your team to ignore alerts.

Your example with the Terraform script and scheduled Lambda is the perfect case study for why the broad defaults fail. That combo of activity is practically a daily workflow, not an attack pattern.

I had to completely rebuild my approach with them. I cloned a few of the rules and changed the entity matching logic. Instead of letting it link any "Azure Resource" to any "Azure Resource", I set it to only create an incident if the *same* high-privilege service principal was in both the deployment alert and the execution alert. That immediately cut out the cross-owner noise like your dev vs. scheduled job scenario.

The screenshot request is a good one. I don't have one handy, but the useful ones look boring - they show a single identity doing a rapid, suspicious sequence across different log sources. The noise looks like a messy graph connecting unrelated actors. Maybe that's the litmus test right there.

That's a solid point about adjusting the entity matching logic. It's the difference between catching "two things happened" and "one entity did two suspicious things."

I've seen that same tuning work, but it introduces a different problem: administrative debt. Now you're maintaining cloned, scoped rules for each high-value resource or identity group. If your environment changes, those rules become stale fast. You need a process to review and update them, or you'll miss new threats.

So while the technical fix works, it turns a set-and-forget feature into an ongoing ops project. That's a real cost.

I agree that the out-of-the-box Fusion incidents are often noise, but your example is exactly why. The rule logic is simplistic.

It sees a deployment pattern and an execution pattern from the same cloud tenant and calls it a day. It doesn't understand context like CI/CD ownership or scheduled jobs. The "ML" part is overhyped; it's basic correlation with a fancy name.

If you haven't scoped the rule down to a specific high-risk identity or resource group first, you're just getting a report on normal cloud operations. The useful hits only come after you've done that manual tuning work, which defeats the "automatic" selling point.

Totally agree about the "ML" label being overhyped for this. It's really just correlation with a time window.

That said, the automatic tuning part isn't completely defeated. Once you've done the initial heavy lift of scoping it to a high-risk identity or resource group, the rule *can* start learning what's normal for *that specific scope*. It won't help with the CI/CD noise you mentioned, but it can baseline the activity of, say, your domain admin service accounts and then flag deviations. The problem is you have to build that guarded scope for it first, which is manual work they don't advertise.

So you're right, it's not automatic out of the box. It's a tool for building custom, scoped detectors, not a magic off-the-shelf analyst.