CIPC met this past week in St. Louis, with a good agenda of cyber, physical, and compliance items. A bit of background for non-CIP folks, the CIPC stands for Critical Infrastructure Protection Committee, an advisory panel to NERC and the ES-ISAC “in the security areas for physical, cyber, operations, and policy matters”. The CIPC meets several times a year to discuss security topics, share information regarding critical infrastructure protection, to develop guidelines for use by NERC members for implementing security, and to assist in the development of the NERC standards (in this case, the CIP standards).
First off, this year appears to be the year of the ES-ISAC. ES-ISAC stands for the Electricity Sector Information Sharing and Awareness Center. Seeing the name, it may have been established due to gov’t action. Maybe, possibly, yes. Every odd-numbered CIPC presentation either pointed to the ES-ISAC as a definitive source for some piece of information, or was discussing changes to the ES-ISAC’s composition/structure and how those changes benefited members. It’s stated purpose is to facilitate information sharing between the gov’t and industry in the area of threats, vulns, and protective measures.
When the 1200 and CIP regulations came out after the 2003 NE Blackout, the ES-ISAC took a hard right to the jaw, and hasn’t really recovered from it. That ‘hard right’ was being operated by NERC , which was now responsible for enforcement the new reliability regulations. I spent a good chunk of 2005-2011 hearing the following question: “Why the heck would I report my vulnerabilities to my auditor??”.
With that history in mind, the most important changes presented at CIPC is that ES-ISAC is freeing itself from the perceived influence of the regulatory side of NERC. There was already a policy in place that didn’t allow communication from ES-ISAC to Audit/Enforcement, but there are steps being taken to wholly separate it out. CIPC presentations indicated that ES-ISAC is going to be a separate corporation from NERC in the near future, and the reporting structure has already been changed. ES-ISAC is now under the CSO, Tim Roxey, and he reports directly to the CEO, Gerry Cauley. This goes in with a general theme of the conference that the ES-ISAC was being stood up as the central coordinating point for electric power. Time will tell how the ES-ISAC fares in presenting themselves to industry as a separate and valuable entity outside of NERC, but the message was very clear at this meeting.
If this is the position of the ES-ISAC, and of the CIPC in particular, the corrective actions they have taken regarding the relationship with Audit/Enforcement are just the beginning. The bulk of the industry remains jaded from years of frustrating cyber security regulatory compliance. Additionally, ES-ISAC will need to show that it is valuable to the electric power industry in a way that is under-served by less sector specific organizations like ICS-CERT and SANS. And, ES-ISAC will need to do this while utilities gear up to work with the massive changes in scope that the CIPv5 is bringing around.
To do this successfully and in a way that adds value, I think the ES-ISAC needs to move beyond the bare bones coordination, recitation, and disclosure of vulnerabilities that ICS-CERT provides. ES-ISAC needs to provide the same type of raw data, but accompany it with analysis-in-context to electric power participants. At minimum, this analysis must support engineers from struggle with evaluating the risks to their systems, or that might be turning to the CIP regulations as their de-facto process. ES-ISAC should provide mitigation that is specific to the way electric power operates and maintains our SCADA, DCS, and other control systems. In this, ES-ISAC has an advantage; They can communicate the specific (and potentially sensitive) context directly to members, but a possible disadvantage is that I’m not sure if they have any charter restrictions that may prevent them from developing/presenting context themselves.
For example, a vulnerability in a PLC would be less of an risk in a normal Control Center environment; Control Centers generally don’t make extensive use of PLCs. But, a PLC vulnerability might be extremely important to a Generation plant, who typically use them in ancillary systems like water treatment, fuel handling, and waste removal. That level of context is missing right now, and it is certainly valuable to members who are concerned about cyber security issues. Without context, it’s easy for owners and operators to get lost in the flood of vulnerability notices that have been coming out, and that will likely continue as more and more cyber security research is conducted on the software and components that help monitor and control infrastructure.
This type of context doesn’t come easy… It requires building relationships with those that have operational experience, and those that have computer security and vulnerability experience, and distilling that into concrete guidance. Luckily, ES-ISAC has a wealth of operational types to draw from in CIPC participants, unlike many other cyber vulnerability organizations.
<Post got too long, stayed tuned tomorrow for Part 2!>
title image by C!…