site-logo
site-logo
site-logo

How NDR Supports NERC CIP-015 Internal Network Security Monitoring

How NDR Supports NERC CIP-015 Internal Network Security Monitoring

How NDR Supports NERC CIP-015 Internal Network Security Monitoring

NDR-OT-Security
shieldworkz-logo

Team Shieldworkz

Learn how Network Detection and Response supports NERC CIP-015 INSM requirements. Discover practical steps to monitor OT networks and strengthen grid security.

If you manage critical infrastructure-whether a power plant, water utility, or industrial facility-you've heard the compliance message loud and clear: internal network security monitoring isn't optional anymore. NERC CIP-015-1 made it a requirement for utilities connected to the bulk electric system. But here's the real challenge: traditional IT security tools weren't built for OT environments. They struggle with legacy protocols, can't baseline normal behavior in industrial networks, and create false positives that bog down already-stretched teams.

This is where Network Detection and Response (NDR) changes the game.

NDR is purpose-built for operational technology environments. It watches traffic in real time, learns what normal looks like in your specific network, and alerts you to suspicious activity without requiring signature updates or deep packet inspection of proprietary industrial protocols. For CIP-015 Internal Network Security Monitoring (INSM), NDR does more than help you pass an audit-it gives you the visibility and confidence that your critical infrastructure is genuinely protected.

In this blog, we'll walk through what NERC CIP-015 actually demands, how INSM works in practice, and exactly how NDR fills the gap between compliance requirements and operational reality. You'll also get a checklist and practical roadmap to implement a monitoring program that works.

Before we move forward, don’t forget to check out our previous blog post on Deep-Dive: The Gentlemen ransomware attack on Mackay Sugar here

What Is NERC CIP-015 and Why It Matters

NERC CIP-015-1 (version 1) is the most recent iteration of the Cyber Security – Security Management Controls standard. Released in late 2023 and effective for most utilities by 2025, it introduced more granular requirements around internal network security monitoring than its predecessor.

Here's why this matters to you:

Grid Stability Depends on OT Security The bulk electric system (BES) underpins reliable power delivery. When a BES Cyber System gets compromised-whether through a casual insider threat or a nation-state attack-the consequences ripple across entire regions. NERC CIP-015 assumes that internal threats are real and that you need continuous, technology-enabled oversight of what's happening inside your network perimeter.

INSM Is a Hard Requirement, Not a Nice-to-Have Unlike some older NERC standards that allowed manual controls, CIP-015 mandates that you deploy automated internal network security monitoring for all BES Cyber Systems and their associated Electronic Security Perimeters (ESPs). There's no checkbox-and-call-it-done approach. You need tools running 24/7.

Compliance Enforcement Has Teeth NERC CIP violations carry financial penalties (up to $40,000+ per day for some violations) and public reporting requirements. Auditors now ask specific questions: What tool are you using? How is it configured? What false positive rate are you seeing? Can you show me what you detected last month? You need answers backed by actual data, not assumptions.

Understanding Internal Network Security Monitoring (INSM) Requirements

Let's unpack what NERC CIP-015 actually expects from an INSM program.

The Official INSM Mandate

CIP-015-1 requires that you:

  1. Monitor all BES Cyber System communications in real time (or as close to it as practical)

  2. Detect unauthorized access or anomalous behavior

  3. Respond to detected events within documented timeframes

  4. Maintain baseline configurations to know what "normal" traffic looks like

  5. Log and retain evidence for incident investigation and audit review

Notice what's not in that list: specific tools, specific technologies, or a one-size-fits-all approach. NERC gives you flexibility. But that flexibility comes with responsibility-you have to design a program that actually works in your environment.

The INSM Lifecycle

A mature INSM program has four moving parts:

Phase

What It Means

Your Job

Baseline & Inventory

Know every device, user, and expected communication path in your BES network

Map your network, document "normal" traffic patterns, identify protocols and ports

Continuous Monitoring

Watch traffic 24/7 with tools that understand OT behavior

Deploy monitoring that learns and adapts to your network specifics

Alert & Triage

Recognize when something is wrong

Create alerts that don't cry wolf; tier them by severity

Response & Investigation

Act on findings and document what you found

Establish playbooks for different alert types; correlate events

The challenge for most utilities is moving from Phase 1 (we know our network) to Phase 3 (we see threats in real time) without drowning in false positives in Phase 2.

The Role of NDR in NERC CIP-015 Compliance

What NDR Does (And Why It Matters for CIP-015)

Network Detection and Response is a class of security technology that sits on your network and learns behavior. It doesn't rely on signatures or rules; instead, it builds a statistical model of what normal traffic looks like in your specific environment-accounting for your unique protocols, devices, and communication patterns.

