How should utilities choose sensor placement for INSM under CIP-015?

How to decide where INSM sensors actually belong

Sensor placement for INSM should start with the monitoring question, not the hardware question: what specific risk, event, or path is each sensor intended to reveal? In practice, that means placing coverage where it can observe the behaviours that matter most, then checking whether those locations still make sense once you account for the site’s topology, traffic patterns, and operational limits.

The most defensible placements are usually those that combine business impact with visibility into likely attack paths. A sensor that sits near an important control boundary, for example, may be more useful than one placed where traffic is abundant but diagnostically dull. Utilities should also avoid assuming that one sensor layout fits every site, because the same monitoring goal can require different placements in a substation, control centre, or virtualised environment.

NERC CIP Guide is the right reference point when you need to connect INSM placement to broader CIP-015 expectations, especially where the monitoring design has to fit the site’s actual architecture and operational constraints.

What makes a placement design strong

Good INSM placement does two things at once: it covers the assets and pathways that would matter most if compromised, and it still works with the real-world engineering of the environment. That often means using a mix of impact-based priority and threat-based choke points. Impact-based priority tells you where failure would hurt most; choke points tell you where malicious activity is most likely to become visible.

That balance matters because a sensor that is only impact-driven can miss the routes an intruder would actually use, while a sensor that is only choke-point driven can over-cover low-value areas and leave important blind spots. The goal is not maximum sensor count, but maximum useful visibility for the monitoring objective. Placement should therefore be justified by the specific risk being covered, not by a generic desire to instrument everything.

At the same time, the architecture has to be observable in practice. Segmentation, routed links, mirrored traffic, virtual switches, and maintenance constraints can all change whether a sensor will see the traffic you think it will see. A good design anticipates those constraints up front instead of discovering them during validation.

NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because the underlying control logic depends on identifying where monitoring, auditability, and boundary protection are actually effective.

How to validate a proposed layout before you trust it

Validation should answer a simple question: if the event you care about happened here, would the sensor actually see enough of it to matter? That requires checking the design against normal traffic, maintenance traffic, and the paths an adversary would most likely use. A sensor can look well placed on a diagram and still fail in practice if a mirror port is incomplete, a virtual path bypasses inspection, or the site’s traffic pattern is different from what the design assumed.

Utilities should also confirm that the placement matches the operational purpose of INSM. If the intent is detection of suspicious east-west movement, the sensor has to see that movement. If the intent is boundary monitoring, the sensor must sit where boundary crossings are still meaningful. If the intent is compliance evidence, the layout must be supportable, repeatable, and documented well enough to defend during review.

NIST Cybersecurity Framework 2.0 supports this kind of validation because the design should be demonstrably tied to governance, detection, and ongoing monitoring, not just installed once and forgotten.

Risk and Threat Considerations

Poor sensor placement creates blind spots, and blind spots are where both compliance failure and real compromise become harder to detect. If the sensors do not cover the highest-risk paths, an attacker can move through the environment without generating the visibility the programme depends on. If the layout is chosen for convenience rather than coverage, the utility may believe it has monitoring in place while missing the routes that matter most.

Failure mechanism: The design misses critical traffic flows, choke points, or architecture-specific paths, so the monitoring system cannot observe the behaviour it was intended to cover.

Impact: Missed detection, weaker audit defensibility, and a monitoring gap that can persist until an incident or review exposes it.

Practitioner Guidance

What to prioritise: Start with the monitoring objective for each site, then map sensors to the small set of paths that most directly support that objective. If a proposed placement cannot be tied to a specific risk or choke point, it is usually a weak candidate.

What to verify: Confirm that the chosen location actually sees the traffic you expect under normal operations, maintenance activity, and failover conditions. Test the layout against the site’s physical and virtual topology, not just the network drawing.

Practitioner takeaway: The best INSM placement is the one that can be defended both operationally and analytically, because a sensor that is easy to deploy but weakly aligned to the site’s real traffic is unlikely to provide meaningful detection value.

Related resources from NHI Mgmt Group

• How should utilities reduce OT exposure while preparing for CIP-015-2?
• Who is accountable for access evidence when CIP-015-2 audits occur?
• Why do identity systems matter so much under DORA?
• How should security teams choose MFA factors that actually resist phishing?