NERC CIP‑015 in Practice #3: Sensor Placement and Data Feeds

This post is part of a blog series recapping highlights from our webinar series of the same name, where industry experts share their knowledge and field lessons from utilities building internal network security monitoring (INSM) programs. In the third episode of this series, we focused on one of the most practical and most debated topics in INSM implementation: sensor placement and network data feeds. I was joined by two experts on the subject: Will Edwards, CISSP, PE, Head of Cyber Services at Schweitzer Engineering Laboratories, and Nicholas Janouskovec, Global Cybersecurity Product Marketing Manager at Emerson.

As utilities move from planning to executing INSM under NERC CIP‑015, one question comes up consistently: Where should I monitor, and what data should I be collecting?

In brief: there is no single “right” design, but there are defensible strategies grounded in risk, operations and regulatory intent. Here are key considerations to guide your decisions.

Why Sensor Placement Matters Under NERC CIP‑015

This topic falls under the first CIP‑015‑1 requirement, which calls for risk-driven network data feed collection. The expectation is clear, but intentionally non‑prescriptive:

Requirement R1, Part 1.1: Identify network data collection locations and methods, based on the network security risk(s), to monitor network activity including connections, devices, and network communications.

That flexibility is both a benefit and a challenge. Utilities are not being told exactly where to place sensors or which data sources to ingest. Instead, they are expected to:

1. Define a monitoring strategy
2. Document the reasoning
3. Apply it consistently
4. Gather evidence of compliance
5. Be able to defend it during an audit

Weighing Common Data Collection Strategies for NERC CIP-015

Across the utilities we work with, three main approaches show up again and again.

1. “Collect It All” (with Limits)

Especially in control centers, many organizations start with a broad collection strategy, placing sensors at aggregation points and collecting as much data as feasible.

In practice, “collect it all” quickly turns into “collect it all… except low‑value data.”
Examples often filtered out include:

• Encrypted backups with limited security value
• High‑volume video or camera traffic
• Redundant broadcast or multicast data

This approach can simplify initial decisions but still requires you to document your rationale.

2. Impact‑based Sensor Placement

Impact‑based strategies focus monitoring where operational consequences are highest. Most utilities already have a starting point for this, using  CIP-002 impact ratings.

Common high‑priority areas include:

• Engineering and administrative workstations
• SCADA/EMS servers and operator workstations
• Jump hosts and other Electronic Access Control and Monitoring Systems (EACMS)
• Core infrastructure supporting BES Cyber Systems

It’s important to understand that impact is not just about compliance classification. Especially in power generation, we see some low‑impact assets that can still create high operational or cascading risk when viewed in aggregate.

3. Threat‑based Sensor Placement

Threat‑based strategies place sensors along realistic OT attack paths, informed by how adversaries actually operate. Instead of asking “what’s most critical?”, this approach asks:

• Where would initial access occur?
• Where does lateral movement happen?
• Where could attackers execute changes or cause impact?

Typical choke points include:

• IT-OT access paths
• Core switches handling east‑west traffic
• Engineering workstations where logic or firmware changes occur
• SCADA and control servers tied directly to BES impact

Relying solely on past attacks comes with obvious risk: the past doesn’t always predict the future. Threat models must evolve, because attackers adapt and often abuse legitimate tools and credentials rather than obvious exploits.

Look no further than the attack on medical technology giant Stryker last month. The Iran-linked hacktivist group Handala used a legitimate admin command to wipe data on more than 200,000 devices enrolled in Microsoft Intune, causing a global shutdown of Stryker operations. Up until then, nobody had thought about using Intune’s remote wipe feature at scale as part of an attack.

In reality, most mature programs blend impact‑based and threat‑based approaches.

Defining the “What”: INSM Data Feeds

Selecting what data feeds to monitor comes with similar nuances. CIP‑015 refers to high‑value data feeds, not just packet captures (PCAPs) or traffic feeds. That distinction matters. A good example is human-to-machine communications, which are commonly encrypted. If somebody is logging into an automation controller and adding a user, that traffic may not show up very clearly in your monitoring solution. But if you enhance it with the logs from that device, you clearly see that a user was added at a precise moment. Capturing those logs enables detections that wire traffic alone can’t provide.

