What CIP-015-1 asks of internal network security monitoring
CIP-015-1 requires documented internal network security monitoring (INSM) inside the electronic security perimeter (ESP) of high impact BES Cyber Systems and of medium impact BES Cyber Systems with External Routable Connectivity, with processes to detect and evaluate anomalous activity and to retain and protect the monitoring data. The standard is organized in three requirements. R1 asks for processes that collect network data feeds, selected through a documented risk-based rationale that covers connections, devices and network communications, and then detect and evaluate anomalous activity against a network communication baseline (Parts 1.1 to 1.3). R2 asks for retention of INSM data tied to anomalous activity until the follow-up action is complete, except during CIP Exceptional Circumstances, and it does not require keeping data unrelated to anomalies. R3 asks for protection of that data against unauthorized deletion or modification, which is the control that matters most for an attacker who wants to erase evidence from a compromised device.
Enforcement is set for 1 October 2028 according to NERC's CIP standards status page, and the page also lists CIP-015-2, which extends monitoring to associated EACMS and PACS, with an effective date of 1 October 2029. Compliance is not granted by a certificate. The Compliance Enforcement Authority, a Regional Entity or NERC, judges it through audits, spot checks, self-certifications, self-reports and data submittals. Before a rollout starts, confirm with your regional entity how it will expect the rationale, baseline and retention records to be presented.
Open source sensors such as Zeek and Suricata, run through Security Onion, can supply the data feeds, detections and storage that R1 to R3 describe, but they do not make an entity compliant by themselves. The evidence an auditor reviews includes the risk-based rationale, detection events, sensor configuration, the baseline, the actions taken and the escalation path, which may run into CIP-008 incident response. Those records come from your processes, owners and change control, so the work to define them belongs on the project plan from the start.
How each CIP-015-1 requirement maps to the INSM function
This table maps each CIP-015-1 requirement part to what the INSM function must do and how to configure it inside the electronic security perimeter. Read it as a checklist for design decisions, then confirm the exact scope and evidence expectations with your Compliance Enforcement Authority and your auditors.
| Requirement | What it asks the function to do | How to configure it and what evidence to keep |
|---|---|---|
| R1 Part 1.1: Data feeds | Implement network data feeds, selected with a risk-based rationale, that monitor connections, devices and network communications | Document the risk-based rationale for each feed. Place Zeek and Suricata sensors where they see traffic crossing into and within the ESP, and keep the feed list and sensor configuration under change control |
| R1 Part 1.2: Anomaly detection | Detect anomalous network activity using the data feeds | Build a network communication baseline from observed traffic, tune Suricata rules and Zeek detections against it, and keep the baseline and detection settings as evidence |
| R1 Part 1.3: Evaluation | Evaluate detected anomalous activity to decide what further action is needed | Define triage steps and owners in Security Onion, record the decision for each event, and link escalations to the CIP-008 incident response plan where applicable |
| R2: Retention | Retain INSM data tied to anomalous activity at least until the action in support of Part 1.3 is complete, except during CIP Exceptional Circumstances | Set retention for anomaly-linked data separately from routine metadata. Confirm retention periods in Security Onion with your legal and compliance owners, since the standard sets a minimum tied to action completion |
| R2 note: Irrelevant data | Entities are not required to retain monitoring data that is not relevant to anomalous activity detected under Part 1.2 | Document the criteria that separate retained from discarded data, so an auditor can see the rule applied consistently |
| R3: Protection of INSM data | Protect collected and retained INSM data to mitigate the risk of unauthorized deletion or modification | Restrict write and delete access on manager and search nodes, log administrative changes, and store copies where a compromised sensor cannot erase them. Confirm the controls with your CIP-007 and CIP-010 owners |
| Scope: Applicable systems | Apply monitoring to networks protected by ESPs of high impact BES Cyber Systems and medium impact BES Cyber Systems with External Routable Connectivity | Confirm impact categorization under CIP-002 before sizing sensors. Map each ESP boundary to a sensor location so coverage gaps are visible |
| Implementation timing | CIP-015-1 is subject to future enforcement from 1 October 2028 (NERC CIP standards page) | Plan the rollout and evidence collection against that date, and confirm whether CIP-015-2 changes your scope before design freezes |
Where Zeek and Suricata sensors sit inside the ESP
Control centers usually hold the densest concentration of BES Cyber Systems, so they are the environment where sensor placement most affects coverage. In a typical design, sensors sit on internal segments inside the ESP, between the operator workstations, the EMS and SCADA servers, and the links toward other protected networks. Traffic is collected with network taps where the operator can accept an inline device, or with SPAN or mirror ports on managed switches where it cannot. Taps capture every frame, while SPAN ports can drop traffic under load, so the choice should be tested against peak operations. Virtualized assets matter here because Order No. 919 accommodates virtualization, so hypervisor management networks and virtual switch traffic may need to be inside the monitoring scope.
- Segment selection: Place sensors where traffic between Applicable Systems crosses an internal boundary, not only at the ESP edge.
- Tap or SPAN choice: Use taps for full fidelity on critical links and document any SPAN limits in the risk-based rationale.
- Virtual switch visibility: Confirm whether east-west traffic between virtual machines stays on the physical network where a sensor can see it.
- Sensor count and load: Ask the partner how sensors are sized for peak control center traffic and how drops are measured.
- Management network scope: Decide whether hypervisor and jump host networks are monitored as part of the baseline.
Confirm with your compliance lead and vendor how the ESP boundary and virtual networks are documented before ordering taps.
Substations are often smaller and more distributed, with fewer hosts per site but many sites across a fleet. Sensor placement usually focuses on the routed and switched links between protective relays, communication processors, human-machine interfaces and any EACMS or PCA devices inside the ESP. Because space, power and maintenance access are limited, the sensor and tap design often needs to be simpler than in a control center, and a single sensor may cover a site or a small group of sites. Remote access paths and connections back to the control center are important to watch because they are common routes into the ESP. The Security Onion documentation separates manager, sensor and search roles, so a fleet model can keep sensors at the substation while analysis happens centrally, provided the links between them are part of the design.
- Remote path coverage: Place sensors where the substation connects to the control center and to any vendor remote access route.
- Relay and communication traffic: Confirm that the protocols used between devices are visible to Zeek and Suricata, and that the sensor sees both directions.
- Power and cabinet constraints: Confirm whether the site can host a sensor with two NICs in a locked cabinet with the required power.
- Central analysis path: Decide which sensor data stays local and which is forwarded to a manager or search node.
- Consistent baselines: Use the same network communication baseline across sites so anomalies are measured the same way.
Confirm with the engineering team which substation links are inside the ESP before selecting a site design.
Generation sites mix control systems, plant historians, engineering workstations and substation-style links to the grid. The ESP boundary can be drawn differently from site to site, so the first task is confirming which Applicable Systems sit inside the perimeter and which traffic crosses into it. Sensors usually belong at the internal segments that connect the plant control network to the protected BES Cyber Systems, with taps or SPAN choices made by the physical layout of each zone. Generation sites also often run more third-party equipment and vendor-managed systems, so unexpected protocols and maintenance connections are common. Virtualized historians and engineering servers introduce the same virtual switch questions as control centers, and Order No. 919 effective dates should be checked against the systems the site plans to deploy.
- Boundary mapping: Build a diagram of ESP segments and mark every point where Applicable Systems exchange traffic.
- Vendor and maintenance links: Place sensors on paths used for vendor support, since these are frequent sources of anomalous activity.
- Protocol visibility: Test whether Zeek and Suricata parse the plant and grid protocols in use, and document any gaps.
- Zone-specific taps: Choose inline or passive taps based on what each zone allows during outages and maintenance.
- Virtualization timing: Track when virtualized assets come into scope against the Order No. 919 effective date.
Confirm the ESP boundary and the protocol inventory for each generation site with the plant engineering team before designing sensor placement.
Open source platforms that fit CIP-015 monitoring
A CIP-015 monitoring design needs sensing engines, a platform that stores and searches the data, and a few adjacent tools for alerting and threat context. The cards below separate the core stack from the optional pieces and flag the licensing and version limits that affect a production choice.
Security Onion distributed design
Security Onion is the recommended production layout when it is deployed as a distributed system with a manager node, one or more sensor nodes and one or more search nodes. Sensors sit inside each electronic security perimeter, while the manager and search nodes can be placed where the security team operates. Confirm that the manager outage behavior in the architecture docs is covered by your recovery plan, because search nodes stop indexing when they cannot reach the manager.
Zeek and Suricata as sensing engines
Zeek produces connection, device and protocol metadata that supports baselines of normal network communication, which CIP-015-1 evidence expects. Suricata provides signature-based detection and full packet capture on the same sensor. Map each engine to the risk-based data feeds you document under Part 1.1, and confirm that the protocols used inside your substations and control centers are parsed by the versions you deploy.
Elastic License 2.0 review
The Security Onion repository is licensed under the Elastic License 2.0, which is source-available rather than OSI-approved open source. Legal and procurement teams should review its terms against how the utility plans to use, modify and distribute the platform before standardizing on it. Keep Suricata (GPL-2.0) and Zeek (BSD-style) licensing in the same review, since each component carries its own terms.
Security Onion Pro controls
Security Onion Pro is a paid edition that adds OIDC single sign-on to the Console, LUKS data-at-rest encryption and FIPS mode. These features matter for protecting INSM data under R3, and FIPS mode may be required by your own cryptography policy. Ask the vendor which Pro features are included in your term, and budget for the subscription as a recurring cost alongside sensor hardware.
Platform version and operating system limits
Security Onion 2.4 reached end of life on October 1, 2026, so any deployment still on 2.4 needs a migration plan. Security Onion 3.x supports only Oracle Linux 9, and 2.4 installs on other distributions require a fresh install rather than an in-place upgrade. Confirm the operating system standard in your environment before procurement, and record the version in your CIP-015 configuration evidence.
Wazuh and MISP or Shuffle as adjacent tools
Wazuh can add host-level alerts and log correlation next to network data, and MISP or Shuffle can add threat intelligence and automated escalation. These tools are optional for CIP-015 itself, but they help with the escalation processes and incident response links the evidence examples describe. Keep them in the design only if their data handling stays inside the defined perimeter and their licenses fit your review.
Retaining and protecting INSM data without over-collecting
CIP-015-1 does not ask you to keep everything your sensors see. R2 limits retention to network activity determined to be anomalous, and requires you to keep that data at least until the action taken on it is complete under R1 Part 1.3. The standard also says you need not retain monitoring data that is not relevant to anomalous activity detected under Part 1.2. In practice, that means your Zeek logs, Suricata alerts and any full packet capture need a written retention rule that ties each data class to a detection and a closed action, not a single blanket period. Confirm with your compliance team how they want the retention end point defined for a finding that stays open for a long investigation, and document that decision in your R2 process before the first sensor goes live.
R3 is the protection requirement, and it targets the risk that an attacker or an insider deletes or alters the evidence. Start by separating roles. The Security Onion manager holds the configuration, the Elastic data and the console, so keep administrative access to it narrow, use distinct accounts for sensor maintenance and search, and log changes to detection rules such as those managed in the Console Detections interface. Review who can modify retained data and whether any path lets a sensor administrator alter indexed records. Security Onion Pro adds OIDC single sign-on to the Console, LUKS data-at-rest encryption and FIPS mode, but whether those features meet your R3 design should be confirmed against your own threat model and the version you deploy.
The architecture has a continuity risk that auditors will ask about. The Security Onion architecture documentation notes that if the manager goes down, search nodes stop indexing because they cannot reach Redis. Receiver nodes add pipeline redundancy and load balancing, but they do not remove the dependency on the manager. For CIP-015 this means a manager outage can open a gap in the record of anomalous activity during that window, which an assessor may treat as a monitoring failure. Ask your implementation partner how they design for manager availability, how sensor-side buffering behaves during an outage, and how the gap is documented and reported. Plan a test that stops the manager in a non-production environment and shows what data is lost.
What auditors ask to see as CIP-015 evidence
What evidence shows why we chose these network data feeds?
Keep a written risk-based rationale for each data feed, because CIP-015-1 Part 1.1 requires feeds selected on that basis. The rationale should name the ESP boundaries, the device and communication paths each feed covers, and why those paths were chosen over others. Sensor placement decisions made in Security Onion Distributed deployments, sensor node inventories and Suricata and Zeek interface assignments are the configuration records that back the rationale. Confirm with your compliance lead which applicable systems are in scope before you write it.
Which records prove our anomaly detection methods work?
Auditors look for detection events tied to the Part 1.2 methods, so export alerts from the component that generated them. Suricata produces NIDS alerts from its loaded rules, while Zeek logs connections, devices and protocol activity that feed baseline-driven detections. In Security Onion, the Console Detections interface shows which NIDS, Sigma and YARA rules are active and records modify, suppress and threshold changes. Keep dated exports of alerts and the rule set version in force at the time, so each event can be traced to a method.
How do we document INSM system configuration settings?
Maintain versioned configuration records for every INSM component, including the Security Onion manager, search and sensor nodes, the Suricata and Zeek settings, and the Elastic Fleet agent policies. Store them in a configuration management system with change history and approvals. Export settings from the Security Onion Console and the node configuration files, and record the software version in use, since Security Onion 3.3.0 and Suricata 8.0.7 both have dated release records. Auditors compare these settings with what the INSM actually runs on the day they check.
What network communication baseline do auditors expect us to use?
They expect a documented baseline of normal communications inside the ESP, showing which devices talk to which, over which protocols and at what typical volumes. Build it from Zeek connection and protocol logs collected over a defined period, then have engineers review and approve it. Record the period, the method, the reviewer and every later update. Without a baseline on file, an auditor cannot judge whether a detection of anomalous activity was reasonable, so treat it as a controlled document rather than a one-time export.
What records show what we did about each anomaly?
Each anomalous event determined under Part 1.2 needs a recorded evaluation under Part 1.3, with the decision and the action taken. Use a case or ticket workflow connected to your SIEM or SOAR tooling, and link each case to the originating alert ID. Record who evaluated it, the conclusion, the containment or follow-up step and the closure date. Under R2, retain the monitoring data for anomalous activity at least until the action is complete, so the case record should state when that data may be released.
How do escalations to CIP-008 incident response show up in evidence?
The evidence examples for CIP-015-1 include escalation processes that could run through the CIP-008 incident response plan. Document the criteria that move an INSM alert into an incident, the on-call path, and the handoff to the CIP-008 reporting steps. Keep the timestamps for detection, evaluation and escalation so the sequence can be reconstructed. Confirm with your CIP-008 owner which alert categories trigger escalation, since the INSM process and the incident response plan must agree.
How do we show that INSM data cannot be deleted or altered?
R3 requires documented processes that protect INSM data from unauthorized deletion or modification, so auditors ask for access controls and integrity measures on the store. Document who can administer the Elasticsearch-backed data store, how administrative access is logged, and how retention deletions run. Security Onion Pro lists LUKS data-at-rest encryption and FIPS mode as paid options, which you should evaluate against your own requirements. Confirm with your vendor and your compliance team what integrity controls your chosen architecture supports before you commit to a design.
Do we need to keep all network monitoring data for the audit?
No. The R2 note says entities are not required to retain monitoring data that is not relevant to anomalous activity detected under Part 1.2. Document the retention rule you apply, including what you keep for anomalous events, how long you keep it, and when it is released after the action completes. Tie the rule to the case records, so an auditor can see that retained data matches the anomalies that were evaluated. Confirm the retention period and storage sizing with your compliance lead and hardware team, since neither is set by the standard alone.
Which component produces each piece of CIP-015 evidence
This table maps each type of CIP-015 evidence to the component that generates it and the artifact an auditor will ask you to retain. Read it as a checklist for your evidence binder, since some artifacts come from Security Onion and others must come from your own documented processes. The main takeaway is that retention and protection procedures are not produced by any tool; you must define them in your own documentation.
| Evidence type | Producing component | Artifact to retain |
|---|---|---|
| Risk-based data feed rationale (R1 Part 1.1) | Entity planning process, informed by network architecture diagrams | Signed rationale document listing selected sensor feeds, the ESP segments they cover and the risk reasoning |
| Network communication baseline | Zeek connection, DNS and protocol logs collected over a defined period | Baseline records showing normal communication pairs, protocols and device behavior, with review dates |
| Anomalous network detection events (R1 Part 1.2) | Suricata alerts and Zeek notices, viewed in the Security Onion Console | Exported alert records with timestamps, sensor identifiers and rule or detection references |
| INSM system configuration | Security Onion manager, sensor and search node configuration | Configuration exports and change records for sensors, rule loading and data retention settings |
| Detection tuning history | Security Onion Detections interface for NIDS rule modification, suppression and thresholds | Change log showing who modified or suppressed each rule, why, and when the change was approved |
| Evaluation and actions taken (R1 Part 1.3) | Analyst triage recorded in case or ticketing systems tied to Security Onion alerts | Incident tickets showing evaluation outcome, further actions and closure evidence |
| Escalation to incident response (CIP-008 linkage) | Your incident response process and escalation contacts | Escalation records and incident response plan references tied to specific anomaly tickets |
| Retention and protection (R2, R3) | Your own written procedures, plus storage and access controls on the Security Onion data store | Documented retention periods, deletion restrictions and access logs. Define these procedures in your own documentation; no tool produces them |
What tooling alone does not satisfy in CIP-015
Zeek, Suricata and Security Onion produce the sensor data, but CIP-015-1 assigns the processes, rationale, baselines and evidence to the entity. Each card below is an obligation the entity must document and operate, whatever platform it chooses.
Documented processes for each requirement
R1, R2 and R3 each require documented processes, so a working Security Onion deployment does not meet them on its own. Write one procedure covering detection and evaluation, one for retention of anomalous-activity data, and one for protecting that data from unauthorized deletion or modification. Check that each procedure names an owner, a review cadence and the system where its evidence is kept.
Risk-based rationale for data feeds
Part 1.1 requires network data feeds selected using a risk-based rationale, and that rationale is written by the entity, not generated by the sensor tooling. Document which connections, devices and network communications each feed covers, and why the ESP boundary and the Applicable Systems justify those choices. Expect an auditor to ask why a segment is not monitored, so record that reasoning too.
Network communication baseline definition
Detecting anomalous activity under Part 1.2 requires a baseline of normal communication, and the platform only compares traffic against the baseline you define. Decide which hosts, protocols and conversations are expected, how the baseline is approved, and when it is refreshed after maintenance or device changes. Keep the baseline version with the detection records, since it appears in the evidence examples.
Escalation path to CIP-008
Part 1.3 requires evaluation of anomalous activity to decide further action, and escalation can run into the CIP-008 incident response plan. Define who triages an alert in Security Onion, the threshold for declaring an incident, and the handoff to the reportable incident process. Test the path with a tabletop exercise so the handoff is documented before a real event.
CIP Exceptional Circumstances handling
R2 and R3 both allow an exception during CIP Exceptional Circumstances, so the procedure must say what changes and who can declare it. Confirm with your compliance team how the declaration is recorded, how the exception ends, and whether retention and protection controls still run during the exception. Do not assume the sensor configuration pauses automatically.
License and support posture
Security Onion is licensed under the Elastic License 2.0, which is source-available rather than OSI-approved, and its Pro edition adds features such as OIDC single sign-on, LUKS encryption and FIPS mode on a paid term. Confirm with your legal team that the license terms fit your deployment, and confirm in writing which support and patch commitments apply to the version you run. Track the end-of-life dates for each release line.
Licensing and support choices for regulated operators
Before you commit to a Security Onion design for CIP-015 monitoring, decide how the platform's license and support model will fit your procurement and change control rules. Security Onion is licensed under the Elastic License 2.0 (ELv2), which is a source-available license rather than an OSI-approved open source license. The code is public and can be reviewed, but the terms differ from the GPL-2.0 license of Suricata and the BSD-style license of Zeek, and your legal team should read the ELv2 terms against your intended use before deployment. The engines underneath are permissively or copyleft licensed with no commercial-use restriction on the engine itself, so the license question sits mainly with the Security Onion distribution and console.
*Security Onion Pro* is a paid edition sold on 1 to 5 year terms. It adds professional support, OIDC single sign-on to the Console, LUKS data-at-rest encryption, FIPS mode and OS STIG compliance, which are features many utilities will weigh against their own hardening baseline. Confirm with your procurement team which support obligations you need in writing: response times, severity definitions, upgrade assistance for the Security Onion 3.x line, and what happens to support when a release reaches end of life, as happened with Security Onion 2.4 on October 1, 2026. Ask the vendor and your partner to state these terms in the quote so they can be compared with the scope of work.
If secrets for the monitoring stack, such as sensor credentials or API tokens, are managed centrally, note that HashiCorp Vault version 1.15.0 and later is licensed under the Business Source License 1.1, which is not an OSI-approved open source license. OpenBao, licensed under MPL-2.0, is an alternative that your architecture team can evaluate against the same CIP-015 retention and protection requirements. Whichever tool you choose, document the license and support position in your procurement file so it can be reviewed alongside the INSM system configuration evidence.
Questions utilities ask before building CIP-015 monitoring
What drives the cost of CIP-015 network monitoring with open source tools?
The cost is driven mostly by labor and sensor infrastructure, not by the open source software itself. The main one-time components are sensor hardware and network taps or spans for each monitored ESP, storage sized for metadata and any packet capture, and engineering time for design, deployment and baselining. The main recurring components are analyst time for alert triage, rule and detection tuning, storage growth, and any support or upgrade retainer. Cost rises with the number of ESPs, the link speeds and the retention period. If you use Security Onion Pro, its subscription is an additional recurring license on 1 to 5 year terms. In a quote, ask for each sensor site listed separately, storage assumptions, who performs baselining, and who owns tuning after go-live.
How long does a CIP-015 monitoring rollout take?
The duration depends on how many ESPs and sensor sites are in scope, how much of the network is already documented, and how quickly change windows open in production. No duration is set by the standard itself, so treat any timeline as something to agree in writing. Enforcement for CIP-015-1 is subject to future enforcement from 1 October 2028 (per NERC's CIP standards page), which gives planning time, but the work includes documenting risk-based data feed selection, building a communication baseline, and establishing escalation paths before the first detections are meaningful. Ask for a phased plan with milestones per site, and for the dependencies on outage windows and vendor access.
What does our team need to supply before a monitoring engagement starts?
Expect to provide the material that defines your ESPs and systems in scope, because the data feed rationale under CIP-015-1 Part 1.1 depends on it. The core inputs are an asset list tied to your BES Cyber System categorization, current network diagrams showing ESP boundaries, switch and firewall configurations, and documented access paths for sensors. You also need named staff: an operations contact for change windows, a network engineer who can provide span or tap access, a compliance owner who will review evidence, and an incident response contact for escalation under CIP-008. Confirm early who owns the risk-based rationale document, since it becomes audit evidence.
Can our own staff build and run CIP-015 monitoring without a partner?
Yes, a utility can build and operate it in house if it has engineers who can run Linux, configure Suricata and Zeek, and maintain a Security Onion deployment, plus enough analyst capacity to triage alerts. Security Onion supports a Distributed design for production, with a manager, sensor and search nodes, which adds operational work to keep those roles healthy. The harder parts are usually the evidence and the change control: documenting baselines, retaining INSM data under R2, and protecting it under R3. A partner can plan, implement, harden, document and support the deployment inside your infrastructure, under a fixed-scope written agreement. Compare the internal effort against that scope before deciding.
How are Security Onion upgrades handled inside an ESP?
Upgrades inside an ESP are a change management task, and they should be planned as one. Security Onion 2.4 reached end of life on October 1, 2026, and 2.3 reached end of life on April 6, 2024, so older deployments may need a path forward first. Security Onion 3.0.0 supports only Oracle Linux 9 and replaced Stenographer with Suricata for full packet capture, so a move from 2.4 to 3 on Oracle Linux 9 is possible, while other distributions need a fresh install. Enclosed or air-gapped ESPs use the ISO and the soup update tool from newer media. Ask the implementer how they test upgrades in a non-production copy, how they capture rollback points, and how the change is recorded as CIP-010 evidence.
Where does the INSM data live, and who can delete it?
INSM data is stored on the sensor and search nodes you deploy, so its location and access are your design decisions. R3 requires documented processes to protect monitoring data against unauthorized deletion or modification, and R2 requires retention of data tied to anomalous activity until the related action is complete. Plan separate administrative roles for the monitoring platform, restrict deletion rights, and log administrative actions. Security Onion Pro adds LUKS data-at-rest encryption and FIPS mode as paid options, which may matter to your data protection requirements. Confirm with your compliance owner which controls satisfy R3 before the design is frozen.
What hardware does a Security Onion sensor need in a substation or control center?
Security Onion supports only x86-64 processors, and the published minimums depend on the node role. A sensor needs at least 4 cores, 12 GB RAM and 2 NICs, a manager or search node needs at least 4 cores and 16 GB RAM, and a standalone node needs at least 4 cores, 24 GB RAM, 200 GB storage and 2 NICs. These are minimums, not sizing for your traffic. Actual sizing depends on link speed, the number of data feeds, packet capture depth and retention, so ask the implementer for a sizing calculation tied to your traffic measurements. Also confirm the enclosure, power and environmental conditions for each site, since those are often outside the software vendor's scope.
How DeployOpen scopes a CIP-015 monitoring engagement
A CIP-015 monitoring engagement starts with a written, fixed scope that names the systems in scope and the Applicable Systems they protect. Before any sensor is ordered, the scope should state which Electronic Security Perimeters contain high impact BES Cyber Systems or medium impact BES Cyber Systems with External Routable Connectivity, because those are the only networks CIP-015-1 R1 reaches. DeployOpen agrees the scope, deliverables and timeline in writing before work begins. The deliverables we typically scope for this kind of work include a sensor placement design with a documented risk-based rationale for each network data feed (the rationale is one of the evidence items the standard lists), a Security Onion configuration baseline for Suricata and Zeek, the network communication baseline used to detect anomalies, retention and protection settings for INSM data, and runbooks that cover triage, evaluation and escalation to the CIP-008 incident response plan. Each deliverable should map to a requirement part so the reader can see what is covered and what is not.
The scope also needs a decision on who owns each control after handover. Your compliance lead will own the evidence set, your operations team will own the sensors and detection rules, and your CIP-008 owner will own escalation. DeployOpen prepares systems, controls and evidence for compliance assessments, but we do not issue audit reports, attestations or certifications. Compliance is monitored by the Compliance Enforcement Authority through Compliance Audits, Spot Checks, Self-Certifications and other mechanisms, so the scope should ask for evidence in the form an auditor will sample, not only a configuration export. Confirm with your Regional Entity which evidence formats it accepts before the evidence procedures are written.
Because CIP-015-1 is subject to future enforcement from 1 October 2028 and CIP-015-2 extends monitoring to associated EACMS and PACS with an effective date of 1 October 2029, many organizations will want a retainer after the initial build. A retainer can cover Security Onion upgrades, rule and baseline tuning, periodic evidence refreshes and continuous testing of the monitoring coverage. Ask for the upgrade path explicitly in the proposal, since Security Onion 2.4 reached end of life on October 1, 2026, and the 3.x line runs only on Oracle Linux 9. A quote should separate one-time build work from recurring retainer work so you can see what continues after go-live.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source monitoring inside your own infrastructure, including the Security Onion sensors that feed CIP-015-1 internal network security monitoring. Each engagement starts with a written scope that ties sensor placement, data retention and evidence to the requirements that apply to your BES Cyber Systems. Compliance assessments are run by the Compliance Enforcement Authority, and DeployOpen prepares the systems and evidence for them.
How we scope
- Confirm which high and medium impact BES Cyber Systems and ESPs fall under R1 with your CIP-002 categorization.
- Document the risk-based rationale for each network data feed, mapped to Part 1.1 and your baseline of expected traffic.
- Agree in writing which Security Onion deployment type, sensor count and retention periods the engagement covers.
How we build
- Install Security Onion sensors inside each ESP with Zeek and Suricata collection, sized to the hardware minimums published for each node role.
- Build detection content and tuning for anomalous network activity, and record the network communication baseline used to detect deviations.
- Configure retention and access controls for INSM data so it can be kept until anomalous activity is resolved and protected against unauthorized change.
How we hand over
- Deliver configuration baselines, data feed rationale and INSM system settings in documentation your compliance team can present as evidence.
- Document escalation paths from detection to evaluation and action, including links to your CIP-008 incident response plan.
- Run a joint walkthrough of alert handling, retention procedures and the evidence set before the engagement closes.
How we support
- Offer ongoing support, upgrades and continuous testing under a retainer, with scope agreed in writing.
- Plan Security Onion upgrades around your change windows, including airgap update procedures where networks are isolated.
- Review detection tuning and evidence sets on a recurring schedule as the CIP-015 enforcement date and any CIP-015-2 changes approach.
