For those coming in late:

  • 9/11 and multiple worms increase cyber security concern for the electric grid
  • NERC representing bulk electric systems decides cyber security standards are required
  • August 2003 NERC issues temporary Urgent Action Cyber Security Standard 1200 (approved one day before the big blackout in the Northeast)
  • NERC works on permanent cyber security standards
  • Work on the NERC permanent cyber security standards drag on
  • In August 2005 Congress intervenes and passes the Energy Policy Act which requires FERC to develop and enforce cyber security standards for the bulk electric system.  FERC is to certify a Electric Reliability Organization (ERO) to develop and enforce the standards, subject to FERC oversight
  • May 2006 NERC CIP-002 to 009 permanent cyber security standards are approved
  • July 2006 NERC officially named ERO as all expected from the start
  • NERC submits CIP standards to FERC as ERO

Which brings us to last month when FERC issued a public document on December 11th commenting on the NERC CIP cyber security standards.  A bit tardy, but here are my comments on their comments.

FERC hit a few main themes hard:

  1. Latitude. CIP standards give an electric utility too much latitude in deciding how secure they need to be.  The CIP standards are littered with phrases like “reasonable business judgement” and “when technically feasible”.  These were probably required to get NERC member approval, but it is easy to see why a regulatory body would not want a utility to determine when they can do less than the spirit or letter of the standard.  FERC staff wrote “staff is concerned that the language unduly compromises the effectiveness of the CIP Reliability Standards and the ability to enforce compliance with them since each Responsible Entity would have discretion to determine how to implement the CIP Reliability Standards”.
  2. Your risk is my risk. In several requirements the standards allow the bulk electric entity to “accept risk” rather than meet the requirement.  FERC points out that since the bulk electric system interconnects utilities and other entities, one entity accepting risk is essentially accepting the risk for all connected entities. Obviously this was not viewed favorably by FERC.  Related to this is FERC’s concern that small entities may not be required to meet the standard but could become a “vector of vulnerability to the security posture of interconnected control systems.”
  3. Lack of specificity. The requirements are written broadly, again probably to gain NERC approval and also because specific standards are harder to write.  FERC gave many examples.  The risk-based methodology used to identify Critical Assets and Critical Cyber Assets is extremely important but not specified in any real detail.  So one utility could write a methodology that resulted in few Critical Cyber Assets and a similar utility could write a methodology that resulted in a large number of Critical Cyber Assets.  FERC’s comments imply they would have preferred the methodology be defined in the standards.  Similar issues were raised with the required security policy, controls at electronic security perimeters, vulnerability assessments, …
  4. Delay. FERC was not happy with the schedule that delayed compliance auditing until Q2 of 2009 at the earliest.  FERC would prefer to see audits begin within the year even if the audits are not full audits.

I have mixed feelings on FERC comments.  They are understandable and would definitely strengthen the standards.  The standards are vague and do have too much latitude, but adding the detail FERC wants could take a while even under the best of circumstances.

The comment I agree with most is the time schedule.  If I had all power I would probably accept the standards for a period of time (1 or 2 years), move up the timetable for auditable compliance to Jan 1, 2008, and start now to add specifity and remove latitude from the standards so a more rigorous set of standards was available sometime in 2008.

This approach would support a gradual increase in security.  It is very hard and often not practical for an organization to go from a low level of security directly to a high level of security.