Open source SIEM for NERC CIP-007 monitoring

How an open source SIEM supports CIP-007-6 R4 monitoring

Picture a grid operator that runs a high impact BES Cyber System under CIP-007-6 R4 and cannot show, on request, a defensible record of security event monitoring. A self-hosted SIEM can collect, alert on and retain the events Part 4 requires, but the entity still owns the scoping, the review process and the evidence. The SIEM does not decide which Cyber Assets are in scope, which events need an alert beyond the minimums, or who reviews the summaries. Before any build starts, ask the implementation partner to map each Applicable System to its log sources and to name the person accountable for each review.

Part 4.1 covers successful and failed login attempts and detected malicious code at the BES Cyber System or Cyber Asset level. Part 4.2 requires alerts for at least detected malicious code and detected failure of event logging, so a silent collector counts as a finding. Part 4.3 requires retention of the Part 4.1 logs for at least the last 90 consecutive calendar days where technically feasible, and Part 4.4 requires review of a summarization or sampling of events at intervals no greater than 15 calendar days for high impact systems and their associated EACMS and PCA. Wazuh and Graylog Open both cover ingest, alerting and retention, but the review cadence and its records are procedures that the entity writes and runs.

NERC and the Regional Entities monitor compliance through Compliance Audits, Spot Checks, Self-Certifications, Self-Reports and data submittals, and there is no CIP certificate to point to. Your evidence is the set of configurations, alert records, retention settings and review sign-offs an auditor can sample. The figures on this page come from the CIP-007-6 standard and NERC's CIP status page, so confirm the current version and effective dates with NERC before you scope the work. Check the NERC CIP standards page and the standard itself at the time of your assessment.

Scoping BES Cyber Systems before choosing a platform

This sequence turns the CIP-002-5.1a impact categorization into a written scope that names which systems the SIEM must cover, which can send agent data, and where the SIEM itself sits relative to the electronic security perimeter. Its output is the input list for every platform and architecture decision that follows.

Confirm impact categories under CIP-002-5.1a
The entity's compliance lead works through the bright-line criteria in Attachment 1 of CIP-002-5.1a to sort each BES Cyber System into high, medium or low impact. Control Center assets, generation and transmission facilities are checked against the listed thresholds, and the result is a signed categorization record. Confirm with your Compliance Enforcement Authority contact or internal compliance team that the categorization matches their reading before you rely on it for scope.
Identify high impact systems and their associated assets
For each high impact BES Cyber System, list the associated Electronic Access Control or Monitoring Systems (EACMS) and Protected Cyber Assets (PCA), since CIP-007-6 Part 4.4 extends the 15-day review to those assets. The output is an inventory with a named owner for each system. Applicable Systems are set per requirement table, so confirm with your compliance team which categories of asset the Part 4 requirements apply to in your entity's case.
Map Cyber Assets that can run agents
Engineering staff check each in-scope asset against the vendor's supported operating systems and the change control rules that apply to BES Cyber Systems. Assets that can accept a Wazuh agent or similar endpoint software are marked as agent candidates. The result is a split list of agent-capable assets and assets that can only emit syslog or other network logs, which shapes collector placement in the next design step.
Document syslog-only and vendor-controlled devices
For each asset that cannot take an agent, record the log types it can produce, such as authentication events, malicious code detections and event logging failures, and the protocol it can send them over. Vendor-managed devices and systems under support contracts need a written confirmation from the vendor on what they will export. The output is a gap register that shows which Part 4.1 event types depend on network collection and which depend on vendor cooperation.
Define the logging scope against Part 4.1 and 4.2
Using the event types in Part 4.1 (successful and failed login attempts, detected malicious code) and the alerting duties in Part 4.2, the compliance and security teams decide which events each asset class must log and which of those events must generate an alert. Record the entity's determination of which security events need an alert, because the standard leaves that determination to the entity. The output is a logging matrix that the SIEM configuration will implement.
Confirm whether the SIEM sits inside the ESP
Network and security architects map where the SIEM server, indexer, collectors and any relay sit relative to the electronic security perimeter and to the devices it monitors. Each placement is recorded as inside the perimeter, outside it, or split through a controlled boundary. Because a SIEM inside the perimeter brings its own systems into CIP scope, the compliance team should confirm the classification with the Compliance Enforcement Authority contact or internal compliance team before design begins.
Approve the scope record before platform selection
The compliance lead, security operations lead and the system owners sign a scope document that lists categorized systems, associated EACMS and PCA, agent and syslog assets, the logging matrix and the SIEM placement. Items marked for confirmation are tracked to closure. The signed record is the input that platform, architecture and implementation partner evaluations are measured against, and it becomes the starting evidence set for an audit.

