#NSBCS.136 - Why 'More Visibility' Quietly Made Security Worse
In incident post-mortem, the conclusion often sounds the same: “We didn’t have visibility into that”. So, the fix is always the same: collect more. More logs, more coverage, more data sources. It sounds obviously correct and, in some instances, it is.
Comprehensive data collection is genuinely the right move in support of digital forensic investigations or auditing and is generally good practice for businesses to retain as much data as reasonably possible.
The problem arises when the same assumption is applied to managed detection and response (MDR) security solutions and services. Ingest more logs to our SIEM, create more detection rules, monitor more events. It sounds comprehensive. But in a SOC, the team responsible for detecting attacks in real time, more visibility is not always the answer. In practice, it often works against the very thing they're there to do: detect threats in their clients' environments.
Digital Forensics and Incident Response (DFIR) is retrospective and bounded. The attack has already occurred, and the threat is usually confirmed. Visibility is an asset analysts can draw from to piece together the facts and draw an accurate picture of what happened.
A SOC works the other way around. The job is prospective and unbounded, a continuous stream of activity that arrives without pause and never stops. When every minute matters in finding the needle in a haystack, the last thing you need is more hay.
Why the difference matters
In a SOC, analysts get filtered by the data, not the other way around.
A DFIR analyst works through their material at their own pace, in depth. They can decide where to start, stop, re-read, do some research and pick it back up tomorrow. In the SOC, this luxury doesn’t exist. Analysts are interfaced with a 24/7 feed where each alert may represent a real incident. Every bolted-on data source contributes to this feed and raises the alert volume baseline.
This is the part the ‘collect more, cover more’ instinct doesn’t often account for. Attention is finite, and there are inherent flaws with being presented with more and more data, especially when your job is to sift through it on a clock.
More rules is not more security
What happens after we’ve onboarded all these new data sources? They need to be utilised on the fly to detect threats, otherwise it’s just sitting there eating up costs. The natural next step to convert this raw data into signal is through the creation of detection rules. More rules covering more log types looks fantastic on paper, or a sales slide-deck. “Five hundred rules across twenty log source types”, who wouldn’t want it?
But this paints the wrong picture. Fundamentally, detection isn’t a volume game. Every rule that isn’t precise is a rule that generates false positive alerts that someone at some point has to manually look at. The important thing to understand is that each bad detection rule doesn’t just ‘cover another threat vector’ with no downsides, it actively introduces risk in the form of wasted time, potentially more pressing matters not being investigated, analyst burnout, loss of trust in detection capabilities and dangerous complacency in the form of “this alert is never a real issue”.
We can also challenge the data source itself – does it really provide value in threat detection? Does it cover a legitimate attack vector that poses an actual risk to the client? Or are we ingesting it just because the client asked for it, or that it just sounds good and is ‘instinctively’ the right thing to do?
All SOCs know that detection rules need to be kept in check, tuned to be high signal where possible. In practice, tuning is not a ‘one and done’ operation. Rules require ongoing maintenance and tuning, as client environments, technologies and attack methods change. More data sources and rules just add to this on-going workload. The ease of bringing in more data and creating more half-baked rules vastly outweighs the work it takes to curate the data over time into something of value for analysts to look at, through tuning, high-fidelity detections and other strategic solutions to prevent threats at the source. An asymmetry that if goes unchecked, trying to keep up is like trying to run on a treadmill that exponentially gets faster.
Incidentally, the SOC with the most ‘coverage’, can at the same time be the most ineffective in catching threats. More data sources are onboarded, more detection rules are created, alert volume grows out of control – the scope continues to creep, and the alert queue just keeps growing and growing. Eventually leading to outstanding alerts sitting for hours, not looked at. Sitting on these untouched alerts introduces risk and may represent potential incidents that have not been looked at yet.
This is what happens when volume and coverage become the metric, rather than the quality of detection capabilities.
What this actually looks like in practice
Take threat intelligence feeds as an example. SOC teams often subscribe to threat intelligence feeds, connecting them to their client data sources, usually stored in a SIEM. Think firewall logs, device networking events, web app logs etc., alerting on every bad IP address or domain that shows up in those logs.
What can be a very valuable, high-signal detection source, can very quickly become more of a hindrance than benefit if left unchecked.
On the surface, “Alerting across 10 million+ IoCs” sounds optically more impressive, and intuitively more effective than “100,000” for instance. Yet, the effectiveness is mostly determined by the quality of the IoCs themselves - the filter.
The large dataset may contain IP addresses that were part of incidents from years ago, that now are just there to generate false positives all day, while the smaller dataset might be a highly curated dataset for ongoing incidents in the last two weeks. One is not just less effective, but actively detrimental.
Add another data source in the mix, let’s say we’re matching on IoCs in firewall logs, and we onboard web proxy data to hook it up to the same threat intelligence feeds. Again on paper, can sound comprehensive and effective, yet both sources are likely going to be watching the same outbound web traffic from different contexts – a great way to double your alert volume for no additional detection.
What SOC maturity actually looks like
None of this is an argument for blindness, it’s an argument for intent.
Visibility was never actually the end goal, catching and stopping attacks are. Visibility was supposed to serve that goal. Somewhere along the way collection quietly became the goal itself. When ingesting more telemetry or alerting on more data sources, security teams should be asking themselves, “If this fires, what are the chances this is actually malicious activity?”.
The next era of security operations won’t be won by seeing more. It will be won by the discipline to decide, deliberately, what is worth letting into your scope, and adopting a more strategic approach to threat detection and prevention for their clients. Successful modern SOCs that understand this are moving toward engineering focused workflows, rather than a data heavy, analyst heavy approach.
What we read this week
N-able N-central Authentication Bypass Under Active Exploitation - N-able has confirmed that attackers are exploiting a critical authentication bypass vulnerability (CVE-2026-18577) in its N-central remote monitoring and management platform. The flaw allows unauthenticated attackers to gain full administrative access to the console and reach managed endpoints. An earlier patch proved incomplete, leading to a further hotfix. CISA has added the vulnerability to its Known Exploited Vulnerabilities catalogue with a short remediation window. Managed service providers and organisations running N-central should apply the latest update (2026.3.1.7) immediately, restrict management interface exposure, enforce multi-factor authentication and hunt for anomalous activity or unexpected tunnels.
INC Ransomware Dominates Exploitation of SonicWall SMA 1000 Flaws - Researchers report that INC Ransomware has emerged as the dominant actor exploiting two critical vulnerabilities in SonicWall Secure Mobile Access (SMA) 1000 series appliances (CVE-2026-15409 and CVE-2026-15410). The flaws enable command execution and device takeover, supporting credential theft, MFA seed extraction and lateral movement into internal networks. Victims span multiple countries, including Australia. Operators should ensure patches are applied, rotate credentials, review session data and monitor for signs of prior compromise.
ChainDrop npm Worm Compromises Hundreds of Packages - A self-propagating worm dubbed ChainDrop (a variant of the Shai-Hulud family) has infected more than 400 npm packages with a combined two billion monthly downloads. The campaign began with the compromise of a maintainer’s GitHub account and spread via stolen credentials and preinstall hooks, harvesting developer, cloud and CI/CD secrets. Developers and organisations should audit dependencies, rotate credentials, check for unexpected network activity and treat affected environments as potentially compromised.
Iranian-Linked Attacks on US Water Systems Expand - Multiple US states, including Michigan and Georgia, have confirmed cyberattacks on public water systems consistent with a broader Iranian-linked campaign targeting operational technology. Attackers have modified passwords, disabled alarms and forced some utilities into manual operation. CISA continues to urge the removal of internet-exposed PLCs and stronger OT isolation. Critical infrastructure operators should prioritise segmentation, offline backups and readiness for manual control procedures.
AI Agents Take Unauthorised Actions During UK Security Evaluations - The UK AI Security Institute reported that agents powered by OpenAI and Anthropic models took 19 unsanctioned actions during cybersecurity evaluations, including attempts to deceive real people and insert malicious code into open-source projects. Anthropic’s model accounted for the majority of incidents. No real-world harm was identified, but the findings highlight risks around agentic AI containment. Organisations developing or deploying AI agents should implement stronger guardrails, monitoring and human oversight.