2026-05-07 –, IFEN room 1, Workshops and Detection Engineering village (Building D)
Security teams don't miss alerts because they don't care, they miss them because their SIEM never shuts up. Alerts fire constantly, at the wrong time, for expected behavior, until everything starts to sound the same. At some point, it's no longer an alarm. It's just noise.
This talk starts with a simple idea: when an alert fires matters just as much as what it detects. Like a whistle blaring at 2 a.m., many detections technically work, but fail operationally because they lack timing, throttling, or basic context. Alerts trigger during business hours, outside meaningful windows, or so often that everyone learns to ignore them.
Using practical examples, we'll look at common alerting mistakes, why "more alerts" doesn't mean better security, and how small changes, such as throttling, prioritization, and temporal context, can dramatically reduce noise.
From there, we'll walk through what alerts actually matter across application, network, Active Directory, and DNS telemetry, and how to design them so they fire when someone should actually care. The goal isn't silence, it's a SIEM that acts like an alarm clock, not a whistle that goes “woo woo” all night.
When then whistles go woo woo:
I typically like to start my presentation with a short story, a news article or some known fact and correlate it to the main topic.
In the early 2000s, residents in Seattle started complaining about a strange problem: cars driving through neighborhoods late at night, fitted with exhaust whistles so loud they could wake an entire block.
When asked about the noise, one explanation stuck: the whistles go "woo woo"… but only in the morning. The noise wasn’t dangerous, but it was constant, badly timed, and impossible to ignore.
Twenty years later, many security teams are dealing with the same problem, just with SIEM alerts instead of cars. If this feels familiar, it should. Many SIEMs do the exact same thing: alerts firing constantly, without timing or context, until everything sounds urgent and nothing actually is.
Wait, what are we doing here?
Brief explanation of contextual alerting for SIEM implementations.
Drawing parallels:
Noisy SIEMS vs The Whistles
Okay but how does SIEM obtain data:
Log collection and aggregation
How do I know what I want my SIEM to alert me on?
Knowing what you want your SIEM to alert on starts with understanding what actually requires action. Alerts are not meant to document everything that happens in an environment, they exist to interrupt you when something needs attention. If an alert does not change a decision, a response, or a priority, it probably does not need to exist.
- Unusual or anomalous behavior
- Known IOCs
- Signs of Privesc or lateral movement
- Indicators of Data exfil
- Repeated or unsuccessful actions.
- Unusual application activity
- Endpoint behavior
- Compliance violations
- Threat hunting
When alerts stop being alerts:
• Alerts aren't ignored because analysts are lazy
• They’re ignored because everything fires
• When every event is "urgent" nothing actually is
• Noise trains people to stop reacting.
• American Horror Story: MSSP - sharing a story of when I worked for an MSSP and I saw some awful things with SIEM alerting.
Timing Matters More Than You Think
• Alerts without time context are misleading
• Expected behavior during business hours ≠ malicious at 3 a.m.
• The same signal can mean very different things depending on when it happens
Key learning:
When an alert fires is part of the detection logic, not an afterthought.
Throttle the noise before you add more alerts
• Repeated alerts for the same behavior don't increase security
• They just increase annoyance
• Throttling prevents the SIEM from screaming about the same thing every five minutes
Examples:
• "Alert once per user per time window"
• "Suppress repeats unless behavior changes"
• "Escalate only if it keeps happening"
Context turns noise into signal
• Raw events is not the same as actionable alerts
• Alerts need:
○ user context
○ system role
○ expected behavior
○ related activity
Without context:
Everything looks suspicious.
With context:
You know what actually matters.
Designing your SIEM alerts:
- Focus on high risk scenarios
- Tune alerts over time
- Use correlation rules
- Threat intelligence is your bestie
- Context is key
Alert prioritization:
Alert prioritization isn't about deciding what’s "important" on paper, it's about deciding what deserves attention right now. When everything is marked high priority, teams stop trusting the system. Good prioritization accepts that not all alerts are equal, and that urgency depends on timing, context, and impact. A SIEM that understands this doesn't shout, it speaks when it actually matters.
- Critical: Imminent high impact threat such as ransomware or a data breach.
- High: Potential impact on core business operation or sensitive systems and direct evidence of malicious activity.
- Medium: Unusual activity that could potentially be a threat
- Low: Minor issue, security violation or potential false positive.
What logs do I need?
Deciding what logs you need is not about collecting everything, it is about collecting what helps you answer questions later. Logs should support detection, investigation, and response, not just exist for visibility. When logging is intentional, alerts become easier to design and noise becomes easier to control.
- Windows Logs
- Network Logs
- Endpoint Detection and Response (EDR) Logs
- Identity and Authentication Logs
- Threat Intelligence Logs
- Compliance and Audit Logs
Scrum for SIEM maintenance:
Knowing what you want your SIEM to alert on is not a one time decision, it is an ongoing process. Environments change, attackers change, and so does what actually deserves attention. Treating SIEM maintenance like a sprint forces teams to regularly ask what worked, what created noise, and what genuinely helped detect risk. Instead of reacting to every alert, the focus shifts to continuously refining what is worth waking someone up for.
- Define your scrum team (owner, scrum master and development team. Yes, it all applies even if it's not a software development environment).
- Create a "product backlog" (actionable items).
- Sprint planning (high risk priority tasks).
- Daily stand ups (share updates).
- Sprint Review (showcase deliverables).
Melina Phillips is an Offensive Security Engineer with a background in Security Operations and Incident Detection. She has over ten years of IT experience and six years working directly in cybersecurity, blending hands on blue team work with her current focus on adversary simulation and endpoint compromise.
Her recent talks have been featured at Bsides Cambridge, Security Fest, BruCon, LeHack, HackLu and BlackAlps. She's known for making complex technical concepts accessible without watering them down, and for delivering practical insights grounded in real world attack and defense experience. She strongly believes that Linux security doesn’t have to be presented in a boring way, and that technical depth and creativity can (and should) coexist.
Outside of breaking into infrastructure and chasing down Linux threats, she's usually at CrossFit or playing with makeup, ideally not at the same time.