Mapping CIP-007-6 R4 Parts 4.1 to 4.4 to SIEM functions

This table maps each part of CIP-007-6 R4 to the SIEM function it needs, how to configure that function on Wazuh or Graylog, and the scope check to confirm before you rely on it. Read it as a worksheet: confirm the applicable systems first, then configure and evidence each row. The main takeaway is that the 15-day review and the 90-day retention depend on which systems are in scope, so scope decisions come before tool settings.

Requirement	What the function must do	How to configure on Wazuh or Graylog	Scope check
Part 4.1: Event logging	Collect and retain logs of detected successful logins, detected failed access and login attempts, and detected malicious code for the BES Cyber System or Cyber Asset	Wazuh agents on Windows and Linux hosts forward authentication and malware-related events; Graylog inputs (syslog, Beats) collect the same from devices that cannot run agents	Confirm each Cyber Asset in scope has a log source and that the source is named in the asset inventory
Part 4.2: Alerting	Generate alerts for detected malicious code and for failure of event logging, plus any other security events the entity decides need an alert	Wazuh rules for malware detections and agent or log-collection health alerts; Graylog event definitions with notifications to your SOC channel	Document which events you chose to alert on and why; the list is your decision, so keep it under change control
Part 4.3: 90-day retention	Keep Part 4.1 logs for at least 90 consecutive calendar days where technically feasible, unless CIP Exceptional Circumstances apply	Wazuh indexer retention policy set to at least 90 days of hot data; Graylog index rotation and retention sized for at least 90 days of daily ingest	Confirm the Applicable Systems for Part 4.3 and record any technical infeasibility decision with its basis
Part 4.4: Review at 15-day intervals	Review a summary or sample of logged events at intervals no greater than 15 calendar days to find undetected Cyber Security Incidents, for high impact systems and their EACMS and PCA	Scheduled Wazuh dashboard or Graylog saved-search reports that cover each 15-day window, with reviewer sign-off recorded	This review applies to high impact BES Cyber Systems and associated EACMS and PCA only; confirm impact rating under CIP-002-5.1a before scoping

Which open source platform fits which CIP environment

Wazuh fits environments where agents can run on the Cyber Assets that generate Part 4.1 events, such as Windows and Linux servers and workstations inside the electronic security perimeter. Agents report successful and failed logins, malicious code detections and log events to the Wazuh server, which applies decoders and rules, and alerts are stored in the Wazuh indexer and viewed in the Wazuh dashboard. The platform is distributed under the GNU General Public License version 2, with an exception for linking with OpenSSL, which matters for procurement reviews that ask about copyleft obligations.

Agent coverage: Confirm that the operating systems and firmware versions on each in-scope Cyber Asset are supported by agents before assuming host-level logging.
Compliance views: The dashboard includes prebuilt views for PCI DSS, GDPR, HIPAA and NIST 800-53, but no NERC CIP view is named in the supplied facts, so map CIP-007-6 Part 4 requirements to rules yourself.
Offline operation: The offline installation guide and an offline vulnerability repository support systems without internet access.
Remote management: The server manages agent configuration and upgrades, which reduces manual change on field devices.
Release cadence: The 4.14 line received several patch releases in 2026, so plan a documented patch process and confirm the current version at build time.

Confirm with the vendor and your compliance team whether agent-based collection is permitted on each in-scope system before you deploy it.

Platforms that fit CIP-007 monitoring and their limits

CIP-007-6 R4 asks for event logging, alerting, 90-day retention and a periodic review, and the platform you choose determines which of those you must build yourself. The cards below cover the three open-source options most often considered, plus the point that a SIEM does not replace vendor-side review of control-system logs.

Wazuh agents and agentless syslog

Wazuh combines agents on supported endpoints with syslog collection and periodic API probing for devices that cannot run an agent, such as firewalls. Agents cover Linux, Windows, macOS, Solaris, AIX and HP-UX, so confirm which operating systems and embedded devices in your BES Cyber System inventory fall outside that list. Offline installation is documented, which matters for networks without internet access. Confirm whether each Cyber Asset in scope can accept an agent without changing its vendor-supported configuration, because CIP-007 testing and change management rules apply to that change.

Graylog Open retention and index rotation