When something deviates from that baseline, NDR flags it. That might be:

  • A device communicating on an unexpected port

  • A user account accessing systems outside normal hours or from unusual locations

  • Traffic that looks like reconnaissance or lateral movement

  • A device sending data to an IP address it has never contacted before

For NERC CIP-015, NDR is a natural fit because it:

1. Operates Inside the ESP NDR works at the network level, meaning it sees traffic crossing your Electronic Security Perimeter and can alert you to both external threats that get through your firewall AND insider threats operating within your trusted network.

2. Understands OT Without Requiring Protocol Expertise Traditional IT security tools expect HTTP, SMTP, and standard TCP/IP. OT networks run Modbus, DNP3, IEC 60870-5-104, OPC UA, and dozens of proprietary protocols. NDR doesn't need to decrypt or interpret these protocols-it learns the behavioral patterns and spots when that behavior changes.

3. Reduces Alert Fatigue A misconfigured firewall rule can generate thousands of alerts per day in an IT network. Good NDR systems are tuned to cut through noise and surface actual anomalies. You get fewer, higher-confidence alerts that your team can actually investigate.

4. Generates Audit-Ready Evidence CIP-015 auditors want to see: What did you monitor? What did you detect? What action did you take? NDR systems provide detailed logs, timelines, and forensic capabilities that make audit preparation straightforward.

Real-World Threats to OT Networks and How NDR Detects Them

Understanding what you're actually protecting against helps explain why NDR works so well for CIP-015.

Threat 1: Lateral Movement After Initial Breach

An attacker gains a foothold on a network-connected engineering workstation through phishing. From there, they begin reconnaissance-scanning for industrial control systems, mapping the network topology, looking for paths to critical systems.

How NDR catches this: NDR sees the workstation suddenly communicating with dozens of new internal IP addresses on ports it never touches under normal operations. The tool alerts on this anomalous scanning behavior, allowing your team to isolate the device before the attacker can move deeper.

Threat 2: Insider Misuse

A contractor with remote access credentials logs in outside of their normal work hours and attempts to download configuration files from a PLC using credentials that shouldn't have that permission.

How NDR catches this: NDR learns the normal pattern: this contractor always connects between 9 AM and 5 PM, Monday through Friday, from a specific IP range. The login at 2 AM triggers an anomaly alert. Additionally, the attempt to access a system outside the contractor's usual scope is flagged as a privilege escalation attempt.

Threat 3: Operational Anomalies (The Hidden Danger)

Sometimes the threat isn't malicious-it's a misconfiguration or a device behaving unexpectedly due to a firmware bug. These can cascade into outages. An HMI starts pulling data from a SCADA system at double the normal rate, overwhelming network capacity.

How NDR catches this: NDR's baseline includes not just what communicates with what, but also traffic volume, packet sizes, and timing. When the HMI's data requests suddenly increase 200%, NDR alerts-flagging this as abnormal even if it's not malicious.

Threat 4: Supply Chain Vulnerabilities

A vendor pushes an update to a device on your network. The update contains a vulnerability that enables the device to communicate outbound to unexpected destinations.

How NDR catches this: Post-update, the device begins making outbound DNS requests or HTTP connections that it never made before. NDR sees this egress behavior as anomalous and alerts your team, allowing you to investigate or roll back the update before damage occurs.

Key Capabilities NDR Brings to INSM

To actually meet CIP-015 requirements, your NDR platform should deliver these core capabilities:

1. Behavioral Baseline Creation The system learns normal traffic patterns passively over a period (typically 2-4 weeks). It builds models for device-to-device communication, user login patterns, data flow rates, and protocol-specific behaviors.

2. Real-Time Anomaly Detection Once the baseline is established, the system continuously compares live traffic against the model and flags deviations in real time or near-real time (most systems deliver alerts within minutes).

3. Protocol Awareness The NDR platform recognizes Modbus, DNP3, PROFIBUS, EtherCAT, and other industrial protocols-not by decoding them, but by learning their traffic signatures and behavior. This means you don't need to configure every protocol manually.

4. Asset Discovery & Inventory NDR automatically identifies devices on your network, their roles, and their communication patterns. This feeds directly into your baseline and helps you catch unauthorized devices or assets that shouldn't be there.

5. Threat Intelligence Integration The platform can correlate your internal findings with known IOCs (indicators of compromise) from external threat feeds, giving you context about whether the behavior you're seeing matches known attack patterns.

6. Forensic Playback When an alert fires, you need to understand what happened. Good NDR systems let you rewind to see the full communication sequence, understand the context, and answer investigator questions like "How did that data flow?" and "What was the path of lateral movement?"

7. Integration with Incident Response NDR should be able to automatically create tickets, trigger playbooks, or alert your SOC. For small facilities, this might be automated email notifications. For large utilities with existing SOCs, it's API integration with your ticketing system.

