NERC-CIP OPERATIONAL PACKAGE

Evidence Library · OT VM · BES Access · Deviations · IT/OT Convergence · BES Categorization · ESP/EAP · CIP-013 · CIP-009 · CIP-015 (Forward-Looking)

Table of Contents

1. Purpose and Scope
2. Three-Lines-of-Defense Model
3. CIP Version Strategy
4. BES Cyber System Categorization Procedure
5. ESP / EAP Topology Documentation
6. NERC-CIP Evidence Library Procedure (CERG-GOV-CIP-001)
7. OT Exposure Management Procedure (CERG-PRC-VM-001)
8. BES Cyber System Access Management Overlay
9. CIP Deviation and Mitigation Plan Template (CERG-TMPL-CIP-001)
10. IT/OT Convergence Security Architecture Guideline
11. CIP-013 Supply Chain Risk Management Plan
12. CIP-009 Recovery Plan Package
13. CIP-015 INSM Implementation Annex
14. Operating Cadence and Reporting
15. Regulatory and Framework Alignment Summary
16. Document Control

1. Purpose and Scope

The OT Standard names several subordinate artifacts and obliges CERG to maintain a full NERC-CIP evidence library separately. Until this package, those named subordinates did not exist. This package assembles them: an evidence library procedure, an OT VM procedure, a BES access management procedure, a CIP deviation template, an IT/OT convergence guideline, BES categorization and ESP/EAP topology procedures, the CIP-013 supply chain plan, the CIP-009 recovery plan package, and a forward-looking treatment of CIP-015 INSM.

It applies to every BES Cyber System (Low / Medium / High Impact) and the associated Electronic Access Control / Monitoring Systems (EACMS), Physical Access Control Systems (PACS), and Protected Cyber Assets (PCAs).

Operate the Compliance, Don’t Just Document It

A binder of CIP requirements is not compliance. Compliance is the continuous evidence that the controls are operating, RTO measured, configurations baselined, access reviewed, deviations tracked, lessons learned actioned. This package is the operating manual for producing that evidence on a schedule the regulator can audit.

2. Three-Lines-of-Defense Model

CERG operates as the second line of defense for CIP controls.

The model is intentionally explicit so audit trails are clean: Operators do; CERG reviews and tracks; Audit independently assures. CERG never grades its own homework on first-line activities, and Operators are not asked to be their own auditors.

3. CIP Version Strategy

CERG operates against the latest approved version of each CIP Standard, with a documented adoption window for newly approved versions and a draft-tracking posture for proposed standards. Specifically:

• Active version baseline reviewed at every CIP filing-effective-date change.
• Migration period for newly approved CIP versions tracked as risk register entries until cutover is complete.
• Draft / proposed standards (presently including CIP-015 INSM) tracked per Section 13.

4. BES Cyber System Categorization Procedure

CIP-002 requires identification and categorization of BES Cyber Systems. CERG categorizes following Attachment 1 criteria; the procedure:

1. Inventory all BES Cyber Assets in the enterprise inventory with required metadata (function, location, criticality input from Operations).
2. Apply Attachment 1 criteria (Section 1, High Impact criteria; Section 2, Medium Impact; everything else Low).
3. Group BCAs into BES Cyber Systems along functional / physical lines per operator input.
4. Identify associated systems: EACMS, PACS, PCAs, BCSI repositories.
5. Document the rationale for each categorization, the assessor will want to see it.
6. Review annually and on material grid configuration / asset changes.

The categorization is reflected in the asset inventory and drives every subsequent CIP obligation.

5. ESP / EAP Topology Documentation

CIP-005 requires Electronic Security Perimeters (ESPs) and Electronic Access Points (EAPs). CERG maintains:

