This post is part of a blog series recapping highlights from our webinar series, where industry experts share their knowledge and field lessons from utilities building internal network security monitoring (INSM) programs.
In the sixth episode, we tackled the topic that NERC CIP programs ultimately live and breathe by: the evidence you generate, and how you manage it across its lifecycle. I come at this from a utilities background. I’ve built and run NERC CIP programs, and I’ve sat on the consulting side running mock audits and advising asset owners. For this episode I was joined by Jeff Foley, Business Development Manager and Chief Technology Evangelist for cybersecurity at Siemens, who helps critical-infrastructure operators build standards-based security programs around the world.
At Audit, Your INSM Evidence Is the Deliverable
Here’s the uncomfortable truth that sets NERC CIP apart from a lot of what we do day to day: you can have the best program in the world and be doing everything right, but unless you can prove you did something, it doesn’t matter. If you can’t show the auditor you did it, you’re looking at an area of concern or a finding.
NERC CIP-015 is objective-based. Just as you get to write your program, you also get to decide what evidence you will collect to demonstrate compliance. This should include evidence that you’re doing what you wrote in your INSM processes. The standard and the technical rationale provide some guidance, but it’s not prescriptive.
To complicate matters, NERC CIP-015 evidence is unusually diverse. Compare it to the CIP-004 training requirements, where the evidence package is fairly standardized; with INSM, the artifacts range from policies and processes to data-feed configurations to detection events to retention reports, all driven by the program and INSM solution.
More than most NERC CIP standards, INSM is a data-management standard.
Breaking Down the Evidence for Each NERC CIP-015-1 Requirement
Given the diversity in the evidence requirements, let’s break down what should be considered under each requirement, including common pitfalls and evidence.
R1 One or more documented process(es)
Providing copies of documented CIP-015 process(es) is a standard part of a NERC CIP evidence submission. Providing evidence of the implementation of the process(es) is where entities may face greater challenges. This is best done under each requirement, with the overall process versioning, approval and adoption process being documented. This may include having SMEs and leadership sign off on when the processes are implemented.
Common Evidence:
- Approved NERC CIP-015 process(s) and policy
R1 1.1 Network data feed(s) and risk-based rationale
Documenting where network data feeds are being collected and why is the key to meeting R1 1.1 requirements. Often, a picture is worth 1000 words; in this case, network diagrams that include logical network layouts, communication flows, and sensor placement diagrams are very helpful. Documenting the reasoning, including the risk-based rationale, can be more difficult and can expose entities to compliance risk. A decision flow chart and clear rationale are recommended when documenting the process. If any traffic filtering is being done, the decision and rationale should also be included. For example, backup traffic is often filtered out because it has low security value and is often encrypted.
Common Evidence:
- Logical network diagram
- Communication flow diagram
- Logical network sensor diagram
- Justification of network feed locations
- Justification of risk-based rationale (documented decision flow)
- Network collection point settings (tap, switch, packet broker configurations)
R1 1.2 Method(s) to detect anomalous network activity
To detect anomalous network activity, you first need to define what it is. Then you need to document how you are going to detect it. Are you going to use baseline, signatures, behavioral detection, or a combination of multiple methods? Much of this may be part of your CIP-015 INSM program documents defined in R1, but 1.2 will require evidence of the configuration that enables network anomaly detection, as well as the detected anomaly events.
Common Evidence
- Define anomalous network activity
- Document anomalous network detection method(s)
- Network baseline (if applicable)
- Anomaly detection rules
- Detected anomalies
- Alert handling logic
- INSM system settings
R1 1.3 Method(s) to evaluate anomalous network activity detected
Provide evidence on how to evaluate anomalous network activity, including actions taken and escalation, and include references to your CIP-008 Cyber Security Incident response plan(s). Evaluation process and decision flow diagrams can be powerful evidence, especially when backed by logs and outcomes from detected network anomalies.
Common Evidence
- Anomaly evaluation process documentation
- Anomaly classification and escalation process documentation including criteria to activate incident response under CIP-008
- Anomaly events with actions and outcomes
R2 Retain INSM data
Data retention is often considered straightforward. Processes define the retention period, how retention is configured, where data is stored and replicated and finally how it’s backed up. However, there is more to retention than defining the processes. When it comes to retention, the area where teams trip up the most is understanding the requirements for operational data vs. evidence. CIP-015 has two retention buckets, with two different obligations and two different clocks:
The nuance is that operational data becomes compliance data the moment an anomaly is evaluated, especially if it turns out to be the start of an incident. The requirement is to retain data as long as you need it to conduct the analysis, which sounds vague compared to the stark lines we’re used to. Best practice: don’t set an arbitrary “delete after three months” rule. Tie retention to outcomes.
Common Evidence
- Documented data retention processes
- Evidence that data retention is being followed
R3 Protect INSM data
For R3, decide whether data is BCSI before audit, not during; it is usually the start of the process. Normally INSM data is BCSI, but everyone writes their own program. If you classify it as BCSI and protect it under your CIP-011 information-protection program, that should satisfy R3. If you decide it isn’t, you still have to apply and document your protections.
Either way, role-based access, audit logging, segmentation, storage integrity and hardening are controls designed to prevent an adversary from quietly removing the very record you’ll rely on to detect them. Documenting what is being deployed to protect the data is key.
Common Evidence
- Documented data protection processes
- Evidence that data protection is implemented
Data Management
More than most NERC CIP standards, INSM is a data-management standard. Run the numbers on 100 Mbps of PCAPs with no overhead, extrapolated over a year and then three, and the storage requirement grows alarmingly fast. At roughly $1,500 to $3,000 per terabyte per year for enterprise-class storage (a figure that’s been climbing), “keep it all” stops being a strategy.
Because not all data carries the same value over time, the smart move is to tier it based on value and need, and storage cost. The technical rationale includes a table along these lines, adapted here:
Adopting data management strategies that ensure data is available to support evaluation and investigations while not keeping low-value data that is not needed for evidence will be key to running a successful INSM data management program.
Where the Findings Hide
Detection and evaluation (R1 Parts 1.2 and 1.3) are where auditors will likely find issues. Picture an audit sample request that touches a thousand anomalies. If the auditor happens to pick the one where someone didn’t complete the evaluation workflow, that’s painful. To avoid that scenario, define your process and follow it for every single event, because you rarely know up front which anomaly will matter.
Be Audit-Ready at All Times
If one habit ties all of this together, it’s the one my early mentors drilled into me: be audit-ready at all times. Automate evidence generation. Let the system drop a .pdf, .csv or audit log into a folder on a cycle and have someone verify it. Trust, but verify. Run mock audits. You’ll catch issues in a dress rehearsal that you can self-report in advance, which builds a far better relationship with your region than having an auditor find it for you.
Final Thoughts on Evidence Generation and Collection
CIP-015-2 is coming. It leaves most of the evidence requirements substantively unchanged but expands scope beyond the ESP and brings Shared Cyber Infrastructure into play. If your program is well-built, that shouldn’t change how you collect, only how much.
This post only scratches the surface of what was covered in the webinar. Register for the webinar series and watch the Episode 6 replay for the full discussion, including the storage math and some choice mock-audit stories. And if you’d like to talk through how any of this applies to your own program, reach out. We’re here to support you.
.webp)
