The standard drafting team (SDT) working on revising NERC reliability standards CIP-004-7 (Cybersecurity — Personnel and training) and CIP-011-3 (Cybersecurity — Information protection) will review the latest round of comments on the proposed changes in hopes of submitting them for approval this year. (See NERC Opens Comments on Standards Plan.)

NERC posted the standards for comment on Aug. 9, along with planned reliability guidelines on winter weather readiness and supply chain procurement. (See “Project 2019-02 Nears Completion,” Reliability Guidelines, Standards Posted for Comment.) Respondents were asked whether they agree that:

• the revisions to CIP-004-7 properly clarify the requirements for managing provisioned access to bulk electric system cyber system information (BCSI) when using third-party solutions such as cloud storage services;
• CIP-004-7 explains clearly that entities are only required to manage physical access to physical BCSI and electronic access to electronic BCSI;
• CIP-011-3 explains the protections expected when using third-party solutions; and
• the 18-month implementation plan proposed by the SDT is reasonable.

The results of the industry ballot that accompanied the comment period are not available yet, but SDT members have indicated they expect stakeholders to ultimately approve the revisions. However, the comments indicate there are some kinks to work out before industry gets fully on board with them.

Concern over Ambiguous Access Terms

Regarding the first question, a number of commenters complained about the insertion of the term “provisioned access” in CIP-004-7 without a definition. Anthony Jablonski of ReliabilityFirst asked that the term be either defined in the standard or removed entirely lest it “lead to misunderstanding [and] inconsistent audit results.”

“If you take ‘provisioned access’ to mean only intentionally created individual accounts, then administrative access to BCSI will not be governed by any standard,” Jablonski warned.

In a comment endorsed by several other stakeholders, Mark Gray of the Edison Electric Institute noted that a requirement to “authorize provisioning of access to BCSI based on need” is ambiguous and could be read to mean that entities are required to authorize access by anyone who asks, or have no discretion over which information can be accessed. He suggested that the phrase “process to” be added to the requirement, to clarify that each entity is responsible for defining its process for granting access.

Ambiguity was also a problem for respondents to the second question, with an anonymous commenter representing the Tennessee Valley Authority objecting that the “proposed language is too ambiguous and obligates entities to protect BCSI in any form, even [those] beyond [their] control.” For example, utilities could be held responsible for access to information being held by FERC or NERC. The commenter recommended that the language be “rescoped” to focus on managing access to information repositories, rather than the data themselves.

Mark Ciufo, writing for Hydro One Networks, also criticized the requirement for lack of clarity, observing that the standard “only [requires] managing physical access to BCSI,” while not explicitly stating that electronic access should be managed as well. Bruce Reimer of Manitoba Hydro agreed, pointing out that the standard’s requirements around the provisioning of physical access also seem inconsistent.

“If all unencrypted BCSI [is] stored on a server, does the server need to have authorized physical access? Obviously, the answer is ‘yes,’” Reimer said. “However, if using the provisioned access language, the BCSI server physical access control would be ignored. The provisioned access to BCSI is not clear.”

General Agreement on Cloud Services

Responses to the question about CIP-011-3 generally agreed that the most recent revisions “add clarity for protections expected when utilizing third-party solutions such as cloud services for storage purposes,” in the words of Jonathan Robbins of Seminole Electric Cooperative. However, many commenters felt the language could still be made more specific; for example, Jablonski and Russel Mountjoy of Midwest Reliability Organization called for the SDT to ensure that terms such as “data governance” and “data sovereignty” are fully defined in the text.

The 18-month implementation time frame likewise received widespread support, though some commenters supported a longer span: Richard Jackson of the U.S. Bureau of Reclamation called for a 24-month deadline, while TVA requested an extension to 36 months. By contrast, Jablonski said the revised standard would create “no significant new compliance requirements” and that, therefore, a six-month window would be more appropriate.