You Own the Detection Tools. Do You Own the Capability?
How to close the OT detection capability gap between deployed tools and provable detection coverage
Walk through most industrial security programs and you will find an impressive stack. A SIEM aggregating logs. An EDR agent on every endpoint that can run one. A network detection platform watching traffic. An OT monitoring tool purchased after the last board conversation about operational risk. Every one of them generates alerts, and someone reviews them. By any inventory of equipment, the program looks ready.
Then leadership asks a simple question: are we actually covered? The room goes quiet. The team knows the tools are there. What no one can say, with evidence rather than assumption, is what those tools actually detect.
That silence is the gap worth talking about. Owning detection tools and owning detection capability are not the same thing, and the distance between them is where real incidents live. In its OT Cybersecurity Year in Review, Dragos found that 45% of its service engagements showed a lack of the visibility needed to detect, triage, and respond inside OT networks. Many of those organizations had already bought the tools. This article is about how to tell which side of that gap you are on, starting with two questions you should be able to answer today.
Tooling Has Spread Faster Than Capability
A tool is something you buy. A capability is something you can prove. The difference sounds academic until an auditor, an insurer, or an attacker forces the issue, and then it is the only thing that matters.
The industry has spent years buying tools, and the numbers show it. The SANS 2024 ICS/OT Cybersecurity Survey found that OT-specific monitoring had climbed to 52% of organizations, up from just 33% in 2019. That is real progress. It also means nearly half of industrial operators still have no OT-specific monitoring at all, and that the half who do cannot assume the deployment did the work for them.
Capability is what happens after the purchase. It is the deliberate work of deciding what the program is responsible for catching, building the detection content that catches it, and confirming that the content fires when it should and stays quiet when it should not. None of that ships in the box. The box ships defaults, and defaults are tuned for a generic IT network, not for your plant, your protocols, or your Purdue architecture.
Why Alert Volume Gets Mistaken for Detection Coverage
The most revealing number in the field comes from CardinalOps. In its 2024 State of SIEM Detection Risk Report, after analyzing thousands of detection rules across real production environments, the firm found that enterprise SIEMs detect only 19% of the MITRE ATT&CK techniques adversaries actually use, while organizations could cover 87% of those techniques with data they are already ingesting.
The data is already in the building, and the tools are licensed and running. What is missing is the detection content that turns one into the other, and that gap is an engineering problem no additional purchase can close.
The report surfaced a related failure: nearly one in five SIEM rules are broken and will never fire, undone by misconfigured data sources or missing fields. Complexity compounds the problem, with 43% of organizations running two or more SIEMs and multiplying the seams where coverage can lapse unnoticed between platforms.
The alert queue hides the gap rather than exposing it. It is enormous, and most of it does not matter, so volume feels like coverage. Industry analyses of security operations consistently find that a large share of alerts are false positives and that many are never investigated at all. A program measured by how many alerts it produces is measuring the wrong thing. The number that matters is how many real threats it would actually catch.
The Blind Spot Where IT Rules Meet OT
Industrial reality makes the gap worse. IT-tuned rules do not understand Modbus, DNP3, or the difference between a routine register write and a sabotage command. Picture a valid login on an engineering workstation issuing a single write to a controller. To a generic rule set, it is an authenticated user sending allowed traffic on an allowed protocol, so nothing fires. To the process, it may be the opening move of an attack.
The consequences are not hypothetical. When German battery maker VARTA was hit by a cyberattack in February 2024, it shut down production at all five of its plants. Attacks that start on the IT side increasingly reach operations: Dragos reports that among the ransomware incidents it handled, 25% caused a full OT shutdown and 75% a partial one. Fortinet's 2024 State of Operational Technology report found that 31% of organizations suffered more than six OT intrusions in a year, nearly triple the 11% reported a year earlier.
The pathway is usually mundane. Dragos finds that attackers routinely break in through weak or exposed remote access, from default credentials to internet-facing RDP. The way in is rarely exotic. The reason it goes unnoticed is that nothing was built to notice it.
A stack that cannot see these moves is not a quiet stack. It is a loud one, pointed in the wrong direction.
The Two Questions That Expose Your Detection Gap
The self-test is two questions. Ask them, and insist on evidence rather than opinion.
First, what do we detect? Not which tools do we own, but which specific adversary techniques would trip an alert if they happened tonight. A capable program answers with a coverage map, not a product list. The reference standard for that map is MITRE ATT&CK, and industrial environments need both ATT&CK for Enterprise and ATT&CK for ICS, because real attacks cross from IT into OT and a single matrix sees only half the path.
Second, how well does it work? For the techniques you claim to cover, do the detections fire, how often are they right, and how fast do they surface? A capable program answers with measured fidelity and detection time. An incapable one answers with the date the tool was installed.
Most programs cannot answer either with evidence. That is a diagnosis, not a failing grade. The gap is normal, and it is closable along a clear path: map what you should cover, build the content that covers it, tune it so the alerts are trustworthy, and measure it so the coverage is provable.
The Difference Between Capability and Expense
Return to the two questions from the top. What do you detect, and how well does it work? A program that can answer both with evidence owns a capability. A program that can only list its tools owns an expense. The tools are identical in both cases. The difference is the discipline applied to them.
That discipline is the whole of what PhishCloud Detection Engineering does. We treat detection as an operational practice rather than a deployment, turning the SIEM, EDR, network, and OT monitoring you already own into coverage you can map, fidelity you can trust, and results you can show a board or a regulator. If you cannot yet answer the two questions with evidence, that is not a verdict on your team. It is simply the honest place to start.
A detection coverage review is the first measurement: it establishes what your current tools actually detect, and where the gap between visibility and protection really sits. Learn more about PhishCloud Detection Engineering HERE.
Sources: Dragos OT Cybersecurity Year in Review; SANS 2024 ICS/OT Cybersecurity Survey; CardinalOps 2024 State of SIEM Detection Risk Report; Fortinet 2024 State of Operational Technology and Cybersecurity Report; MITRE ATT&CK for ICS; Bloomberg.
Tool ownership is visible.
Detection capability is measurable.
Only one survives real incidents.
A tool is an asset entry. A capability is a tested, measured, and repeatable detection outcome against defined adversary techniques.
When content quality is weak, alert volume rises while meaningful detection remains low and confidence stays misplaced.
Authenticated traffic on allowed protocols can still represent sabotage behavior when command context and process state are ignored.
Programs that answer with mapped techniques, measured fidelity, and detection time own capability. Others own tooling expense.
The detection gap closes through engineering practice, not procurement cycles: content quality, validation rigor, and operational feedback loops.
Coverage answers breadth: which techniques are represented by tuned detections across IT and OT paths.
Fidelity answers trust: whether detections are accurate enough for operators to act decisively under pressure.
Speed answers consequence: how quickly meaningful signal reaches triage before operational impact compounds.
OT detection capability is proven by evidence, not by inventory depth.
The largest detection gaps are content and validation gaps, not tooling gaps.
The two-question test reveals whether your program owns capability or expense.