Practical Steps to Implement NDR for CIP-015

Step 1: Define Your Monitoring Scope

Start by clearly identifying what needs to be monitored:

  • All BES Cyber Systems (as defined in your NERC inventory)

  • All devices within your Electronic Security Perimeter (ESP)

  • Critical communication paths between control systems, engineering workstations, and remote access points

  • Backup systems and hot-standby equipment

Document this scope in writing. Your auditor will ask: "What did you decide to monitor and why?" Having a crisp answer saves time during assessment.

Step 2: Choose Deployment Architecture

NDR can be deployed in a few ways:

Deployment Type

Best For

Considerations

Inline (TAP/Mirror)

High-confidence, low-latency detection; switching fabric can mirror traffic to NDR appliance

Requires network engineering; some environments can't spare a tap port

Out-of-Band (SPAN/Mirror Port)

Most OT environments; no impact on production traffic; less invasive

Dependent on switch capabilities; traffic loss possible during high-volume periods

Agent-Based

Endpoint monitoring for remote users and critical workstations

Requires agent deployment and management; not all legacy devices support agents

For most utilities, out-of-band deployment on a switched network is the practical starting point. You configure your managed switches to mirror BES network traffic to the NDR sensor, and the sensor passively learns and alerts.

Step 3: Establish Your Baseline

This is non-negotiable and can't be rushed:

  • Run the NDR system in learning mode for 3-4 weeks minimum

  • During this period, document all planned maintenance, backup operations, and expected communication changes

  • Capture a "typical" operational cycle-ideally including at least one full week of normal operations

  • Mark special events (backups, firmware updates, testing) so the baseline doesn't include them as "normal"

Many teams make the mistake of rushing baseline creation. A weak baseline means high false positive rates downstream, which kills team confidence in the tool.

Step 4: Tune Alert Rules and Severity Tiers

Not all anomalies are emergencies. Build a tiered alert framework:

Alert Tier

Severity

Response Timeframe

Examples

Critical

Immediate threat to system integrity

Immediate (< 5 min)

Unauthorized privilege escalation, known malware signatures, lateral movement attempts

High

Significant deviation; requires investigation

1 hour

New device accessing PLC, user accessing system outside normal window, unusual data volumes

Medium

Notable but low immediate risk; may be operational

4-8 hours

Device contacting new external IP, minor protocol deviation, after-hours access by authorized user

Low

Informational; log for trend analysis

24 hours

New device on network (expected), minor traffic pattern shift, routine software updates

Categorize your common scenarios (backups, redundancy tests, software updates) as expected to suppress routine alerts.

Step 5: Build Response Playbooks

For each alert type, document what your team should do:

Example Playbook: Unauthorized Privilege Escalation Attempt

  1. Alert fires; severity = Critical

  2. SOC acknowledges and notifies OT team

  3. SOC pulls forensic data: What account, what commands, what systems, what time?

  4. OT team verifies: Is this a known maintenance activity or a legitimate troubleshooting session?

  5. If unexplained: Isolate the source device immediately; initiate incident response

  6. Document findings in incident log and notify compliance team

Having written playbooks means your response is consistent and auditable.

Step 6: Integrate with Your Incident Response Program

Your NDR alerts shouldn't exist in isolation. They're one part of your larger security program:

  • Map NDR alerts to your Incident Response Plan (IRP)

  • Establish handoff procedures: How does information flow from NDR to your incident response team?

  • Define escalation: When does an alert become an incident? When does it trigger a NERC CIP breach notification obligation?

  • Maintain audit logs: Every alert, every investigation, every action must be logged

Common Mistakes and How to Avoid Them

Mistake 1: Deploying NDR Without Proper Baseline Creation

Many teams turn on NDR and immediately enable all rules. Result: 10,000 alerts in the first week, and the tool gets disabled or ignored.

How to avoid it: Commit to 3-4 weeks of learning mode. Yes, it delays your "go live," but it prevents the tool from becoming noise. Use the learning period to involve OT engineers in understanding what the tool sees.

Mistake 2: Monitoring Too Narrowly

Some utilities monitor only their control room network, missing lateral movement in the operations network or engineer access points.

How to avoid it: Monitor the entire ESP. Include remote access points, engineering network segments, and backup systems. If it's in your NERC inventory, it should be monitored.

Mistake 3: Ignoring Operational Reality

An NDR alert fires on a device behavior that's actually a normal part of your maintenance routine-maybe your redundancy test triggers unexpected communication, or a firmware update causes a protocol deviation.

How to avoid it: Involve OT engineers in tuning from day one. They know what "normal" really is. Create a feedback loop: When OT explains why an alert is actually expected, update the baseline and alert rules. This is not wasted work-it's the foundation of a practical program.

Mistake 4: Setting Expectations Too High

