Cyber Asset Lesson Learned Finalized

NERC’s Standards Committee (SC) approved the Lesson Learned (LL)document on CIP-002-5: BES Cyber Assets on January 21, 2015. This document was originally released for comment on September 9, 2015, and the final document is dated December 7, 2015. It was created by NERC’s V5 Transition Advisory Group (V5TAG).

One of my criticisms of the LL process is that the LLs will be commented on, get revised, and then get approved and posted by the SC without industry having a chance to see or vet the revisions before they are finalized. While NERC has re-posted some of the LLs for comments, they’ve generally only done that when there are major revisions, and they definitely haven’t done so for all (or even most) of the Lessons Learned documents. This leads to a limited number of people actually having input into what the final, official, document contains. I believe this process has the potential to introduce flaws into the documents, and it happened again with the Cyber Asset LL.

The final document will be available from the “Related Documents” section of the CIP-002-5.1 page at NERC’s website, and the consideration of stakeholder comments will be available from the transition program page. The redlined version of the document is a little harder to find, but it is available from the SC agenda package for their January 21, 2016 meeting.

Sidenote: At one point, the redlined versions were not provided by the V5TAG or the SC. As part of my day  job I actually went and created a redlined version from the previous draft and the finalized draft for a couple of the LLs. That was a pain-in-the-butt, so the inclusion of the redlined versions the last few times finalized LLs were released was much appreciated.

Anyways, the purpose of this post is to look at some of what is in the LL and some of what was taken out of it.

When Cyber Assets meet a threshold of BES impact they become BES Cyber Assets (BCA) which may be grouped by responsible entities into BES Cyber Systems (BCS)

While I don’t disagree with this statement, I think it may be misleading to some people, specifically the word “threshold”. If the Cyber Asset has an adverse impact on the BES within 15 minutes of being misused, degraded, or unavailable, then it is a BES Cyber Asset.[^This is a simplified definition, obviously, and there are more qualifiers and requirements, but this summary works for now.] While the 15 minutes could be considered a threshold, there is no allowance in the standards for the adverse impact to have some minimum threshold. The way the sentence in the LL is worded, with “threshold” directly preceding “of BES impact” could cause some confusion for somebody who associates “BES impact” with the “adverse impact” from the BES Cyber Asset definition.

Some study participants assessed each functional system at a site or facility to determine its potential to adversely impact the BES in 15 minutes or less…Other study participants identified all Cyber Assets, grouped them into BES Cyber Systems, and evaluated the impact of the resulting system.

I like how this provides two approaches to achieving the goal of identifying BES Cyber Assets. This is a good example of an LL being written in such a way that it acknowledges that, “there may be other legitimate ways to fulfill the obligations of the requirements that are not expressed within this supporting document,” as the LL puts it in the introductory paragraph.

Did the device’s function directly impact the reliable operation of a BES asset?

The word “directly” was removed from here, and there were similar edits at other places. This was done in response to a comment from ACES, and seems like a good decision, although it leads to a problem discussed next. There’s nothing in the definition of BES Cyber Asset that talks about a difference between “direct” and “indirect” impacts, and so adding that concept here seems like it would add to confusion insteading of making things more clear.

Did the device function as an EACMS, PACS, or Intermediate System? These types of devices, such as firewalls, intrusion prevention systems or physical access controllers and others that perform security functions may indeed have an adverse impact if they are unavailable or misused to allow unauthorized access or deny authorized electronic or physical access, but it is an indirect impact. These devices have their own definitions and requirements in the CIP version 5 Reliability Standards and therefore are not considered BCAs due solely to their impact.

This is the most glaring example in this document of the problem of not having LLs vetted by industry after being edited. I do not think these changes would have made it through a public vetting process, if there had been one. In the first part of this paragraph, they are saying straight-up that firewalls, IPSs, or other security devices can have an adverse iimpact if they are unavailable or misused. While these devices do have their own definitions, there is nothing in the definition of BES Cyber Asset that would imply that an entire class of devices can be categorically excluded from the requirement to determine whether they are BES Cyber Assets. By removing those last five words from this paragraph in the draft LL, the V5TAG has gone beyond providing an example of a compliant approach, and has gone into the terrority of interpreting the standards.

There are programmable devices that may have an impact, but have no way to change their executing code, have no concept of a user or authentication, have no ports/services, have no network connectivity, no concept of event logs or alerting, no patches or updates, andor are located in areas where physical security perimeters cannot be established. For these devices, the ERO will allow (for the purposes of assessing compliance with the standards) Responsible Entities to only protect those devices to the extent capable.

The last sentence in this excerpt had, by far, the most comments related to it. EEI went so far as to say that unless the sentence was removed they couldn’t support the document being submitted to the SC for approval. The problem with the sentence was that it implies that non-programmable devices, if they would have an adverse impact within 15 minutes of their misuse, degradation, or unavailability, would have to be protected to the extent capable. The definition of Cyber Asset, though, explicitly states that a Cyber Asset is programmable. That means that a number of new devices would now be in-scope for the CIP standards.

They changed this table to say they were identifying Cyber Assets typically “evaluated” as BES Cyber Assets instead of saying they were typically “identified” as BCA. This change seems to be more in line with what the purpose of the list of device types originally was.

The transition study participants found a lack of clarity in the CIPV5 Reliability Standards because they do not specifically define the “programmable electronic device” component of the BES Cyber Asset NERC Glossary term. Consequently, the CIP V5 Transition Advisory Group referred the identified issues to be evaluated for standards development.

This was added to the document. While a better definitio of Cyber Asset or a definition of “programmable” is needed, unfortunately the creation of an SDT will not be a very quick process, so that clarification likely won’t help most entities very much in the near- to mid-term future.