Graylog Open ingests syslog and GELF, routes events through streams and processing pipelines, and deletes the oldest indices under its retention settings. Those settings must be configured to keep Part 4.1 logs for at least 90 consecutive calendar days where technically feasible, and you need to prove it with retention records. Graylog Open needs MongoDB for configuration and either Data Node or self-managed OpenSearch for storage. Confirm the sizing guidance, the supported OpenSearch range for your Graylog version, and whether event definitions alone satisfy your Part 4.2 alerting list.

Security Onion network and host telemetry

Security Onion bundles Suricata, Zeek, osquery and the Elastic stack into a single platform for network monitoring and log management. It fits the Part 4.1 need to detect malicious code and suspicious network activity when sensors can see the traffic, which requires a SPAN or tap placement inside the electronic security perimeter. Confirm sensor placement is permitted by your CIP-005 design, that the Elastic License 2.0 terms suit your procurement policy, and that retention settings reach 90 consecutive days on the sensor and storage hardware you plan to deploy.

Vendor review remains your obligation

A self-hosted SIEM collects and alerts on the events you forward, but it does not replace the periodic review that CIP-007 Part 4.4 requires for high impact BES Cyber Systems and their associated EACMS and PCA. The review must summarize or sample logged events at intervals no greater than 15 calendar days, and you must be able to show who performed it and what was found. Confirm with your Compliance Enforcement Authority how the review record is kept, and confirm which vendor-side logs from control-system equipment the SIEM cannot see at all.

Evidence auditors ask for and which component produces it

This table maps each piece of evidence an auditor may request for CIP-007-6 Requirement R4 to the SIEM component that produces it and how to keep it defensible. Read it as a checklist of what to capture on day one, not as proof that any single item is sufficient, since the Compliance Enforcement Authority decides what satisfies the requirement. The main takeaway is that evidence must be dated, complete and tamper-evident, so plan retention and review records before the first audit window opens.

Evidence item	Producing component	How to keep it defensible
Event logging configuration per Cyber Asset	Wazuh agent configuration and server-managed settings, or Graylog inputs per source	Version-control agent and input configs, and export a dated inventory mapping each applicable Cyber Asset to its logging settings
Sample of successful and failed login logs	Wazuh decoders and rules on Linux and Windows agents, or Graylog streams and searches	Retain raw events with timestamps and source identifiers, and document the search queries used to pull the samples
Malicious code detection records	Wazuh alerts from file integrity and malware rules, or Suricata and Zeek alerts routed to the SIEM	Keep the original alert and its disposition, and do not edit records after the fact; note the rule version active at the time
Alert rule definitions and alert delivery records	Wazuh rule files and integration logs, or Graylog event definitions and notification history	Store rule definitions under change control with approval dates, and retain delivery logs showing who was notified and when
Log failure alert tests	Wazuh agent disconnection or silence rules, or Graylog event definitions for missing sources	Run and record scheduled test cases with dated results, including the test plan and any remediation tickets
90-day retention proof showing index or retention settings and archive	Wazuh indexer retention and snapshot policy, or Graylog index rotation and retention settings with OpenSearch or Data Node storage	Export current retention configuration and archive job logs, and confirm that the oldest retained event covers at least 90 consecutive calendar days
Dated Part 4.4 review records with summarization method	SIEM dashboards and saved searches used for the review, with the reviewer's own documented procedure	Record each review at intervals of no more than 15 calendar days, name the summarization or sampling method, and keep signed or ticketed outputs

What buyers ask about CIP-007 SIEM cost, effort and retention

What drives the cost of a self-hosted SIEM for CIP-007 logging?

Cost is driven mainly by how many events you ingest per day and how long you keep them, because storage and compute grow with both. Graylog's storage sizing rule is a useful starting point: daily ingest multiplied by retention days multiplied by 120 percent, with the message journal sized at 3 to 5 times daily ingest on SSDs. Open-source editions such as Wazuh and Graylog Open carry no license fee, so the recurring cost is infrastructure, staff time and any paid support. Ask any partner for a quote that shows the daily ingest assumption, retention period and hardware per tier, separately from the software and services.

Can our own staff run a CIP-007 SIEM without outside help?

Yes, many utilities run open-source SIEMs in-house, but the work is more than installing software. Your team must own log source onboarding, detection content, alert routing, storage capacity, upgrades and the evidence trail for each CIP-007-6 Part 4 requirement. Staff with NERC CIP compliance experience and a SIEM operator are the main skills to check. If those skills are thin, a fixed-scope implementation with a partner, followed by a retainer for upgrades and support, can cover the gap. Confirm internally who will be on call for alerts before choosing a model.

