I’ve been doing a lot of work that involves the CIP vulnerability assessment process recently, namely while developing the Bandolier R8 Audit Files, and another more comprehensive file set that haven’t been released yet.  This week, I had the opportunity to sit in on part of the Order 706 Development Team Webinar.  The 706 Team is responsible for creating the next generation of the NERC CIP standards, and they were presenting the V5 standards to industry before the comment period.  For more info on the 706 Team, check out NERC’s 706 project website.

Over my next few posts, you’ll notice a compliment sandwich format regarding the Version 5 updates…  A few comments relatively positive, a few negative, repeat as necessary.  I’ll be continuing this format over the comment period of the Version 5 standards.

I heard a lot of good things on that call, and a few things I didn’t  agree with.  However, I did notice a welcome increase in the scope of the vulnerability assessment from NERC.  In the original CIP standards, the CIP-007 R8 vulnerability assessment requirement wasn’t a full vulnerability assessment.  The minimum requirements boiled down to an audit of the ports and services and default user accounts on individual cyber assets. It was the combination of these two factors that started a 2009-2011 personal trend of calling the R8 requirement the “NERF Vulnerability Assessment”, after the popular line of children’s’ toys.

Version 5 makes an upgrade to the scope of the required vulnerability assessment.  The Version 5 scope is expanded, requiring an evaluation of all sub-requirements in CIPs 005, 006, and 007.  As an example of the scope increase, cyber assets could conceivably go through a bare-minimum R8 assessment totally unpatched and without anti-virus installed. Version 5 would require that patching and anti-virus implementation be included in the assessment, and deficient systems be identified as findings.

Regardless of how good the scope upgrades are, I believe there is still an issue with the vulnerability assessment process that has not been identified. The vulnerability assessments are discoverable during an audit, and there is still a fear among owners to fully embrace a Vulnerability Assessment process due to potential fines for anything discovered.

This audit and monetary penalty fear is harmful to the process of systematically assessing critical infrastructure for potential vulnerabilities, and providing the motivation to fix those vulnerabilities.  Individuals with the responsibility for ensuring compliance find themselves in a catch-22: On one hand, these issues are risks to their system and to compliance, and should be identified and acted upon.  On the other hand, these issues are often failures of the compliance process, and are punishable by monetary penalties.

To help combat this fear, I have a radical idea for consideration: Make non-willful violations discovered in the course of a V5 vulnerability assessment not punishable by fines, but require the prompt reporting of the V5 findings via the self-report and mitigation process in order to qualify.  By conducting compliance in this manner, owners have an incentive to set vulnerability assessors free to identify a multitude of issues, within the defined scope and budget. Owners could not be fined due to the initial discovery, but could be fined due to insufficient mitigation response actions in the face of the known risk.  This would encourage a culture of responsible compliance, where issues are raised in a safe, fear-free, and responsible manner, then tracked for compliance and hopefully resolved quickly and completely.

Any comments, or questions, please post below for discussion.

title image by robnguyen01