What Are Security Alerts and False Positives?
Understanding Cybersecurity Step by Step — Part 8
Software engineering learner documenting my journey across Java, backend development, DSA, and cybersecurity. I write beginner-friendly explanations, practical notes, and lessons learned while building and analyzing real-world systems.
In Part 7, I finally understood how SIEM works.
It collects logs. Normalizes them. Runs rules. And when something matches, it creates an alert.
That alert lands in the analyst's queue.
And I thought .... okay, great. Alert fires. Analyst sees it. Analyst acts on it. Attack stopped.
Simple, right?
Then I learned something that genuinely surprised me.
Most alerts are wrong.
Not wrong like the SIEM broke. Wrong like ...... the rule fired perfectly, everything worked exactly as designed, and it still wasn't an actual attack.
I sat with that for a while. Because it changes how you think about the whole job.
The Monday morning moment
Let me tell you the scenario that made this click for me.
It's Monday morning. Arjun opens his dashboard.
Alert at the top. Severity: high.
"Multiple failed login attempts - 47 failures on account: sarah.thomas"
First instinct? Someone is brute-forcing Sarah's account.
But before doing anything, he checks the details.
Monday, 8:58 AM. Sarah's own laptop. Same IP she always uses. Same location. And at 9:02 AM - successful login.
What happened?
Sarah came back from the weekend, forgot her password, tried a few times, hit "forgot password," reset it, and logged in.
Not an attack. Just a Monday.
Alert closed. Two lines of notes. Four minutes total.
That's a false positive. And I didn't fully appreciate how much of the job this actually is until I started learning about it properly.
So what even is an alert?
When the SIEM creates an alert, it's not saying "you're being attacked."
It's raising its hand and saying - "hey, I found something that matches one of my rules. Can a human look at this?"
That's it. The alert is a question. Not a conclusion.
Is this actually a threat?
That's the analyst's job to answer. Not the SIEM's.
And that's where false positives come from. The SIEM matched the pattern. But the pattern, in this context, turned out to be harmless.
Sarah's 47 failed logins looked exactly like a brute force attack from the SIEM's perspective. Same IP, multiple failures, short time window. The rule was right to fire.
But the SIEM doesn't know it's Monday. It doesn't know Sarah always forgets her password after long weekends. It doesn't know what's normal for Sarah.
Arjun knows. Because Arjun is a human who understands context.
The thing that actually scared me
When I first learned about false positives, I thought ........ okay, a bit annoying, but manageable. Check the alert, close it, move on.
Then I learned about alert fatigue.
And that changed everything.
Here's the thing. A real SOC gets hundreds of alerts every single day. Tier 1 analysts are triaging constantly. Alert after alert after alert, shift after shift.
If most of those alerts keep turning out to be false positives - something starts to happen to the analyst's brain.
They get tired. Not physically tired. Decision-tired.
They start assuming alerts are probably nothing. They start checking less carefully. They develop a subconscious habit - close, close, close, this is probably fine.
And then one day, buried inside those hundreds of false alarms - a real attack shows up.
And it gets closed too.
That's alert fatigue. And from what I've read, it's one of the most common ways real attacks go undetected in actual SOC environments.
I wasn't expecting that when I started learning this. I thought the problem was missing alerts entirely. I didn't realize that too many alerts could be just as dangerous.
The four outcomes I didn't know existed
Once I started understanding this properly, I came across something that reframed the whole thing for me.
Every alert investigation ends in one of four ways.
True positive - alert fired, analyst checked, it's real. This is what the SIEM is built for.
False positive - alert fired, analyst checked, it's harmless. Sarah forgot her password.
True negative - no alert, nothing happened, everything is fine. Most of the time, this is the world.
False negative - no alert, but something did happen. An attack slipped through without matching any rule. Nobody saw it.
That last one is the one that keeps security teams up at night. And it's exactly why Tier 3 threat hunters don't wait for alerts - they go looking precisely because they know false negatives exist.
What triage actually looks like
I wanted to understand what the analyst is actually thinking when they open an alert. So I started breaking it down.
Here's a scenario that helped me get it.
New alert in Arjun's queue.
"Outbound connection from internal IP 10.0.0.52 to external IP 45.33.32.156 on port 4444"
Port 4444 is commonly associated with Metasploit - a well-known hacking tool. That sounds bad.
But instead of panicking, Arjun just starts asking questions.
What machine is 10.0.0.52? He checks. It's Vikram's laptop. Vikram is a developer.
What process made the connection? He pulls the endpoint logs. It came from node.js.
Is this normal for Vikram? He checks historical logs. Yes, Vikram's laptop makes outbound connections on all kinds of ports regularly. Local servers, test environments, debugging tools. That's just developer behaviour.
Is the destination flagged anywhere? He runs the IP through VirusTotal. Comes back clean.
Conclusion - Vikram was probably running a local development server. False positive. Closed with notes.
Four questions. Four minutes.
What I noticed when I mapped this out is that Arjun wasn't trying to prove it was an attack. He was trying to understand if it made sense. And once it did - he closed it confidently.
The thing that builds suspicion
I kept trying to figure out - what actually makes an alert feel real versus feel like noise?
And what I figured out is that it's never one thing. It's the combination.
Timing being off helps. Activity at 2 AM from an account that only ever works 9 to 5 feels different. The same login at 10 AM feels like nothing.
The source not matching helps. A login from a country the employee has never connected from before. A process running on a machine it has never touched.
The behaviour being inhuman helps. 340 login attempts in 2 minutes isn't a person. Humans don't type that consistently at that speed.
Multiple systems being involved helps. Same IP hitting the firewall, the authentication server, and the database within 10 minutes - that starts to look coordinated.
None of these alone means anything certain. But when two or three of them stack up on the same alert - the story starts to feel wrong. And when the story feels wrong, you dig.
The thing that actually shifted how I think
Early on, I thought the analyst's job was to answer ..... is this an attack?
But that's not really it.
The real question is - does this make sense?
Normal activity makes sense. It has context. It fits the pattern of what this user, this machine, this system normally does.
Suspicious activity doesn't quite fit. Something about it is slightly off. The timing is wrong. The source is unusual. The behaviour doesn't match the history.
The analyst isn't running rules. The analyst is reading a situation and asking whether the story holds together.
That skill - feeling when something is slightly wrong - that's not something you get from a textbook. It builds up over hundreds of hours of triage. Alert by alert. Check by check.
And I find that genuinely interesting. Because it means the job isn't just technical. It's almost investigative. Like being a detective who works entirely from digital evidence.
What changed for me after understanding this
Before this, I thought the goal of a SOC was to catch everything. Zero tolerance. Flag everything. Better safe than sorry.
After this, I see it completely differently.
A SOC that over-alerts is heading toward disaster just as surely as one that under-alerts. Too many false positives create the exact conditions that let real attacks through.
I also understood why rule tuning is something that never stops. The environment keeps changing. New tools get deployed. New behaviour patterns emerge. Rules that were accurate six months ago might be generating noise today.
And I understood something about the analyst role that I hadn't before. It's not a job where you follow a checklist. It's a job where you develop judgment. Where experience changes what you see when you look at the same alert a junior analyst would close in 30 seconds.
Key takeaway
An alert is a question. A false positive is when the answer turns out to be harmless. Alert fatigue is what happens when there are too many of those - and it's how real attacks get missed. The analyst's job isn't to decide if something is an attack. It's to decide if something makes sense. And the instinct to feel when it doesn't and that's what experience actually builds.
👉 In Part 9, we go into the Incident Response Lifecycle what happens the moment an analyst decides something is real, and how the SOC goes from detecting a threat to containing it, recovering from it, and making sure it doesn't happen again.
Part 1: What Really Happens When You “Just Open a Website”?
Part 2: Where Networks Become Vulnerable
Part 3 : How Hackers Find Vulnerabilities
Part 4: What Happens After a Cyber Attack?
Part 5: What Does a SOC Analyst Actually Do?
Part 6: Understanding Logs : The Backbone of Detection
Part 7: How SIEM Works Step by Step