How long does a CIP-007 SIEM rollout take?

The rollout length depends on scope: the number of BES Cyber Systems, Cyber Assets and log sources in scope, whether the platform sits inside or alongside the electronic security perimeter, and how many change and test windows your change management process requires. No single duration applies across utilities. Ask for a written schedule that separates architecture and sizing, a test environment, phased onboarding by impact category, and cutover, along with the acceptance criteria for each phase.

What does the utility's own staff need to provide during the project?

Your team typically supplies the asset inventory from your CIP-002 categorization, access to the systems that generate security events, approvals for network changes and sign-off on the CIP-007 evidence model. Operations staff must also confirm which events matter for identifying Cyber Security Incidents and which need alerts. Plan for subject-matter time from OT, IT security and compliance, and agree on those named people in the written scope before work begins.

Does the SIEM have to sit inside the electronic security perimeter?

The CIP standards do not require a specific SIEM placement, but the placement decision drives what the SIEM can collect and what additional controls it needs. A SIEM inside the ESP sees BES Cyber System logs directly but must itself be protected as a system in scope, while one outside collects through controlled, one-way or tightly filtered paths. Confirm the placement with your Compliance Enforcement Authority's expectations and your own CIP-005 design, and document the reasoning. Your architecture team should decide this before sizing hardware.

How do we handle the 15-day log review required by CIP-007-6 Part 4.4?

Part 4.4 requires a review of a summary or sample of logged events at intervals of no more than 15 calendar days, aimed at finding undetected Cyber Security Incidents on high impact BES Cyber Systems and their associated EACMS and PCA. A SIEM supports this with saved searches, dashboards and scheduled summary reports that the reviewer signs off each cycle. Build the review as a recurring procedure with a named owner, a calendar, and a written record of what was reviewed and what was found. Ask any partner to show that record format before go-live.

What retention does CIP-007-6 Part 4.3 require, and how do we size for it?

Part 4.3 requires retaining the Part 4.1 logs, where technically feasible, for at least the last 90 consecutive calendar days, unless CIP Exceptional Circumstances apply. Size storage for that 90-day window plus headroom, using the daily ingest, retention and 120 percent rule for log storage. Keep in mind that the retention clock is set by the standard, so the SIEM design must also protect those logs from change and deletion. Confirm the exact retention period and any longer internal policy with your compliance lead before sizing.

What tooling alone does not satisfy

A SIEM collects and alerts on events, but CIP-007-6 R4 also depends on decisions and records that no product makes for you. The cards below cover the definitions, review evidence, exception handling, change control, access rules and upcoming standard versions that an auditor will ask about. Close each one in writing before the SIEM goes live.

Defining Cyber Security Incidents

Part 4.1 requires logs that support identifying and investigating Cyber Security Incidents, but the standard leaves the incident definition to the entity. A SIEM cannot decide which events matter. Write a documented definition that names the event types, the in-scope systems (high impact BES Cyber Systems and their associated EACMS and PCA) and the criteria that move an alert into an incident record. Test that definition against recent alerts from your own environment before an auditor does.

Documented review and summarization method

Part 4.4 requires reviewing a summarization or sampling of logged events at intervals no greater than 15 calendar days to find undetected Cyber Security Incidents. A dashboard that someone glances at does not prove that review happened. Document who performs the review, what summary or sample they use, how the sample is chosen, where findings are recorded and who approves the cadence. Keep those records in the SIEM or a ticketing system so an auditor can sample them across the audit period.

CIP Exceptional Circumstances handling

Part 4.3 requires keeping Part 4.1 logs for at least the last 90 consecutive calendar days where technically feasible, with exceptions under CIP Exceptional Circumstances. Define in writing what counts as an exceptional circumstance, who declares it, how long it lasts and what evidence records the gap. Storage limits and collector outages can both create missing logs, so confirm with your Compliance Enforcement Authority how it expects those gaps to be documented.

Change management for the SIEM

If the SIEM, its collectors or its agents fall within the scope of an in-scope BES Cyber System, changes to them are subject to the change management and configuration controls in the CIP standards. Confirm the classification first (EACMS, PCA or neither) under your CIP-002 categorization. Then treat server upgrades, rule and decoder updates and collector changes as changes with a record, a test step and a rollback plan. Wazuh 4.14 patch releases have arrived roughly every one to two months, so plan for that pace.

Access to the SIEM and its logs