If you position NDR as a "threat prevention" system, you'll disappoint. NDR detects and responds; it doesn't prevent. An attacker can still create an alert by attempting something malicious-they just can't do it invisibly.

How to avoid it: Frame NDR correctly: "We will see attempts faster and investigate more thoroughly." That's a realistic and valuable value proposition.

Mistake 5: Failing to Document the Program

NERC auditors want to see: What is your monitoring strategy? How did you implement it? What are you monitoring? How do you respond? Without documentation, you can't prove your program exists.

How to avoid it: As you build, document. Create an INSM Program Charter that includes scope, tools, processes, and responsibilities. Keep it updated as the program evolves.

Building a Compliance-Ready Network Security Program

NDR is a critical component, but it's not the whole program. Think of it as the "detection" piece in a larger framework.

The INSM Framework (Beyond NDR)

Component

Purpose

Overlaps with NDR?

Baseline & Inventory

Know your network

Yes-NDR auto-discovers assets

Access Control

Restrict who can connect to what

No-this is policy and firewall rules

Monitoring (NDR)

See what's happening

Yes-core function

Logging & Retention

Keep records for audit and forensics

Partial-NDR logs; you need to integrate with SIEM

Incident Response

React to findings

Partial-NDR alerts; you own the response process

Training & Awareness

Reduce insider threats

No-this is an organizational/HR function

Vendor Management

Control third-party risks

No-this is procurement and contracts

How It All Connects

Your access control policy might say "Only authorized remote session managers can connect to critical PLCs." Your NDR system learns this baseline: "RSAM device A connects to PLC B between 8 AM and 8 PM, Monday through Friday, via port 502." When a user account (not the RSAM) tries to connect to PLC B on port 502 at 11 PM, NDR flags it as anomalous. Your incident response process kicks in: Is this expected? If not, you contain the threat.

Conclusion

The Bottom Line

NERC CIP-015 demands that you monitor your internal network continuously, detect anomalies, and respond in a disciplined way. Network Detection and Response is the technology enabler that makes this possible without drowning your team in false alerts or requiring them to decode industrial protocols manually.

Implementing NDR for CIP-015 gives you:

  • Real-time visibility into all BES Cyber System communications

  • Behavioral-based detection that catches insider threats and advanced attack techniques

  • Reduced false positives because the system learns your specific environment

  • Audit-ready evidence for NERC assessments

  • A practical foundation for building a mature security program

But technology alone isn't enough. You need a clear scope, written playbooks, OT engineer involvement, and a commitment to tuning the program over time. The best INSM programs are built iteratively-learning from each detection event, refining rules, and continuously improving.

Your Next Steps

  1. Assess your current state. Do you have monitoring in place today? Is it automated or manual? What gaps exist?

  2. Define your monitoring scope. Which systems absolutely must be monitored? Where are your highest-risk communication paths?

  3. Evaluate NDR platforms. Request demos from vendors; ask about their baseline creation process, alert accuracy, and OT protocol support.

  4. Start with a pilot. Deploy NDR in a non-critical network segment first. Let your team experience the tool, see the baseline creation process, and build confidence before enterprise rollout.

  5. Document your program. Write down your INSM strategy, deployment architecture, alert tiers, and response procedures. This is your audit foundation.

Ready to strengthen your internal network security monitoring?

Shieldworkz specializes in helping utilities and critical infrastructure operators build monitoring programs that actually work in OT environments. Our NDR platform is built for industrial networks, learns OT behavior patterns automatically, and integrates with your existing incident response workflows.

Interested in learning more? Request a demo with our engineering team to see how NDR handles your specific network types and protocols.

Additional resources:

Comprehensive Guide to Network Detection and Response NDR in 2026 here
NERC CIP-015 Internal Network Security Monitoring Readiness Checklist for Electric Utilities here
OT SOC Foundational Guide here
Managed SOC Service here
OT Cyber Threat Intelligence Advisory - Middle East here
NIS2 Directive Achieving NIS2 Compliance Through IEC 62443 here
What Is Removable Media? Risks, Policies, and Industrial OT Security Solutions here
Free Removable Media Policy Template for OT and IT Teams here

threat report shieldworkz

Recibe semanalmente

Recursos y Noticias

Vea cómo nuestras soluciones de seguridad de OT líderes en la industria abordan los desafíos de seguridad críticos

También te puede interesar

BG image

Comienza ahora

Expande tu postura de seguridad CPS

Póngase en contacto con nuestros expertos en seguridad CPS para una consulta gratuita.

BG image

Comienza ahora

Expande tu postura de seguridad CPS

Póngase en contacto con nuestros expertos en seguridad CPS para una consulta gratuita.

BG image

Comienza ahora

Expande tu postura de seguridad CPS

Póngase en contacto con nuestros expertos en seguridad CPS para una consulta gratuita.