A friend –
who probably knows a lot more than I do about NERC CIP, but came into the game
later than I did - asked me recently to write a post on the history of CIP. I’m
finally doing that, although I’ll say at the outset that this isn’t meant to be
your standard Wikipedia article. It’s focused on what I know personally, and you
have to be very careful on what you take away from this post as facts vs.
opinions. That being said, I hope you’ll find it interesting. I was originally
planning on calling this a “brief” history of CIP, but as you can see the brief
part fell by the wayside (I've never been very good at brevity, anyway). You hereby have my permission to read this post in
two or three sessions. I probably won’t be able to write another post this week, anyway.
The origins of
CIP were long before I became involved with it (2008). I’m told there were some sort
of market access standards (from FERC) that required cyber security measures
around 1999 or 2000, but I’ve been unable to verify that in my extensive
five-minute search of the internet. I have to assume this is actually some sort
of creation myth dreamed up by pre-(cyber-)literate peoples as they chewed on
mastodon bones while sitting around campfires.
NERC cyber
security standards first enter the historical record around 2003 with NERC
Urgent Action 1200, aka NERC Cyber Security Standards (CSS); like all NERC
standards before passage of the Electric Power Act of 2005, compliance with
them was voluntary. The standards applied only to control centers. They were
later replaced by UA 1300, which now applied to generation as well as control
centers.
After
passage of EPAct, the UA 1300 standards were submitted to FERC as CIP-002
through CIP-009 in August 2006. After issuing a NOPR (Notice of Proposed
Rulemaking) in July 2007, FERC approved these standards as CIP version 1 in
January of 2008 in their landmark Order 706.
You’re free
to read all 221 pages of Order 706, but the highlights of the order are:
- FERC approved the CIP v1 standards.
- At the same time, FERC ordered NERC to make “revisions” to
these standards. Since NERC’s Rules of Procedure don’t allow any standard
to be revised once approved by the NERC Board of Trustees, and since all
standards are approved by the BoT before even being submitted to FERC for
their approval, these changes would have to be in a new version of the
standards, version 2. Accordingly, NERC constituted a new drafting team,
dubbed CSO 706 for Cyber Security Order 706; the team first met in the
fall of 2008.
- IMHO, the primary changes FERC requested in Order 706
were:
- The CIP v1 drafting team had used the phrase “reasonable business judgment” in a number of places in the standards, to indicate that certain questions were left up to the entity to decide. FERC didn’t like this language, and ordered it removed.
- The team had also used the phrase “acceptance of
risk” in the standards. This is a common phrase in cyber security
standards and guidelines in general. It means that the entity, in cases
where mitigating a particular cyber risk may be too difficult or costly,
agrees to instead accept the risk and move on. FERC pointed out –
correctly, in my opinion – that the risk involved in the CIP standards,
as well as all NERC standards, is risk to the Bulk Electric System, not
to the organization itself. No organization can decide to accept
risk on behalf of the whole BES.
- The drafting team had also used the words “where
technically feasible” in multiple places, meaning that, if a particular
requirement couldn’t be complied with for a particular type of device in
scope (for example, a switch that couldn’t comply with the antivirus
software requirement because there was no way for the end user to load
such software on the switch), the entity would only need to point out
that fact at audit. However, FERC ordered NERC to “develop specific
conditions that a responsible entity must satisfy to invoke the ‘technical
feasibility’ exception.” This led to NERC’s later development of the TFE
process, which probably shortened the lives of a number of CIP compliance
professionals by 5-10 years.[i]
- The
Commission directed NERC to “provide additional guidance regarding the
development of a risk-based assessment methodology for the identification
of critical assets pursuant to CIP-002-1.” They were already skeptical
that NERC entities’ use of the RBAM, as specified in CIP-002-1 R1,
would end up identifying many Critical Assets, and they were right. Other
than Control Centers, very few generating stations were identified as
Critical Assets under CIP v1-3. There were a number of substations that
were so designated, but that designation was usually obviated by the fact
that, in CIP v1-v3, if there was no external routable connectivity at an
asset, it wouldn’t have any Critical Cyber Assets – meaning no systems
would be in scope at the substation. Because the great majority of substations at the time were not routably connected to the outside world, there were very few
substations with CCA’s. This meant that there were very few substations that were effectively in scope for CIP, even
though they might have been designated Critical Assets.
- FERC
also ordered “external review of critical asset lists…” FERC didn’t
directly tell NERC what they were asking for in this regard, but NERC did
develop the “bright line criteria”, which first appeared in CIP v4. The
criteria did away with the RBAM altogether and simply specified what types
of assets would become Critical Assets, based on various technical conditions. When the CSO 706 drafting team
started work on CIP v5, they modified the criteria so that they dropped
the reference to Critical Assets, replacing it with High, Medium and
Low impact levels.[ii]
When the CSO 706 SDT started meeting in 2008,
they decided to triage the directives from Order 706. They would first
address the “low-hanging fruit” in CIP v2, then address the rest of the directives
in v3. So they immeidately developed CIP v2, which eliminated both the “reasonable
business judgment” and “acceptance of risk” language from the v1 requirements.
V2 was quickly balloted and passed, approved by the NERC Board, submitted to
FERC and finally approved by FERC in September 2009.
When FERC approved CIP v2, they brought up a
new requirement – for procedures for escorted physical access into Critical
Assets by persons not authorized for direct access to Critical Cyber Assets -
that they wanted to see added quickly; in fact they required that the new CIP
version be approved and submitted to them in 90 days. NERC accomplished this
feat, and FERC approved CIP v3 in March of 2010.[iii]
It came into effect that October.
Once the CSO 706 SDT had drafted CIP v3, they
turned their attention to CIP v4. They had a radically different idea
for v4, though: They would just have two standards. CIP-010 would replace
CIP-002, and it would provide a new way of identifying assets in scope for CIP:
through bright-line criteria. Also, those assets would no longer be classified as
Critical Assets or not in scope; they would be classified High, Medium and Low
impact. Furthermore, the systems in scope would be called by a new term, BES
Cyber System. All of the requirements in standards CIP-003 through -009 would be combined into CIP-011, and there
were many changes proposed for these requirements. The first drafts of these
two proposed standards were developed in early 2010; the SDT expected to be
able to get these two new standards approved by NERC by the summer of 2010.
This radical proposal led to a firestorm of
suspicion among NERC entities, and 600 people signed up to attend as observers –
in person or by phone – for the SDT’s next meeting, in Dallas in April 2010. At that meeting these observers
weren’t exactly shy about registering their profound concern.[iv] It was clear that the SDT's proposal would never be approved in anything like its current form.
After this meeting, the SDT retreated to
their phone meetings to decide what to do; they clearly couldn’t go ahead with
the CIP-010/-011 proposal now. One of the big objections to the proposal might
seem pretty mundane, but really wasn’t: By changing the numbering of the standards
so drastically, NERC entities were going to have to make some huge changes in
computer systems as well as other things like training programs, which were all
based on the CIP-002 through CIP-009 scheme.
In the aftermath of the Dallas meeting, some
CEOs of large utilities became convinced that, if NERC didn’t develop some new CIP version by the end of 2010,
FERC would completely take away from NERC the task of developing new CIP
standards. So somebody developed the idea of just replacing CIP-002-3 with a
new CIP-002 that would implement bright-line criteria for identifying Critical
Assets, but leave everything else in v3 (including identification of Critical
Cyber Assets in CIP-002 as well as CIP-003 through -009 in their entirety)
unchanged. This would address FERC’s primary concern, which was that too few
assets had been designated Critical Assets, due to the looseness of the
criteria for developing a risk-based assessment methodology in CIP-002-3 R1.
And this is what happened. The SDT got to
work[v]
adopting the bright-line criteria to CIP-002 (and making some changes to them
from the original CIP-010 draft), but didn’t touch any of the other standards
(except to change their version numbers, so all of the new draft standards were
version 4). The final ballot approving CIP v4 occurred at the end of 2010, and
v4 was submitted to FERC immediately.
With v4 behind them, the drafting team started
work in January 2011 (at a meeting located at the headquarters of a large
utility, during which meeting the power went out in most of the building for a
couple hours - Oops!) on CIP v5, which was now going to be the version that
finally provided most of the changes that FERC had asked for in Order 706 (plus
some more changes that NERC proposed, like the concept of BES Cyber System. By
the way, that term originated in a “concept
paper” in June 2009. This paper introduced the BCS idea, as well as the
idea of “BES Reliability Functions”, which later became the BES Reliability
Operating Services).[vi]
And a funny thing happened: Even though what
the drafting team was proposing was quite different from CIP v3, as the year
2011 wore on, popular support seemed to be growing for the new version; in
fact, some SDT members began to regret that they’d been rushed into developing
v4, when clearly v5 would do everything v4 does and a lot more. The hope was
that FERC would never approve v4, and v5 would become the next version.
That’s why it was a shock when, in September
2011, FERC issued a NOPR saying they intended to approve CIP v4. At the time, I
thought[vii]
FERC wasn’t all that serious about this – that they were trying to get all of
NERC to support v5. Why would it be in anyone’s interest to make a big
transition to v4, then a year or two later make an even bigger transition to
v5?
If FERC was trying to pressure the NERC
ballot body to get behind v5, the strategy didn’t work. The first draft of v5
was posted in November 2011, and was roundly voted down in the ballot in
December (the highest percentage of the vote that any of the standards achieved
was around 25%). But the SDT wasn’t fazed, and at their next meeting, at ERCOT’s
headquarters in January 2012[viii], they made a number of changes to the standards. Probably the most important change was eliminating any requirement for Low assets that might require identifying individual Low BCS; in fact, the SDT went further and
inserted wording in two or three places in the standards to the effect that an inventory of Low BCS
wasn’t required. Those assurances remain in place today, of course.
But FERC had another surprise up their
sleeve. In April 2012, they approved CIP v4. My opinion remained[ix]
that they weren’t serious about wanting v4 to come into effect (which was now
scheduled for April 1, 2014). Instead, they were sending NERC entities another
message: “You’d better get behind CIP v5 now. If you don’t, you’ll definitely
have to comply with v4, plus you’ll still have to comply with v5 after that,
because it will ultimately pass. Plus, the NERC Board has the power to write the
standard and send it to us for approval without balloting, in case you’d
prefer to do it that way.”
Whether the NERC membership was taking FERC
seriously, or whether the further changes made to v5 over the course of 2012
convinced them that it was now a workable CIP version (I suspect the latter),
the NERC membership did get behind CIP v5. It finally passed the fourth ballot
late in the year, and v5 was submitted to FERC at the end of January 2013.
However, even though some people at NERC were
expressing confidence that FERC would quickly approve v5 and at the same time
say that v4 would never come into effect, I had become convinced that, since v4
was the law of the land (which it was after FERC approved it), NERC entities
had no choice but to go full speed ahead in getting ready for v4. After all, as
of January 2013 (when I started writing this blog) there were only 14 months
left before the v4 compliance date. I even wrote a post
in February 2013, saying that it was highly unlikely FERC would approve v5
anytime soon (in that post, I also reiterated a call I’d previously made for
the compliance date for v4 to be moved back). I now call this my “Dewey Beats Truman”
post, since two months later FERC issued a NOPR
saying they intended to approve CIP v5, and that v4 would never come into
effect.
FERC approved CIP v5 in Order 791
on November 22, 2013[x].
As with all their previous CIP orders, they also ordered some important
changes, which of course became “CIP v6”. NERC put in place a new drafting team
to implement these changes, having decided that, after four or five years of
continual meetings, the CSO 706 team deserved a break (although two or three of
the members, being gluttons for punishment, continued on the new team).
Significantly, this new team was called the CIP Version 5 Revisions SDT. This
wasn’t an accident; with all of the back-and-forth and “start-no, stop-no,
start again!” of the CIP v4/v5 debacle, the industry was hardly in the mood for
a nice new version to sink their teeth into. So the words CIP version 6 were
evidently verboten in NERC circles; I
didn’t hear or see the term used until Scott Mix of NERC used it at a meeting
on the new version in Atlanta in early 2015.
Meanwhile, FERC had another surprise up their
sleeve. In March 2014, FERC issued an emergency order
in response to the Metcalf substation attack in 2013 (which had recently caused
a lot of alarm in Congress), mandating that NERC develop a new standard for
physical security of critical substations – and that they approve it and submit
it to FERC in 90 days. Needless to say, this was a big task, but it was accomplished,
and CIP-014 was approved by FERC that fall.
The “CIP v6” SDT worked throughout 2014 on
drafting and then balloting their revised standards.
There were some twists and turns along that way, but the "v6" standards were finally approved by the NERC ballot body at the end of 2014 and submitted
to FERC in February 2015. In July of 2015, FERC issued a NOPR
saying they intended to approve CIP v6. But FERC went beyond that to discuss
new or modified standards they were considering ordering NERC to develop,
probably the most important of which was a standard for supply chain security.
However, this wasn’t all that was going on in
CIP World. In fact, the major story was that throughout 2014 and 2015 there
were many discussions and battles in the industry about the meaning of the CIP
v5 standards[xi]. NERC
issued various documents – FAQs, Lessons Learned and Memoranda – many of which
ended up being rescinded. NERC finally decided that only a new drafting team,
developing even newer versions of some of the CIP standards, could clear up
these issues.
As it turns out, the new SDT would have more
on its plate than just trying to fix problems from CIP v5. In January 2016,
FERC issued Order 822,
approving CIP v6 and – as usual – also mandating some more changes in CIP. These
changes were added to the new drafting team’s SAR (and the new drafting team
was called the “Modifications to CIP Standards” SDT – note there’s no mention
of any version numbers at all in that name). This team started meeting in the spring
of 2016, and immediately focused on two items mandated by FERC, one of which
had a one-year deadline: the clarification of the meaning of LERC and a
requirement for Transient Cyber Assets used at Low impact assets. These changes
were balloted and approved in 2016, and submitted to FERC in early 2017. In
October, FERC issued a NOPR
saying they intend to approve these changes and – of course – asking for
comments on some further changes they may order regarding Lows. Assuming FERC
orders those changes when they approve the two changes that were submitted to them early this year, these
will most likely be added to the current SDT’s agenda.
Meanwhile, the other big development of 2016
(regarding CIP, of course. I think there was also some election in November
2016 that some people thought was significant. I, of course, was too caught up
in NERC CIP issues to pay much attention to that) was that FERC ordered
that NERC develop a supply chain security standard in July. This standard was
indeed developed, approved and submitted to FERC at the end of September. It
now awaits FERC’s approval.
The only other significant CIP development I
haven’t already mentioned was the startling announcement that I relayed in my post
dated April 1, 2017, that the US had decided to deploy NERC CIP to Mexico….And
on that note, I’ll sign off. It’s been fun writing this summary of what’s gone
on in CIP since 2008. I’ll plan on doing this every ten years from now on. Mark
your 2028 calendar now!
Happy New Year!
The views and opinions expressed here are my own, and do
not reflect those of any organization I work with. If you would like to comment
on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com.
[i]
At the September NERC CIP meeting, Tobias Whitney of NERC presented a slide
that showed the number of TFE’s submitted annually had fallen from in the
thousands under CIP v3 to under 200 in 2016; of course, this was because CIP v5
was designed to be “TFE-friendly”. Instead of requiring particular technologies
in all cases, CIP v5 deliberately makes use of terms like “per device
capability”, so that the entity can choose different ways of mitigating a
particular cyber risk, rather than have to implement just one particular
technology. The best example of this is CIP-007-6 R3, where antivirus software
is no longer specifically required. Instead, the objective of the requirement
is malicious code prevention, and the entity can choose whatever method is best
for any particular device in scope.
[ii] Of course, the
drafting team made a further modification to the criteria, in which they
tweaked the wording to indicate that the criteria applied to BES Cyber Systems,
not actually to the assets themselves; however, the criteria themselves still
apply to the asset, not the systems. As anyone who was following this blog in
2013-2015 knows, I thought
this was a very bad decision that was going to cause endless confusion going
forward. But guess what? I was totally wrong about this. Even though there is officially
no such thing as a High impact, Medium impact or Low impact asset, I doubt that
ten percent of NERC compliance professionals or auditors even know that this is the case. But it really doesn’t
matter, since exactly 0% of compliance professionals and auditors are actually
acting as if it isn’t the assets that are classified, but instead the BCS. And
I’m fine with that; as long as there is complete agreement that this is what CIP-002
R1 and Attachment 1 say, there’s no point in standing on a rooftop and yelling
that this isn’t the case.
I used to think that the chickens would come home to
roost on this issue the first time a NERC entity was fined for not properly classifying their
BCS at a particular asset – say, they classified BCS at a particular asset as
Low impact when NERC thought they should have classified them Medium impact. The entity would then take this dispute to an
Administrative Law Judge (which NERC entities are always allowed to do, since all
NERC standards, like all FERC-approved standards, are regulatory law). He or
she would spend 15 minutes trying to make sense of CIP-002 R1 and Attachment 1 –
as I did in my first-ever post
on CIP v5 in 2003, although I spent a lot more than 15 minutes writing it! - and
proclaim “What is this (stuff)?” He/she would throw out the penalty, but might
even rule that any dispute over classification of BCS was undecidable because
of the ambiguity and outright contradiction in CIP-002. I no longer think this
is likely to happen, though, mainly because the ultimate enforceability of CIP
v5/v6 has been undermined in other ways as well. In any case, no case against
NERC for a CIP penalty has ever been fully adjudicated, and I doubt one ever
will be. Too much depends on trust between NERC, the regions, and the entities,
for an entity to want to break that trust by filing a lawsuit.
[iii]
The single change that FERC ordered only applied to CIP-006, so NERC might
technically have just revised that one standard to version 2, leaving the other
standards at the v1 level. However, the drafting team decided to change the
numbering embedded in all of the CIP standards to v3, even though that meant
having to submit all of the standards for ballot. When the next drafting team –
charged with implementing the changes that FERC ordered in Order 791, which
approved CIP v5 in 2003 – faced a similar decision, they decided only to revise
the standards where there had been a substantive change and leave the others at
the v5 level, which is why NERC entities now have to comply with both CIP v5
and v6 standards. In the next couple of years, there will be CIP-003-7 (due to
the LERC changes) and CIP-005-7 (to implement changes that accompany CIP-013);
plus within 3-4 years CIP-003-8
will come along. And of course, CIP-010 and CIP-011 have their own version
numbers; they’re both on v2, although CIP-010 will go to v3 once CIP-013 is
approved by FERC. So, as I’ve pointed
out recently, we all need to get rid of the idea that there are “CIP
versions”. Instead, the CIP standards should all be considered as having their
own version numbers; it is up to the entity to make sure they are always
dealing with the current effective version of each standard.
[iv]
I didn’t attend that meeting in person, but I did by phone. The tension in the
room was readily apparent even 1,000 miles away.
[v]
I attended the August 2010 SDT meeting in Chicago – the first one I’d ever
attended – and wrote about it in an “open letter” published under the Matrikon
name (Matrikon was the company I joined one month before they were acquired by
Honeywell in June 2010, but for a year we continued to operate as Matrikon). I
later published some posts in a Honeywell cyber security blog, but started my
own blog in January 2013. If anyone wants to see this open letter, email me at tom@tomalrich.com. It also tries to explain
the big change from the original CIP v4 proposal (i.e. the one rejected in
Dallas) to what ultimately became CIP v4 – although of course that was never
implemented.
[vi]
I also attended this meeting and wrote about it in an open letter. You can
email me if you’d like to see it.
[vii]
And wrote about it in a post on a now-nonexistent Honeywell blog. I hopefully
have the text of that post on a USB stick at home, but I won’t be there for a
week. If you would like to see that, email me and if I’ve found it I’ll send it
to you.
[viii]
I also wrote about this meeting on the Honeywell blog. Again, I’ll know next
week if I still have a copy of that post. Email me if you’d like to see it.
[ix]
Again, I hope I still have the text of the post I wrote about this. Email me if
you’d like to see it.
[x]
50 years almost to the hour after the assassination of John F. Kennedy.
Coincidence, you say? Well, I don’t know…
[xi]
I must have written 50-80 posts on various controversies and developments
regarding CIP v5 in those two years. You’re welcome to go back and read all of
them. And if you do that, please tell me what they all said! I myself have no
stomach for doing that.
No comments:
Post a Comment