• A network diagram set showing every Medium and High Impact ESP, the EAPs defining it, and the connections crossing each EAP.
• Per-EAP documentation: device, firmware version, rule set, last reviewed, owner, evidence of inbound/outbound deny-by-default, and authentication for interactive remote access.
• Per-ESP documentation: enclosed BCS, EACMS, PACS, PCAs; supported categorization (Medium/High); evidence of monitoring (CIP-007 R4, and forthcoming CIP-015 INSM).
• Annual review (or sooner on architecture change) with evidence routed into the library (Section 6).

6. NERC-CIP Evidence Library Procedure (CERG-GOV-CIP-001)

The Evidence Library is the single, authoritative repository of CIP compliance evidence, what the auditor opens first.

6.1 Library Structure

The library is organized by CIP Standard, then by Requirement, then by Sub-requirement. Each leaf has:

6.2 Evidence Discipline

• Every CIP Requirement applicable to in-scope assets has at least one Evidence Artifact named in the library.
• Evidence is gathered through normal operations (CERG-managed scans, configuration capture, access reviews), not assembled at audit time.
• Refresh cadences are driven from this library to the operating cadence (Section 14).

6.3 Reused Evidence

CIP evidence reuses the broader CERG evidence catalog wherever possible (per CERG-GOV-CB-001 Section 8). The library cites where it lives rather than duplicating the artifact.

7. OT Exposure Management Procedure (CERG-PRC-VM-001)

The enterprise exposure management procedure (CERG-PRC-VM-001) governs IT scopes; this OT-specific procedure overlays it with OT-safe practices.

7.1 Identification

• Passive scanning is the default for live OT surfaces.
• Authenticated checks under engineering supervision in defined windows.
• Vendor advisories subscribed; advisories triaged against in-service firmware / software inventories.
• NVD / CISA ICS Advisories subscribed.
• Active scanning is permitted only under an approved scope and time window per CERG-PRC-AV-001 Section 9.

7.2 Risk Assessment and Treatment

• Vulnerabilities mapped against CIP-007 R2 patch evaluation cycle (35 calendar days from release for Medium/High Impact to evaluate; per the standard’s specifics).
• Treatment options: apply patch in next maintenance window · implement compensating control · accept via Risk Register and CIP deviation if a deviation is required (Section 9).

7.3 Patching

• Patch evaluation cadence per CIP-007 R2.
• Patch deployment per CIP-010 R1, configuration changes require baseline update, security impact analysis, and authorization.
• Patch evidence retained in the Evidence Library per CIP-007 R2.4.

7.4 Documentation

• Per the procedure in CERG-PRC-VM-001 Section 6 with OT-specific fields: applicability to BES, CIP-007 R2 timing, CIP-010 R1 change record.

8. BES Cyber System Access Management Overlay

CIP-004 R4 / R5 obligations are operationalized as an embedded BES overlay on CERG-PRC-AC-002.

8.1 Authorization

• Access to BES Cyber Systems is authorized only after the individual has met CIP-004 personnel risk assessment requirements (background check, training).
• Authorization is documented with a named approver per role.
• Reviews per CIP-004 cadence (every 15 months, plus on role change).

8.2 Provisioning and Revocation

• Provisioning of unescorted physical access to ESPs and electronic access to BCS goes through PAM-mediated workflows where supported.
• Revocation within 24 hours of termination (CIP-004 R5.1), CERG operates against 1 hour for involuntary terminations.
• BCSI access is governed under CIP-011 (information protection).

8.3 Vendor Remote Access

• Brokered through approved gateways with session recording.
• Authenticated per CIP-005 R2; monitored per CIP-005 R2.5 (interactive remote access via intermediate system).
• Vendor identities enrolled via CERG-PRC-AC-002 Section 10 and CERG-PRC-TPRM-001.

9. CIP Deviation and Mitigation Plan Template (CERG-TMPL-CIP-001)

When a CIP requirement cannot be met as written (or cannot be met for a defined window), CERG documents a deviation and mitigation plan. This is in addition to the risk register entry in CERG-PRC-RM-001.