Logs are only useful as evidence if people who manage the monitored systems cannot change them. Forward events off the monitored system to the SIEM, separate SIEM administrator roles from the administrators of monitored assets, and record who searches, edits or deletes alerts and indices. For vendor remote access, route sessions through an approved, monitored path with multi-factor authentication. Confirm which CIP requirement governs that path, since the vendor remote access controls in CIP-003-9 apply to low impact BES Cyber Systems.

Plan for the 2026 standard changes

Several CIP versions now carry future effective dates. CIP-007-7.1, approved in FERC Order No. 919 to accommodate virtualization, is effective 1 July 2028, so design collection for virtualized hosts with that version in view. CIP-015-1 (Internal Network Security Monitoring) is subject to enforcement from 1 October 2028, and CIP-015-2 extends monitoring to associated EACMS and PACS with an effective date of 1 October 2029. Plan sensor placement and log retention now, and confirm the schedule with your compliance team.

How DeployOpen scopes and delivers a CIP-007 SIEM

Every DeployOpen SIEM engagement starts with a written, fixed scope. Before work begins, the scope names which BES Cyber Systems, Electronic Access Control or Monitoring Systems and Protected Cyber Assets are in the monitored set, which of them are high impact and therefore subject to the Part 4.4 review, and which log sources feed each one. That boundary decides the rest of the work. Inside it, DeployOpen plans the architecture, implements the self-hosted platform and its collectors, hardens it, documents it and supports it after go-live. The platform runs in your own infrastructure, whether that is a data center, a cloud account you control or a network segment inside or alongside the electronic security perimeter. Ask the partner to show, in the scope document, where each component sits relative to the perimeter and who has administrative access to it.

DeployOpen prepares the evidence that a CIP-007-6 Compliance Audit or Spot Check may request, including configuration records for event logging, alert rules for malicious code and logging failures, retention settings for the 90 consecutive calendar day requirement, and review records for the 15 calendar day interval. Those artifacts are only useful if the entity keeps producing them, so the written deliverables should name who runs each review cycle and where the records are stored. DeployOpen does not issue audit reports, attestations or certifications. Your compliance team, your Regional Entity and the Compliance Enforcement Authority make those determinations, so confirm early which evidence format your auditors expect.

Confirm the deliverables, the support terms and the change control before signing. Ask for the list of documents the engagement produces, the acceptance criteria for each, and whether ongoing support, upgrades and continuous testing are covered by a separate retainer. Because most engagements are fixed-scope, any new log source, a second substation network or a change in impact classification after CIP-002 review is a scope change that should be priced and written down. Ask how that change control works and who in your organization approves it.

How DeployOpen delivers CIP-007 monitoring evidence

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including the networks where BES Cyber Systems run. For CIP-007 event monitoring, we scope the SIEM around the Applicable Systems you name, build the logging, alerting, retention and review workflow, and prepare the evidence your compliance team will need.

How we scope

Engagements are fixed-scope, with the systems, log sources and deliverables agreed in writing before work starts.
We confirm which BES Cyber Systems, EACMS, PACS and PCA fall under CIP-007-6 R4 with your compliance lead.
The scope names which security events are logged, which trigger alerts and who receives them.
We record the network placement of the SIEM relative to the electronic security perimeter and any boundary crossings.
Retention, storage sizing and the review cadence are written into the scope so they can be tested later.

How we build

We deploy the SIEM inside your cloud account, data center or segmented network, following your change control.
Log collection is configured for the agreed sources, including syslog from devices that cannot run agents.
We build alert rules for malicious code and for failure of event logging, and test each one with sample events.
Retention settings are configured to keep logs for at least 90 consecutive calendar days where technically feasible.
Access to the logs themselves is restricted and logged, so the monitoring system is not an unmanaged copy of your data.

How we hand over

Deliverables include architecture diagrams, configuration records, rule inventories and the test results for each alert.
We document the 15-day summarization or sampling review procedure so your staff can run it as written.
Runbooks cover backup, upgrades and recovery of the SIEM components on your own infrastructure.
Evidence packages map configured controls to CIP-007-6 Parts 4.1 to 4.4 for your compliance team to review.
We do not issue audit reports or certifications. Independent auditors and the Compliance Enforcement Authority make those determinations.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, scoped in writing.
Upgrades for Wazuh, Graylog or OpenSearch components are planned and tested before they reach production.
Security testing of the SIEM and its integrations can be included so the monitoring platform is itself assessed.
Ask any implementation partner to confirm who responds to alerts and who maintains rules after go-live.

Open source SIEM for NERC CIP-007 security event monitoring