Can you accept risk in NERC CIP?

 

I haven’t been able to attend many of the meetings of the Risk Management for Third-Party Cloud Services Standards Drafting Team (SDT), which started meeting last fall. However, I was able to attend last Thursday’s meeting. I was quite pleased to see that the team is now starting to discuss some of the weighty issues that the group will have to address as they draft the new and revised standards that will be required to make full use of the cloud “legal” - for NERC entities with high or medium impact NERC CIP environments. The weightiest of these issues are those that have to do with risk.

In many ways, this SDT resembles the CSO706 (“Cyber Security Order 706”) SDT, which in 2011 started drafting the CIP version 5 standards. CIP v5 completely revised the framework that was in place for CIP versions 1-3. Those three versions were based on the concepts of Critical Assets, Critical Cyber Assets, and the Risk Based Assessment Methodology (which was the opposite of risk-based). In CIP v5, they were replaced with new concepts like Cyber Asset, BES Cyber Asset, BES Cyber System, the Impact Rating Criteria, Electronic Security Perimeter, Interactive Remote Access, Intermediate System, External Routable Connectivity, Electronic Access Control or Monitoring System, Physical Access Control System, and more.

Of course, when they started to work on CIP v5 in early 2011, the CSO706 SDT didn’t set out to discuss all of these concepts; instead, the need for the concepts arose from the team’s discussions of the problems with the then-current CIP v3 framework. In fact, the more controversial topics, like External Routable Connectivity and the meaning of the term “programmable” in the Cyber Asset definition, continued to be discussed - sometimes heatedly - in the 2 ½ years between FERC’s approval of CIP v5 in November 2013 and when the v5 standards came into effect (simultaneously with the v6 standards) on July 1, 2016.

So, I was pleased to find out yesterday that the “Cloud” SDT’s discussions have already ventured into the conceptual realm; the changes required to bring the NERC CIP standards into the cloud era (which almost every other cybersecurity framework entered at least a decade ago) will beyond a doubt require both new concepts and fresh thinking about old concepts. Any attempt to just start writing the new (or revised) requirements without first agreeing on the concepts that underlie them is guaranteed to be unsuccessful.

One of the many concepts that came up in Thursday’s meeting was acceptance of risk. Of course, in most areas of cybersecurity, it is almost a dogma that successful practice of cybersecurity requires being able to accept some risks. After all, there will always be some cyber risks that, for one reason or another, an organization can do nothing about. As long as the risk is accepted at the appropriate level of the organization, the organization has done all it can.

During the meeting, someone pointed out the need for NERC entities to be able to accept risk in cloud environments. I pointed out that the requirements in CIP version 1 almost all explicitly allowed for “acceptance of risk”, if the NERC entity decided that was a better course of action than complying with the requirement. However, FERC’s Order 706 of January 2008 approved CIP v1 but at the same time ordered multiple changes; these were at least partially incorporated into CIP versions 2, 3, 4, and especially 5.

One of the changes FERC mandated in Order 706 was for all references to acceptance of risk to be removed. FERC’s reasoning was that the purpose of CIP is to mitigate risks to the Bulk Electric System (BES). Each NERC entity that is subject to CIP compliance is essentially acting as a guardian[i] of the BES, or at least of whatever portion of the BES is owned and/or operated by the entity. Therefore, the risks addressed by the CIP requirements aren’t risks to the NERC entity. This means the entity doesn’t have the choice of whether or not to accept them – their role in the BES requires they not accept them.

However, not accepting a risk isn’t the same as not doing anything about it. Since no organization has an unlimited budget for risk mitigation, any organization needs to decide which risks it can afford to mitigate and which ones it can’t afford to mitigate. Often, those are risks with high impact but very low probability – e.g., the risk that a meteorite will crash through the roof of a building.

If there were a significant probability that this could happen, it would be worthwhile to strengthen roofs enough to deflect meteorites, at least up to a certain size. However, because the likelihood of this event occurring is tiny, most organizations have at least implicitly decided they will be much better off if they allocate their limited mitigation resources toward risks with a higher likelihood – hurricanes, tornadoes, hailstorms, etc.

Until CIP version 5 appeared, there were no CIP requirements that permitted consideration of risk: You had to do X or else face a fine. We now call these prescriptive requirements. With prescriptive requirements, it doesn’t matter if the requirement mandates actions that mitigate only a tiny amount of risk, while neglecting actions that might mitigate much greater risks but aren’t required; the NERC entity needs to perform the required actions first and leave the other actions for later, if time permits.  

One example of a prescriptive requirement today is CIP-007 R2 Patch Management. This requires the entity to apply every security patch released by the patch source for a particular Cyber Asset in scope for the requirement. It doesn’t matter if the software vulnerability addressed by the patch has already been mitigated in that Cyber Asset, for example by a firewall rule; the patch still needs to be applied.[ii]

Fortunately, the NERC CIP community seems to have learned its lesson regarding prescriptive requirements. CIP version 5 introduced the first of what I call risk-based CIP requirements, including CIP-007-5 R3 Malware Protection and CIP-011 R1 Information Protection[iii]. Since then, almost every new CIP standard or requirement has been risk-based.

Given that prescriptive requirements are usually tied to individual hardware assets and it is virtually impossible to pinpoint on which cloud asset a process is running at any one time, it is inevitable that cloud-based CIP requirements will be risk-based. In fact, as I mentioned at the end of this post, it seems to me that implementing risk-based requirements for the cloud may well require changes to the NERC Rules of Procedure. Stay tuned.

To produce this blog, I rely on support from people like you. If you appreciate my posts, please make that known by donating here. Any amount is welcome, but I would like all regular readers to donate $20 per year – consider that my “subscription fee”. Thanks!

If you would like to comment on what you have read here, I would love to hear from you. Please email me at [email protected]. And while you’re at it, please donate as well!