In one published case study of an industrial intrusion detection deployment, the system flagged more than 27,000 events as potentially malicious in a single observation window. Of those, 76 turned out to be real threats. The remaining 26,924 were noise. The false positive rate was 99.7 percent.
That number is not an outlier. It is the part of modern cybersecurity that almost no vendor will put in a sales deck, because the entire industry is built on telling customers they need to see more, not less. The 2025 SANS Detection and Response Survey found that 73 percent of security teams now rank false positives as their single biggest detection challenge. Microsoft and Omdia's State of the SOC 2026 work puts the average false positive rate across modern security operations at 46 percent. Praetorian's analysis goes higher: most security tools sit between 50 and 80 percent. A typical security operations center generates around 960 alerts per day. Roughly 63 percent of them are never investigated at all.
I am seventeen, and I have been building a network monitoring tool called Sentinel Security. The closer I get to a production system, the more I am convinced that the hardest engineering problem in this field is not catching attacks. It is deciding what to ignore. And the entire industry has been arguing about the wrong half of that question for two decades.
The math that does not add up
The pitch from almost every cybersecurity vendor for the last fifteen years has been visibility. More sensors. More logs. More data sources. More integrations. More dashboards. More alerts. The reasoning sounds correct on first hearing: a missed attack is worse than a false alarm, so the safe move feels like catching everything.
Then you look at the outcomes.
The 2025 Verizon Data Breach Investigations Report analyzed 22,052 security incidents and 12,195 confirmed breaches across 139 countries. Ransomware appeared in 44 percent of all breaches, up from 32 percent the year before. IBM's 2025 Cost of a Data Breach Report put the average global breach cost at $4.44 million and the average lifecycle at 241 days from initial compromise to containment. That works out to roughly $18,400 in damage per day of undetected access. The United States average hit an all-time high of $10.22 million per incident.
So the picture is this. The industry has spent more on detection tooling than at any point in its history. Breach costs are at record highs. And the analysts running these tools say the single biggest thing standing between them and their job is noise from the tools themselves. Something in that equation is broken.
My argument is that the broken part is not the tools. It is the design philosophy underneath them.
How detection works
There are two fundamental ways a security tool decides something is suspicious, and almost every product on the market is some blend of the two.
The first is signature-based detection. The system looks for known indicators of compromise. A specific byte sequence in a packet. A hash matching documented malware. A DNS lookup to a domain on a blocklist. Signatures are fast, cheap to run, and produce very few false positives when they are accurate. The limit is that signatures only catch what has already been documented. A novel attack slides past untouched.
The second is behavioral detection. The system builds a baseline of what normal traffic looks like, then alerts when current activity deviates from that baseline. Behavioral detection catches things signatures miss, including zero-day attacks and novel adversary techniques. The limit is that "unusual" is a slippery word. End-of-quarter reporting is unusual. New hires are unusual. A printer pulling down a firmware update from a domain it has never contacted before is, technically, unusual. None of these are attacks. All of them trigger alerts.
The honest reality of modern detection is that the engine is rarely the problem. The engine usually works. What does not work is the assumption baked into nearly every commercial product: that more alerts is always better than fewer.
What I am learning building Sentinel
When I started writing detection logic for Sentinel, I expected the difficulty to be in the engine. I thought the hard part would be catching real adversary behavior. That turned out to be the easier problem. Open-source libraries like Scapy handle most of the heavy lifting on packet capture. Public threat intelligence feeds cover a large share of known indicators. The detection layer, in isolation, is largely a solved problem.
What is not solved is what happens between the detection layer and the human reading the result.
Three design questions have shaped how I am thinking about the current build. These are also the questions I would push hardest on if I were evaluating any commercial detection product, not just my own.
The first is how the system expresses confidence. Most detection tools today produce a flat list of alerts, all marked "suspicious," and leave it to the analyst to figure out which ones matter. That is not a detection problem. It is a prioritization problem that the software is offloading onto a person. The version of Sentinel I am working on treats confidence as a first-class output: every alert carries a numeric score reflecting how certain the system is that an event is genuinely anomalous, not just unusual. A connection to a known command-and-control domain scores high. A new device on the network at midnight scores medium. An off-baseline DNS query from a known device with a predictable update schedule scores low. The first version of my logic treated all of these the same. The current direction is to use confidence as the gate that decides whether to alert at all.
The second is context. A workstation behaving like a workstation is normal. A workstation suddenly behaving like a server is not. Without context about a device's role, history, and typical behavior, the same packet can look completely benign or completely hostile. The current design treats every device on the network as having a learned profile that shapes how its activity gets interpreted. This sounds straightforward in writing. It is not. The data model has gone through three iterations and is still not where I want it.
The third is what happens after a false positive. A system that fires an alert, gets told it was benign, and then keeps firing the same alert on the same pattern is not a detection system. It is a notification system that no one will read after the first week. The design direction I am working toward is what the literature calls allowlisting with context. The system learns that a specific pattern, on a specific device, in a specific behavioral envelope, is acceptable for this organization. Not as generic machine learning, which on smaller networks tends to overfit immediately. As a structured rule.
None of these are solved problems. They are open engineering questions that I expect to keep working on for a long time. The thing I would defend is that they are the right questions, and most of the industry is still answering the wrong ones.
Why scale changes the cost, not the problem
The false positive problem affects every organization, but it does not affect them in the same way.
In a large enterprise SOC, the impact is measurable in analyst capacity. At 960 alerts per day across an 8-hour shift, an analyst has roughly 90 seconds per alert. If half of those alerts are false positives, half of every analyst's day is spent ruling out noise. Praetorian frames this as a doubling of detection capacity: an organization that reduces its false positive rate from 70 percent to 30 percent effectively doubles its real investigation throughput without hiring anyone. The financial implications scale with company size. IBM's 2025 data shows that organizations using AI and automation extensively cut their breach lifecycle by 80 days and saved an average of $1.9 million per incident, almost entirely by detecting things faster.
In a smaller organization without a dedicated security team, the math collapses entirely. The "team" is the IT generalist, or the founder, or whoever ended up with admin access to the router. The 90-second-per-alert budget does not exist. The threshold where people stop checking the dashboard is much lower than the industry assumes.
The detection problem is universal. The cost of getting it wrong is not. That asymmetry is one of the reasons I think this is a problem worth working on across the entire spectrum of network security, not just at the enterprise end where the budgets are.
What I actually think happens next
I am not going to claim Sentinel has solved any of this. The current build is better than the first version was, but the deeper challenge is that confidence scoring needs data, contextual rules need feedback, and both of those things take time on a live network to calibrate. A system designed to get quieter as it learns has to spend its early life being loud. That tension is not a marketing problem. It is a real engineering constraint, and I do not think any tool in the category has fully figured it out yet.
Here is what I have come to believe after several months of building. The cybersecurity industry will keep selling "more visibility" because the business model demands it. Vendors get paid by alert volume, sensor count, and dashboard complexity. None of those metrics correlates with how well an organization actually detects threats. The metric that does correlate is the one almost nobody markets on: precision. A system that fires only when it has high confidence catches more real attacks than one that fires constantly, because the human on the other end of it still bothers to look.
That is the part of this problem I think is worth working on. Not louder tools. Sharper ones.
Quick check: three questions
What does the article identify as the central design flaw in most modern detection products, and why does the author argue this is not actually an engine problem?
What are the three design properties the article argues every alert should carry before it reaches a human?
Why does the author argue that the false positive problem is universal but the cost of getting it wrong is asymmetric across organizations of different sizes?
Answers
Most detection products are built around the assumption that more alerts is always better than fewer, which produces an industry-wide false positive rate between 46 and 80 percent depending on the source. The engines themselves are rarely the problem. They usually catch what they are designed to catch. The flaw is in the design philosophy underneath: a flat list of "suspicious" alerts forces a human to do the prioritization that the software should be doing, and at scale this fails predictably.
Confidence (a numeric score reflecting how certain the system is that an event is genuinely anomalous, not just unusual), context (a learned profile for each device that shapes how its activity gets interpreted), and suppression behavior (whether the system actually learns from being told an alert was benign, or keeps firing on the same pattern). All three are open engineering questions, not solved problems.
Every organization deals with the same false positive rates because they use the same underlying detection logic. The cost varies sharply with how many people are available to absorb the noise. A large SOC measures the impact in lost analyst capacity. A smaller organization without a dedicated security team has no capacity at all, and the threshold where people stop checking the alerts is much lower than the industry assumes.
Sources
Verizon. 2025 Data Breach Investigations Report.
https://www.verizon.com/business/resources/reports/dbir/
IBM and Ponemon Institute. Cost of a Data Breach Report 2025.
https://www.ibm.com/reports/data-breach
SANS Institute. 2025 Detection and Response Survey.
Microsoft and Omdia. State of the SOC 2026.
Praetorian. Alert Fatigue and False Positives: Why More Alerts Mean Less Security.
https://www.praetorian.com/security-101/alert-fatigue-and-false-positives/
Vectra AI. Alert Fatigue: Causes, Real Cost, and How to Fix It.
https://www.vectra.ai/topics/alert-fatigue
Sentinel Security is a network monitoring product I am currently building. If you work in detection engineering, run a security operations function, or build security tools yourself, I would be glad to compare notes. You can reach me at contact@sentinelcybers.com.