How do you deal with a flood of mostly useless security alerts?

Start by sorting alerts into a few buckets: urgent action needed, someone should review it, and informational. Then look at the noisiest rules one at a time. Check what triggers them, whether the alert leads to a useful action, and who actually owns that action. Suppress duplicates or narrow overly broad conditions, but keep a record of what changed and review the results.

This takes real time, so it needs an owner and scheduled work, not an expectation that the team will quietly tune everything between other responsibilities. Recheck the rules when the systems they monitor change.

Bulk-closing alerts and pretending they were reviewed is a bad place to leave this. If there isn't enough time to investigate the volume, make that a visible staffing and risk decision. Show leadership the alert count, how much time triage takes, and an example of a real alert that got delayed in the noise. Ask them to choose what gets prioritized or what work gets paused.

That doesn't clean up the rules by itself, but it makes the tradeoff explicit instead of leaving individual staff to absorb it.

A severity label alone doesn't tell anyone what to do. An alert should explain what was observed, why it matters, what evidence supports it, and the next step. If the tool can't provide enough context to distinguish a likely issue from a routine event, treat that as a quality problem to fix, not just another red banner.

Be careful about solving this with a broad mute rule. A noisy alert may still catch something important, as the delayed incident shows. Try changes on a narrow rule or category, check whether the alerts become more actionable, and keep a way to revisit the change if the environment shifts.

For lower-priority findings, routing them to the service owner can also help, as long as ownership and follow-up expectations are clear.