Why network security monitoring for energy and utilities starts with impact level and zone
For an energy or utility operator, the first design decision in network security monitoring is not which sensor to buy. It is where each sensor can legally and safely sit, and that answer comes from the impact classification of each BES Cyber System under CIP-002 and the Electronic Security Perimeter that CIP-005-7 requires around high and medium impact systems. Control networks often cannot take an endpoint agent, so passive sensors at zone boundaries and inside the perimeter carry most of the monitoring load. Before any tap or span is planned, confirm with your compliance lead which systems are high, medium or low impact, which assets are routable-connected, and where Interactive Remote Access terminates. Those answers define the zones you are allowed to monitor and the ones where a sensor would itself become a regulated asset.
NIS2 adds a second constraint. Energy is a high-criticality sector in Annex I of Directive (EU) 2022/2555, covering electricity, district heating and cooling, oil, gas and hydrogen, so operators in scope need monitoring evidence that matches their incident reporting duties and their operational footprint. Tool choice follows from these placement rules. Security Onion packages Suricata and Zeek with Elastic components and a console, so it is a reasonable packaging layer for sensors and search nodes, while Suricata and Zeek do the traffic analysis at the wire. Two constraints must be checked early: Security Onion is licensed under the Elastic License 2.0, which is source-available rather than OSI-approved, and the 3.x line supports only Oracle Linux 9 on x86-64 hardware. Confirm both with your procurement and platform teams before choosing sensor hardware.
A practical first step is to map every candidate sensor location to its impact level, perimeter boundary and maintenance path, then ask a partner to document how each sensor is hardened and how its data is protected inside that zone. Data collected inside the perimeter may itself need the protections that CIP-011-3 applies to BES Cyber System Information, so retention and access rules should be settled before deployment, not after.
Which energy and utility rules shape the monitoring build
This table maps the NERC CIP and NIS2 requirements that most affect where sensors go, how remote access is watched and how long monitoring data must be kept. Read each row as a design constraint, then confirm with your registered entity, regulator or compliance lead which requirements apply to your assets. DeployOpen prepares systems and evidence for assessments but does not issue audit reports or certifications.
| Requirement | Source | What it means for the build |
|---|---|---|
| CIP-002-5.1a impact classification | NERC CIP standards | Bright-line criteria sort BES Cyber Systems into high, medium and low impact. Classification decides which sensor zones and evidence set apply, so confirm the classification before placing sensors. |
| CIP-005-7 Electronic Security Perimeter | NERC CIP-005-7 | Routable-connected high and medium impact assets must sit inside an ESP. Sensors need taps or span points on perimeter crossings, and the monitoring design must show where the ESP boundary runs. |
| CIP-005-7 Interactive Remote Access | NERC CIP-005-7 | All Interactive Remote Access must pass through an Intermediate System with encryption and MFA. Monitoring should confirm that remote sessions traverse the intermediate system and alert on bypass paths. |
| CIP-013-2 vendor remote access and software integrity | NERC CIP-013-2 | Supply chain plans cover vendor incident notification, vulnerability disclosure, software integrity and coordination of vendor-initiated remote access. Vendor sessions and software updates become monitored events with retained records. |
| CIP-013-2 review cycle | NERC CIP-013-2 | Plans must be reviewed at least every 15 calendar months. Keep monitoring rules and vendor access lists under the same review cadence so evidence stays current. |
| CIP-015-1 internal network security monitoring | NERC CIP standards page | Approved by FERC on 26 June 2025 and enforceable from 1 October 2028. Plan sensor coverage inside the ESP now, and confirm retention and protection requirements for INSM data with your regulator. |
| NIS2 Annex I energy sector | Directive (EU) 2022/2555 | Energy, including electricity, district heating and cooling, oil, gas and hydrogen, is listed as a high-criticality sector. Confirm with your national authority how the directive applies to your entity and which incident reporting timelines follow. |
| Delegated Regulation (EU) 2024/1366 | Commission Delegated Regulation (EU) 2024/1366 | Sets sector-specific cybersecurity rules for cross-border electricity flows. Where interconnected operators share data or access, the monitoring design must define which telemetry crosses the boundary and who receives it. |
How sensor design differs at control centers and substations
Control centers usually host the highest impact BES Cyber Systems, so the monitoring design tends to be the most complete. A central Security Onion deployment in the Distributed model fits this environment well, with a manager node, one or more sensor nodes and one or more search nodes. The search tier carries retention and investigation load, and the architecture notes that search nodes stop indexing if they lose the manager, so the manager and its connections need the most planning attention.
- Sensor placement: Place taps or span feeds at the boundary of the Electronic Security Perimeter and on major internal switch uplinks, so that traffic between control zones is visible to the sensors.
- Protocol visibility: Zeek and Suricata should see industrial and routable protocols used between control zones, described and tuned for the specific control system vendor in use.
- Redundancy: Receiver nodes add pipeline redundancy and load balancing, which matters when a single site is the main monitoring point.
- Retention: Size search node storage for the metadata and any packet capture the program retains, and confirm the retention period with compliance staff.
- Hardware: Sensor hardware must meet at least the minimums in the Security Onion hardware docs, and capacity should be confirmed against peak traffic.
Confirm with your compliance team which BES Cyber Systems at each control center are high impact before you decide how far the sensor footprint extends.
Substations and generation sites often hold medium impact BES Cyber Systems, and they may have limited bandwidth back to the control center. Local sensors that record and summarize traffic on site are more practical than sending every packet to a central point. Depending on the site, the manager may need to run remotely, so the link between the local sensor and the manager must be designed for intermittent or narrow connectivity.
- Sensor placement: Place sensors on the routable connections that cross the perimeter of the site, and on the switch that aggregates protected devices where the site design allows it.
- Constrained links: Plan for narrow or unreliable backhaul, and confirm how the sensor buffers and forwards data when the link drops.
- Remote management: A remote manager can reduce on-site staff needs, but confirm access controls, change paths and the effect of a manager outage on the sensors.
- Hardware footprint: Confirm that the chosen sensor hardware fits the physical cabinet, power and cooling limits, and meets the minimum sensor specifications.
- Protocol scope: Confirm which protocols each site uses, since substation devices can differ widely from control center systems.
Ask the operator to walk each site with you before finalizing sensor counts, since cabinet space and link capacity often decide the design more than the standards do.
Tap and span placement decides what a sensor can see, and the choice differs at the perimeter and inside the Electronic Security Perimeter. Passive taps are generally preferred over switch spans for sensitive control networks because spans can drop packets under load and a span configuration can change. Both choices need engineering review against the operator's change control and safety rules.
- At the perimeter: Monitor traffic crossing into and out of the Electronic Security Perimeter, including remote access paths that pass through the intermediate system.
- Inside the perimeter: Monitor traffic between zones and between engineering workstations and field devices, where lateral movement would appear.
- Span risk: Span ports can drop packets at peak load, so confirm the switch capacity and whether a tap is feasible.
- Impact on operations: Passive taps avoid inserting devices into the control path, but any new cabling or port change needs an approved maintenance window.
- Coverage gaps: Document which links are not visible so the gaps are known to the SOC.
Request a written sensor placement diagram from the partner that marks each tap or span point, the zone it belongs to, and the protocols expected there.
Zeek and Suricata are most useful when they see the protocols that operators and attackers actually use. In energy environments, the mix often includes traditional industrial protocols, vendor-specific control traffic, time synchronization, remote access and standard IT protocols. Zeek can produce structured logs for many protocols, while Suricata relies on rules and signatures, so the two tools complement each other. Confirm exact parser support for each protocol in the actual environment before relying on it.
- Industrial protocols: Ask whether each protocol in use has a parser or a reliable detection approach in Zeek or Suricata, and where gaps exist.
- Time and remote access: Monitor time synchronization traffic and remote access sessions, since changes there often indicate risk.
- IT protocols: Capture DNS, authentication and file transfer traffic that crosses zones, as these support investigations.
- Encrypted traffic: Expect much of the traffic to be encrypted or proprietary, and plan metadata-based detection for those flows.
- Rule tuning: Plan for baselining in the first period, because industrial traffic is often regular and predictable and noisy rules can be tuned.
Ask the partner to produce a protocol inventory from the site's own traffic before writing any detection rules.
Which open source platforms fit energy and utility monitoring
Utility networks combine control center systems, substation equipment and vendor remote access, and each platform covers a different part of that picture. The cards below show how Security Onion, Suricata, Zeek and Wazuh divide the work, and what to confirm about protocol coverage and segmented deployment before a sensor goes into a production zone.
Security Onion as the operating platform
Security Onion packages Suricata, Zeek, Elastic components and the Security Onion Console into one deployment, so the utility runs one console for sensor health, detections and hunting. The Distributed design, with a manager, sensor nodes and search nodes, is the recommended production layout, and the manager's loss stops search node indexing. Check the Elastic License 2.0 terms with counsel before standardizing on it, and decide whether the Pro edition's OIDC single sign-on, LUKS encryption, FIPS mode and OS STIG compliance are needed for the control center.
Suricata for signature and protocol alerts
Suricata inspects traffic on substation and control center segments with signature rules, protocol detection and optional prevention modes. In an OT zone, the first decision is whether to run it in passive monitoring only, since an inline device can affect control traffic. Confirm which industrial protocols its parsers decode for the utility's fieldbus and vendor equipment, and which rule sources are approved for use inside an Electronic Security Perimeter.
Zeek for protocol metadata
Zeek records structured logs of connections and protocol transactions, which helps analysts review unusual commands, file transfers and sessions between engineering workstations and field devices without relying on signatures alone. Its BSD-style license suits a utility that wants to write its own analyzers for proprietary protocols. Confirm whether an existing Zeek analyzer covers each industrial protocol in use, and plan how much metadata the zone can store for the retention period set by the utility's CIP program.
Wazuh for host telemetry and correlation
Wazuh collects logs and host telemetry from Windows, Linux and supported servers in the control center, then correlates them with network alerts from Security Onion. This covers events that never cross the wire, such as local logins, service changes and file integrity events on historian and engineering servers. Confirm which of these hosts can run an agent without violating vendor support terms, and which hosts must be covered only through syslog forwarding from the network side.
How a utility rolls out Security Onion in phases
The sequence moves from deciding which systems matter for the grid to a monitored, documented sensor estate that feeds the SOC and supports evidence for CIP-015 readiness. Each phase produces an artifact the next one depends on.
Classify assets and impact levels first
The utility's compliance and OT leads, with the NERC CIP program owner, list BES Cyber Systems and classify them as high, medium or low impact under CIP-002-5.1a. The output is a signed inventory that states which systems and control centers fall inside the scope of monitoring. Sensor counts, placement and retention all follow from this list, so no tap is ordered until the classification is approved and the inventory is versioned.
Map zones, perimeters and tap points
The network team, working with the OT engineers, maps each Electronic Security Perimeter, the routable paths into high and medium impact assets, and the Intermediate System used for Interactive Remote Access under CIP-005-7. They then choose where passive taps or span ports can see traffic without touching control logic. The output is a zone diagram with a tap register that names each sensor location, link type and the change window needed to install it.
Plan hardware and install path
The architecture and security team sizes sensor, manager and search nodes against the published Security Onion minimums for x86-64 hardware, then decides whether each zone can reach the internet. Where it cannot, the team plans an airgap install using the ISO packages and the update path described in the airgap documentation. The output is a bill of materials, an install method per zone and a record of which rule and package updates must be carried across the gap.
Build the distributed deployment
The engineering team builds the Distributed deployment that the Security Onion architecture documentation recommends for production, with a manager node, sensor nodes in each monitored zone and search nodes for storage and queries. They test the design against the manager failure behavior described in the docs, since search nodes stop indexing if they cannot reach Redis on the manager. The output is a working pipeline with each sensor reporting to the manager and a documented recovery plan for manager outages.
Tune rules and detections in the Console
The detection engineers load the NIDS, Sigma and YARA rule sets in the Security Onion Console and tune them against the utility's own traffic. They use suppress and threshold settings for noisy NIDS rules and custom filters for Sigma rules, and they record each change with the asset it concerns. The output is a baselined rule set with a change log, so that the SOC can explain why any rule is on, off or adjusted during an audit or incident review.
Route alerts to the SOC
The SOC lead defines which Security Onion alerts become tickets, which go to the OT operations contact, and which are held for review, and confirms the escalation path to the control center. Routing should be tested with sample alerts from each sensor zone before go-live. The output is a written routing matrix with named owners and a test record showing that each alert class reaches its intended queue.
Collect evidence and plan CIP-015 readiness
The compliance lead gathers configuration exports, rule change logs, sensor inventories, access records for the Console and retention settings into one evidence folder per control area. In parallel, the team compares the design with the requirements of CIP-015-1, which FERC approved on June 26, 2025 and which becomes enforceable on October 1, 2028. The output is a readiness gap list and an evidence index. Independent auditors and NERC decide compliance; the utility's job is to show the monitoring is operating and documented.
Handling Security Onion upgrades inside regulated zones
Treat a Security Onion upgrade as a change to a monitoring system that may sit inside an Electronic Security Perimeter, not as a routine patch. The first decision is the version path. Security Onion 3.0.0, released March 31, 2026, supports only Oracle Linux 9, and 2.4 reached end of life on October 1, 2026. A control center sensor or manager still on 2.4 therefore has no supported upgrade path beyond what the vendor documents, and any OS-level change must be planned with the operating system standard your utility already uses. Confirm with Security Onion Solutions, before scheduling anything, whether each node can move in place or needs a fresh install. The architecture change matters too: for 2.4 installations on Oracle Linux 9, full packet capture moves from Stenographer to Suricata. That changes what is captured, where it is stored and how it is queried, so the change record should name the capture settings and the retention period you are carrying forward.
Schedule the work around the manager, because its outage has effects beyond the manager itself. The Security Onion architecture documentation states that when the manager goes down, search nodes stop indexing because they cannot reach Redis. For a distributed deployment with sensors in several substations, a manager window means events from those sites may queue at the sensor or go unindexed until the manager returns. Your change request should record the expected indexing gap, the sensor buffer behavior you have confirmed, and whether receiver nodes are deployed to add pipeline redundancy. Map each window to a maintenance period your operations group has already approved, and keep sensor-only changes separate from manager changes so a failed step does not blind the control center.
Use airgap mode and ISO media for updates in zones with no outbound connectivity, and make the media itself part of the change evidence. Security Onion supports airgap installs, where the ISO carries packages and NIDS, YARA and Sigma rules, and the soup update tool can update from newer ISO media. Record the ISO version and checksum, who transferred it across the boundary, and the approval that allowed it, since that transfer is often the step a CIP-013 supply chain review or an internal assessor will ask about. Test the same media on a staging sensor first, and keep the rollback path documented. Confirm with your implementation partner how rule updates are carried across the gap at the same cadence as the software, because a current platform running stale signatures is still a monitoring gap.
What auditors and regulators ask to see from network monitoring
This table maps each evidence item that assessors and regulators typically request to the regulatory driver behind it and the monitoring component that produces it. Use it to plan which logs, diagrams and change records the sensor design must generate from day one. DeployOpen prepares the evidence; independent assessors and regulators decide whether it is sufficient.
| Evidence | Regulatory driver | Component that produces it |
|---|---|---|
| Electronic Security Perimeter diagrams and asset inventory | CIP-005-7 (ESP for high and medium impact BES Cyber Systems) | Sensor placement map, tap and span records, and network asset inventory from Security Onion |
| Interactive Remote Access logs through the Intermediate System | CIP-005-7 (encryption and multi-factor authentication for all IRA) | Intermediate System logs correlated with Suricata and Zeek session records at the ESP boundary |
| Vendor remote access records and coordination evidence | CIP-013-2 (vendor incident notification and remote access coordination) | Zeek connection logs and alerts tagged by vendor source, plus the supply chain plan review record |
| Internal network security monitoring data collection scope | CIP-015-1 (INSM, enforceable from 1 October 2028 per NERC) | Sensor coverage documentation and the list of monitored segments and protocols in Security Onion |
| INSM data retention and protection controls | CIP-015-1 and CIP-011-3 (information protection) | Retention settings, access controls and encryption configuration for stored sensor data |
| NIS2 incident detection and reporting records | NIS2 Directive (EU) 2022/2555 for energy and drinking water sectors | Security Onion alert history, Wazuh and SOAR case records showing detection and reporting timestamps |
| Rule and tuning change history | CIP-013-2 and CIP-005-7 change control, plus NIS2 risk management expectations | Security Onion Console Detections audit trail of NIDS rule modifications, suppressions and threshold changes |
| Sensor coverage maps and health status | NERC CIP audit preparation and NIS2 monitoring expectations | Sensor heartbeat and health data, sensor inventory and dated network diagrams kept under change control |
How much does energy network monitoring cost and what does it need from our team?
What are the main cost drivers for network monitoring at an energy utility?
The cost is driven by how many sites need sensors, how much traffic each site carries, and how long you keep packet capture and metadata. Each site typically needs sensor hardware, taps or span access, and network changes to reach the monitored links. Storage grows with retention and link speed, so the sizing decision matters early. Ask any quote to itemize sensors and taps per site, storage sized for your retention period, tuning effort, and whether Security Onion Pro is included or quoted separately. Security Onion itself is free to download, but its license terms and any paid edition should be checked against your procurement rules.
Which costs are one-time and which recur each year?
Hardware, taps, installation and initial rule tuning are usually one-time. Storage expansion, staff time for alert triage, rule updates, operating system and platform upgrades, and any subscription or support terms recur. Security Onion Pro is sold on 1 to 5 year terms, so its renewal cycle belongs in the multi-year model. Ask the partner to separate one-time and recurring line items so your budget owner can see the annual run cost, not only the rollout price.
Can our own security team run energy network monitoring without outside help?
A small team can operate a monitoring platform once it is deployed, but the first rollout usually needs people who understand both OT networks and Security Onion. Your team will need to triage alerts, tune detections, manage sensor health and handle platform upgrades. Standalone deployments are suited to evaluation, while Distributed deployments with a manager, sensors and search nodes are the recommended production design. Ask a partner which roles they will hand over, what runbooks they will write, and how much operator training is included in scope.
How long does a rollout take and what makes it longer?
No duration is fixed here, so ask for a timeline in the written scope. The main drivers are the number of sites, access approvals for changes inside control networks, the need to schedule work during maintenance windows, hardware lead times, and how many zones must be documented. Sensor placement reviews in segmented networks take longer than IT-only deployments. A partner should show the phases, the change approvals they depend on, and the acceptance tests for each site.
Can Security Onion sensors run without internet access at our substations?
Yes, Security Onion supports full installs on networks without internet access. The ISO carries packages along with NIDS, YARA and Sigma rules, and the soup update tool can update from newer ISO media in airgap mode. You will need a process to move signed media across your boundary, plus a schedule for rule and platform updates. Confirm with the vendor and your partner how updates will be validated before they are imported into a protected zone.
How do NIS2 and NERC CIP change the scope and the work?
NIS2 places energy among sectors of high criticality, so the scope is set by the entity's obligations under national transposition. NERC CIP scope depends on how BES Cyber Systems are classified as high, medium or low impact, and on which assets sit inside an Electronic Security Perimeter. CIP-015-1 on internal network security monitoring is enforceable from 1 October 2028 according to NERC, so plan sensor coverage now if you need that capability later. Your compliance lead should confirm which entities and systems are in scope before a quote is priced.
What should we ask for in a quote for this work?
Ask the partner to state the written scope, the sites and zones covered, and the sensor and tap list per site. Request the storage sizing method, the retention period assumed, the tuning hours or workshop count, and the acceptance criteria. Ask whether Security Onion Pro is included, what support terms apply, how upgrades are handled in segmented zones, and what your staff must provide. Also ask which items are fixed scope and which would be change requests, so you can compare quotes on the same basis.
What to ask an implementation partner for utility monitoring
Start with the impact classification. Ask the partner how they map each asset to its CIP-002 impact rating before they choose a sensor location, and what written record they keep of that mapping. A sensor placed without a documented impact rating cannot be shown to cover the right BES Cyber Systems, and the mapping should also show which high and medium impact assets sit inside an Electronic Security Perimeter under CIP-005-7. Ask who signs off on the mapping on your side, how changes to the asset list are reviewed, and how a new substation or control center addition would flow into the design. Ask also how they will test a sensor inside a live ESP without disrupting operations: which passive tap or span method they propose, whether they run a change window or a staged cutover, what they do if a sensor fails, and whether they will test on a lab copy of the zone first. Confirm how Security Onion's Suricata and Zeek components are fed, and how protocol visibility is handled for the field protocols in your environment, since the partner should be able to name the parsers they expect to use and the gaps they expect to find.
Next, ask how they keep rules current in airgapped zones and how Security Onion upgrades are scheduled and tested. Security Onion supports full installs on networks without internet access, and its airgap documentation describes updating from newer ISO media with the soup tool, so ask who builds the media, how signatures and rule sets are verified before they cross the boundary, and how the chain of custody is recorded. Ask for the upgrade calendar, the test environment used before production, and the rollback plan. Confirm the current release line with the partner rather than assuming it: Security Onion 2.4 reached end of life on October 1, 2026, and 3.x runs only on Oracle Linux 9, so a site on another distribution may need a fresh install rather than an in-place upgrade. Finally, ask how they will deliver evidence for CIP-005 and CIP-015 readiness. Request a sample evidence package that shows ESP boundary diagrams, the sensor inventory and the monitoring coverage map, plus the retention and access controls applied to INSM data. Ask which parts of that package the partner prepares and which must be produced and attested by your compliance team.
How DeployOpen scopes and supports utility network monitoring
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including segmented control networks. For energy and utility network monitoring, we start from the asset inventory and the regulatory scope, then build sensors and Security Onion inside the zones the client already operates.
How we scope
- Confirm which sites, control centers and BES Cyber System zones fall inside the monitoring boundary before any hardware is ordered.
- Map tap and span points, link speeds and protocol coverage for each zone, agreed with the operations and OT teams.
- Record the written scope, deliverables and timelines in a fixed-scope agreement before work starts, with any ongoing support priced as a retainer.
How we build
- Deploy Security Onion sensors inside each segmented zone, choosing a Distributed design with manager, sensor and search nodes where production needs it.
- Tune Suricata and Zeek rules against the plant's normal traffic so alerts reflect real deviations from control system behavior.
- Test sensor placement and capture under expected peak traffic to confirm no packet loss before the monitoring goes live.
How we hand over
- Document architecture, zone boundaries, data flows, retention settings and the alert workflow the client's SOC will run.
- Deliver runbooks for rule updates, sensor maintenance and Security Onion upgrades, including airgap update steps where zones are isolated.
- Prepare the monitoring evidence and control records that the client's assessor or auditor will review, without issuing any audit opinion.
How we support
- Offer ongoing support, upgrades and continuous security testing as a retainer after handover, scoped in writing.
- Review sensor health, rule sets and alert quality on a schedule the client agrees, and adjust tuning as the network changes.
- Confirm with the client whether Security Onion Pro features such as OIDC single sign-on or FIPA-related hardening are required for their environment.
