Back to the “Definitions Wars”?
An Ancient History lesson
Before two weeks ago, the last time a new set of CIP standards was introduced was in 2011, when the NERC team that drafted the CIP version 5 standards (after having previously drafted CIP versions 2, 3 and 4) introduced the new standards CIP-002-5.1 through CIP-011-1. The NERC approval process (including four ballots and intervening comment periods over one year) for CIP v5 started in early 2012 and lasted one year, followed by FERC approval on November 22, 2013 (50 years almost to the minute after John F Kennedy’s assassination – although nobody has ever alleged there’s any connection between the two events. Me? I’m still not sure…😊).
There were many discussions (and debates) over the standards in the NERC community during the drafting and balloting periods. The version that was finally approved had been significantly changed in response to comments received after each of the first three ballots (in just one of the comment periods, the SDT received over 1,000 pages of comments. They had to respond to every comment, although they were able to group similar comments and answer them together).
Despite all the discussions and revisions to the standards before they were approved by NERC and FERC, more problems were discovered after FERC’s approval, as NERC entities prepared for compliance. One of the biggest problems was that the SDT hadn’t defined two words that were part of the “foundation” of CIP v5: “programmable” (used in the defined term Cyber Asset, the foundation of asset identification) and “routable” (used in the defined term External Routable Connectivity). While the SDT defined literally all the important terms in CIP today (Cyber Asset, BCA, BCS, EACMS, PACS, ESP, Interactive Remote Access, etc.), they wanted to limit their number as much as possible, since creating a definition that’s used in more than one NERC standard requires submitting it to the same balloting process as the standards themselves.
If a NERC CIP standard uses a word that has a generally accepted definition in the computing and networking community, it’s OK if it isn’t officially defined. Since I attended many of the SDT meetings in 2010 and 2011 (which were mostly in person, of course), I can attest there were several discussions of those two words. However, the team convinced itself that both words have a generally accepted meaning (although I don’t recall one ever being called out); therefore, there was no reason to create a definition for either of them.
This turned out to be a mistake, since once NERC entities started to put together their v5 compliance programs in early 2014, they had a lot of questions about the meanings of those two words. I wrote about twenty posts on the various interpretations that NERC entities made of each word, as well as NERC’s ultimately fruitless efforts to “define” them without invoking the only process allowed by the NERC Rules of Procedure: developing a definition and having it balloted by NERC entities, approved by the NERC Board of Trustees and finally approved by FERC (a process that is almost identical to the process of developing a new standard, and is certain to take 2-3 years). There was even a meeting (including just NERC staff members and staff of the four trade associations) at NERC’s offices in DC in I believe 2015; it was mostly focused on the meaning of “programmable”. From what I heard, the discussion grew so heated that it was a miracle that a fistfight didn’t break out.
How were these controversies officially resolved? Neither one was resolved – since nobody had the time or inclination to devote a couple of years to resolving them the correct way. Instead, NERC entities and their auditors worked out a general understanding of both terms. But none of that was ever written down, and there was nothing to prevent an auditor from changing his or her mind and issuing a PNC (potential non-compliance) notification for a procedure they had said was probably compliant a month previously. I wish I could say this were the only case in which something like this happened, but that would be far from the truth.
Those who do not learn from history are doomed to repeat it
Two weeks ago, what I call the Cloud CIP SDT introduced four of the approximately twelve standards that they are proposing to ultimately replace the current CIP standards (except for CIP-014 and – perhaps – CIP-006, the two physical security standards). They are called the “hundred series”, since they are numbered CIP-102, -103, etc. The primary term in the standards (i.e. the equivalent of “BES Cyber System” in today’s CIP standards) is “BES Cyber Services and Systems” (BCSS). Its definition consists of almost exactly the wording of the current BES Cyber Asset definition, with the term “Cyber Asset” replaced by “One or more cyber services or systems”.
In today’s CIP standards (which are fundamentally unchanged since CIP v5 was introduced), the basic defined term is Cyber Asset (even though the definition of that term, “programmable electronic device”, is ambiguous due to the lack of a definition for “programmable”). The fact that Cyber Asset is part of the definition of BES Cyber Asset means that today, asset identification must start with devices; anything not in the universe of intelligent devices isn’t in scope for CIP compliance today (only software on devices that are in scope is itself in scope).
Of course, since the 100 series standards are intended to apply both to on-premises and cloud-based systems and since individual devices (or combinations of devices) can’t be tracked by cloud users, Cyber Asset is no longer a useful term. Moreover, since BES Cyber System is defined as “One or more BES Cyber Assets…”, it clearly can’t be used in the cloud, either.
This is why the Cloud CIP SDT developed the term BCSS. It was a good decision to build the definition on the BCA definition, since the concept of “sub-15 minute impact on the BES” is a valid one, whether the asset being considered is an on-premises device or entirely in the cloud. However, the devil’s bargain that the SDT made to do this was basing the BCSS definition on two undefined terms: “cyber service” and “(cyber) system”. If this isn’t fixed, the 100 series standards are unlikely to be approved by NERC or FERC; even if they’re approved, these problems will persist long after the 100 series standards have been implemented (which is unlikely to be before 2030, if then).
You might point out that the term “system” is a fundamental part of “BES Cyber System”, even though it’s not defined – just like programmable and routable aren’t. The CIP v5 drafting team discussed defining “system” as well, but they ultimately decided that defining BCS as “One or more BES Cyber Assets” meant they had implicitly defined “system” as “a grouping of Cyber Assets”. While I never thought that was a great move, it at least stopped the bleeding; unlike with “programmable” and “routable”, there were never big arguments about “system” that I know of.[i]
However, I think not defining “cyber system” and “cyber service” will be a huge mistake for this SDT, if they don’t correct it before they go to the balloting phase. Fortunately, the SDT has now admitted that balloting won’t start until early2027, and perhaps not even then. Until two or three weeks ago, they were insisting (without providing a good reas) that balloting had to start in September, which would have – by my calculation - required stopping the earth’s motion around the sun for at least a month or two as they finished the many things they were required to do before the balloting can begin. I always suspected that insisting on the September date was the SDT’s way of demonstrating that they have a sense of humor.
If the SDT doesn’t draft definitions of those two terms[ii], here’s what could happen: any NERC entity would be free to develop their own definition of BCSS, as long as they could justify it to the auditor; at the same time, auditors and Regions would be free (nay, required to develop their own definitions). What could possibly go wrong with that?
Well, for example:
· Suppose an entity decides that only systems that run Windows are properly called BCSS, whether they’re in the cloud or on-prem. They say this because Windows software has more vulnerabilities than Linux software. This blog doesn’t discuss religious issues, so I won’t weigh in on whether that’s a valid argument. However, I can certainly see it coming up.
· An auditor might decide that, since the average software product today contains hundreds of dependencies - which are often called “microservices” when part of SaaS - and each dependency is a software product in its own right, they should all be identified as BCSS.
· A user might argue that only dependencies that load into memory when the user accesses the software should be identified as BCSS.
· A user or auditor might argue that only dependencies that load from the cloud should be identified as BCSS, whether the software is used as SaaS or on premises. They would argue that dependencies that are part of the base software should normally be patched by the software supplier.
· Another auditor might point out that the user needs to verify that the supplier patches component vulnerabilities; otherwise, the components need to be treated as separate BCSS.
· A user might note that since only a very small fraction of vulnerabilities found in software components are exploitable in the software itself, treating any components as BCSS will make compliance with the 100 series requirements needlessly burdensome for any NERC entity.
· An auditor might announce they’ve decided to retire and take a job as a Walmart greeter.
Wouldn’t all these discussions be great fun and quite interesting, especially at audit time? If you don’t think they would be, you might suggest to the SDT, during the 45-day comment period that started last weekend, that they define “system” and “service”, or even better drop the latter from the BCSS definition altogether.
Tom Alrich’s Blog, too is a reader-supported publication. You can view new posts for three months after they come out by becoming a free subscriber. You can also access all of my 1300 existing posts dating back to 2013, as well as support my work, by becoming a paid subscriber for $30 for one year (and if you feel so inclined, you can become a founding subscriber for $100). Whether free or paid, please subscribe.
If you would like to comment on what you have read here, I would love to hear from you. Please comment in my chat or email me at tom@tomalrich.com.
[i] However, if the SDT had been willing to take the time to define “system”, we probably would not be having such a big problem with the cloud today, since the problem is almost entirely because of out-of-date definitions.
[ii] I don’t understand why both “service” and “system” need to be included in the BCSS definition. “Systems” are found both on premises and in the cloud. On the other hand, “service” only applies to the cloud; if access to software is provided in the cloud, it’s called “software as a service” or SaaS. But it’s both a system and a service.
However, SaaS only meets the BCS definition if it has a real-time impact on the BES, which implies a direct connection to a sensor or actuator. Any other SaaS that is used to operate or monitor the power grid might use BCSI, in which case it falls under CIP-004-7 R6 and CIP-011-3 R1 and R2. A separate SDT recently spent 2-3 years developing or modifying those three standards to accommodate use of BCSI in the cloud; they did an excellent job. There’s no reason to reopen that issue.