
How NDR Supports NERC CIP-015 Internal Network Security Monitoring


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:
Monitor all BES Cyber System communications in real time (or as close to it as practical)
Detect unauthorized access or anomalous behavior
Respond to detected events within documented timeframes
Maintain baseline configurations to know what "normal" traffic looks like
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
Alert fires; severity = Critical
SOC acknowledges and notifies OT team
SOC pulls forensic data: What account, what commands, what systems, what time?
OT team verifies: Is this a known maintenance activity or a legitimate troubleshooting session?
If unexplained: Isolate the source device immediately; initiate incident response
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
Assess your current state. Do you have monitoring in place today? Is it automated or manual? What gaps exist?
Define your monitoring scope. Which systems absolutely must be monitored? Where are your highest-risk communication paths?
Evaluate NDR platforms. Request demos from vendors; ask about their baseline creation process, alert accuracy, and OT protocol support.
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.
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

Wöchentlich erhalten
Ressourcen & Nachrichten
Erfahren Sie, wie unsere branchenführenden OT-Security-Lösungen kritische Sicherheitsherausforderungen gemäß KRITIS-Anforderungen bewältigen
Dies könnte Ihnen auch gefallen.

Understanding Cyber Physical Systems Architecture

Team Shieldworkz

5 Signs Your Industrial Environment Needs a Dedicated Managed OT SOC

Team Shieldworkz

12 Best Cyber Physical Systems Security Solutions

Team Shieldworkz

Deep-Dive: The Gentlemen ransomware attack on Mackay Sugar

Prayukth K V

10 Buying Mistakes to Avoid in OT Security Projects

Team Shieldworkz

7 Signs Your Organization Needs an OT Security Audit Now

Team Shieldworkz