Common data feed types include:

• Network traffic capture (PCAP): Highest fidelity for investigations and audit evidence
• Network flow metadata: Scalable visibility with lower overhead
• Log data: Granular data from firewalls, switches, authentication systems, controllers and endpoints that can enrich and corollate

Full traffic visibility down to the payload level is still the gold standard and remains critical for investigations. Logs often reveal user actions, configuration changes, and encrypted activity that packet inspection alone can’t show. Metadata can provide statistical overview at scale but does not usually provide the granularity by itself to meet program requirements. The strongest programs intentionally layer data sources to build a defensible monitoring picture. Bottom line: if it’s not in the data, it didn’t happen.

Defining the “How”: Collection Mechanisms

How data is collected matters just as much as what is collected. Common approaches include:

• Network TAPs and SPAN/RSPAN/ERSPAN
• Flow exports such as NetFlow, sFlow, and IPFIX
• Software‑defined networking (SDN) telemetry
• Endpoint‑based collection, including virtualized and container environments
• Integrations with SIEMs, asset inventories and vendor platforms

Again, there is no universal sensor or sensor approach. The main thing is to match the collection method to the environment. Legacy substations, modern control centers and distributed generation sites often require very different approaches.

Benefits of Software-defined Networking for Data Collection

Especially in older power generation facilities, on the fossil side, many of those networks have existed for a long time. Creating or adding extra runs for port mirroring adds time and expense. Alternative approaches like SDN can be really beneficial.

SEL is a leader with SDN for utilities, which takes a deny-by-default approach to all connected devices and traffic. From that starting point an entity can software-define what traffic to capture and how to manage specific device-to-device or human-to-device communications. In a generation facility, you’re looking at switch gear, process control and various distributed aspects of a network. From a sensor placement perspective, you may have 20 to 30 places where you want to grab data or traffic. With SDN, you can essentially bubble up “umbilical cords” to one switch or a set of switches and aggregate that traffic into a centralized sensor. That approach can be both economical and space saving, especially for distributed environments.

Sensor Placement Reality Check: Walk It Down

When you’re thinking through sensor placement, in engineering terms, the most important step is the walkdown.  

On paper, sensor placement often looks clean and logical. In reality:

• Power may be unavailable
• Switch ports may already be consumed
• Cable runs may be impractical
• Bandwidth constraints may surface late
• Older plants may not resemble current diagrams

Large programs frequently discover that a non‑trivial percentage of sites require remediation before monitoring can be deployed. You’ve got to physically walk it down and see for yourself what needs to be done and allow ample time to do it.

This is not a failure, it’s normal. But it reinforces why timelines must account for real‑world constraints.

Rationale Drives the Program

Under NERC CIP-015, regulated entities must implement network data feeds using a documented, risk‑based rationale that explains what is monitored — both the how and why.

A defensible INSM strategy requires six things:

1. A defined rationale for data collection
2. A clearly articulated collection strategy
3. Sensor placement aligned to each environment
4. Written justification tied directly to Requirement 1.1  
5. Evidence to support policy alignment  
6. Periodic reassessment (at least annually, and whenever the environment changes)

CIP-015 INSM is not a one‑time design exercise. It’s a living program that must evolve as threats, architectures and regulatory expectations change. NERC intentionally avoided prescribing a single way to implement INSM for these reasons. Utilities differ too much in size, architecture, maturity and risk profile for a one‑size‑fits‑all solution.

What matters is not whether two utilities design identical monitoring architectures, but whether each can clearly explain and defend its decisions.

The organizations that will be most successful under CIP‑015 are the ones that:

• Start early
• Design intentionally
• Document relentlessly
• Revisit assumptions often

If you’re still deciding where to begin, the message from the field is clear: start with the “why,” and let that guide the “where” and the “how.”

This article scratches the surface of what my colleagues from SEL and Emerson and I shared in this episode. If you haven’t already, I encourage you to watch the full replay and register for the remaining episodes in the series. If you’d like to discuss how these lessons apply to your specific environment, please reach out.

‍