CIP DEVIATION AND MITIGATION PLAN - DEV-CIP-YYYY-NNNN

A. DEVIATION IDENTIFICATION
   Standard / Requirement   :  (e.g., CIP-007-6 R2.2)
   Applicability            :  Low / Medium / High
   Affected BCS / EACMS / PACS / PCAs
   Discovered By            :
   Discovery Date           :
   Description              :  Specific, requirement-citing language

B. CAUSE
   Why the requirement is not met as written

C. RISK
   Risk Register ID (per [CERG-PRC-RM-001](../procedures/CERG-PRC-RM-001_Risk_Register_and_Exception_Process.md))
   Residual Risk Score
   Operator Sign-Off

D. MITIGATION
   Compensating control(s) - specific, in-place, named, evidenced
   Detection coverage uplift (if applicable)

E. PLAN TO ELIMINATE THE DEVIATION
   Steps                    :
   Owner                    :
   Target Closure           :

F. APPROVAL
   CERG NERC-CIP Compliance Manager     :
   CISO                :
   Operations               :

G. RECORD
   Library Reference        :  (where deviation lives in Section 6 library)
   Self-Report Required?    :  Y/N
   Self-Report Submitted    :  Date if applicable

Deviations Get Self-Reported When Self-Reporting Is the Right Call

CERG works with Operations and Legal to determine when a deviation is a self-reportable noncompliance under the regional entity’s self-reporting program. The deviation record above always exists; whether to self-report is a deliberate Legal / Compliance / CISO decision, not a default.

10. IT/OT Convergence Security Architecture Guideline

This embedded convergence guideline informs architecture decisions where IT systems touch OT systems. It is the V1 authoritative location for the planned standalone CERG-GL-OT-001 guideline until that reserved artifact is promoted in a future catalog amendment. It is referenced by CERG-PRC-AR-001 for any project crossing the IT/OT boundary.

10.1 Foundational Patterns

• No flat IT/OT networks. Convergence happens at named, documented EAPs.
• One-way logging out of OT, brokered control into OT. Data flows out of OT to SIEM are one-way; control / management flows into OT traverse identity, authorization, and recording controls.
• Identity-first segmentation. IT identity does not auto-translate to OT identity; OT identities are separate and governed by Section 8.
• DMZ / industrial DMZ. Where IT systems consume OT data, an industrial DMZ holds data brokers, historians, and integration services.
• Engineering-tool isolation. Engineering tools live on managed engineering workstations only; not on general-purpose corporate endpoints.

10.2 Pattern Reviews

The guideline catalogs approved IT/OT integration patterns:

• Historian-as-publisher (read-only, broker-mediated).
• Operator workstation reading OT data via DMZ.
• Vendor remote access via brokered jump.
• Cloud-hosted analytics consuming OT data via one-way export.
• IT identity using OT data in business analytics platforms.

Each pattern lists the controls, the diagrams required, and the architecture review depth.

10.3 Anti-Patterns

• Direct IT→OT VPN without brokering.
• OT-side credentials used by IT business processes.
• IT-side patching tools reaching into OT.
• Cloud agents installed directly on OT endpoints.
• File shares straddling IT and OT trust boundaries.

11. CIP-013 Supply Chain Risk Management Plan

Operationalized in coordination with CERG-PRC-TPRM-001. The CIP-013 Plan satisfies CIP-013-2 R1 and is reviewed annually (R3).

11.1 Scope

Vendor relationships involving Medium or High Impact BCS planning, design, installation, deployment, software/firmware/services, vendor remote access.

11.2 Components

11.3 Evidence

CIP-013 evidence flows from this section into the Evidence Library (Section 6).

12. CIP-009 Recovery Plan Package

Operationalized in coordination with CERG-STD-RES-001. The CIP-009 obligations:

13. CIP-015 INSM Implementation Annex

