Building Detection Use Cases Around Real Threats

A detection use case is only valuable if it is built around a specific, credible threat scenario -- not a generic 'detect malware' aspiration that nobody can actually validate or tune. The most effective OT detection programs work backward from realistic attack scenarios, often grounded in frameworks like MITRE ATT&CK for ICS, rather than forward from whatever data happens to be easiest to collect. A well-formed use case names the threat scenario explicitly -- for example, 'unauthorized engineering workstation used to push a configuration change to a PLC outside an approved maintenance window' -- and then defines exactly what data source would reveal it (engineering workstation logs, PLC command logs, change management system records), what the detection logic actually looks for, what a true positive looks like versus a false positive, and what the response action should be if it fires. Building use cases this way forces a useful discipline: if you cannot name the data source that would reveal the scenario, you do not actually have detection coverage for it, no matter what your security architecture diagram claims. This is one of the most common gaps auditors find -- a control that looks complete on paper but has no corresponding, tested detection logic behind it. Prioritization matters as much as construction: a small number of high-confidence use cases tied to your organization's most consequential threat scenarios (informed by your risk register, not a generic industry list) will deliver more real security value than a large number of shallow, low-confidence rules that mostly generate noise.