CIP-015 (Internal Network Security Monitoring) is tracked as a forward-looking obligation for Medium and High Impact BES Cyber Systems. This annex operationalizes the CIP-015 readiness overlay referenced in CB-001 §8 BES Overlay. Until CIP-015 becomes enforceable for the organization, CERG treats this annex as a readiness investment; upon applicability, it becomes an audit-asserted operational procedure.

INSM Is Not Optional for Medium/High Impact BCS

Once CIP-015 becomes enforceable, operators of Medium and High Impact BES Cyber Systems must demonstrate continuous internal network security monitoring. This annex ensures CERG is not scrambling on day one.

13.1 Scope and Applicability

13.2 Network Sensor Placement

Sensor placement follows the ESP/EAP topology documented in Section 5 and the IT/OT convergence architecture in Section 10.

Sensor Density Guidelines

• Each Medium Impact ESP: Minimum 1 sensor covering EAP ingress/egress.
• Each High Impact ESP: Minimum 2 sensors — one at EAP boundary, one for interior east-west monitoring.
• Any ESP with >50 BCA devices: Add 1 sensor per additional 50 BCAs or fraction thereof, distributed across logical segments.
• Sensor coverage evidence: Documented in the ESP/EAP topology diagram (Section 5) with sensor locations annotated.

13.3 Data Collection Requirements

Collection Integration

• All INSM data sources feed into the enterprise SIEM per CERG-STD-LM-001 Section 4.
• Where SIEM ingestion is not feasible (e.g., air-gapped OT environments), a local log collector forwards to SIEM via one-way data diode.

13.4 Alerting Rules and Detection Baseline

The following alert categories are the minimum detection baseline for Medium and High Impact BES Cyber Systems. Rules are implemented in the SIEM and maintained by the Detection Engineer per CERG-STD-LM-001 Section 6.

Alert Tuning and False-Positive Management

• All alerting rules start in test mode for 30 days post-deployment.
• After 30 days, rules are moved to active monitoring with a 14-day tuning window.
• False-positive rate >5% per rule triggers re-evaluation and rule revision.
• Tuning documentation is retained in the evidence library.

13.5 Evidence Package

CIP-015 evidence is collected and stored in the NERC-CIP Evidence Library (Section 6) under CIP-015 requirements.

13.6 Coverage Gap Analysis

A formal gap analysis is performed quarterly, comparing current INSM coverage against the CIP-015 draft requirements and CB-001 §8 BES Overlay expectations.

Gaps are documented in the risk register and tracked as deviation items per Section 9 until closure.

13.7 Integration with Existing CERG Capabilities

13.8 Readiness Activities (Pre-Applicability)

Until CIP-015 is enforceable, CERG performs the following readiness activities:

1. Map existing OT telemetry sources to expected INSM coverage objectives (Section 13.3).
2. Identify ESP / EAP monitoring gaps that would affect Medium or High Impact BES Cyber Systems.
3. Deploy minimum viable sensors at EAP ingress/egress for High Impact ESPs.
4. Implement baseline alerting rules for Critical and High alert categories (Section 13.4).
5. Route monitoring backlog items through CERG-STD-LM-001 and the risk register when coverage cannot be implemented immediately.
6. Preserve evidence of readiness decisions in the Evidence Library (Section 6).

13.9 Cutover Trigger

When CIP-015 becomes applicable, Governance: 1. Updates this annex from “readiness” to “enforceable” status. 2. Sets evidence collection cadences from “on readiness” to Section 13.5 table frequencies. 3. Activates all alerting rules from test mode to active monitoring. 4. Updates compliance calendar with enforceable evidence requirements. 5. Notifies all NERC-CIP Compliance Manager, OT Security Engineer, and Detection Engineer roles. 6. Creates CIP-015-specific evidence library entries per Section 6.

14. Operating Cadence and Reporting

15. Regulatory and Framework Alignment Summary

16. Document Control

Source: plans/CERG-PLN-CIP-001_NERC_CIP_Operational_Package.md · Download .md · View on GitHub