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 tom@tomalrich.com. And while you’re at it, please donate as well!
[i] The
idea of guardianship is my invention, not something FERC stated in Order 706.
[ii] I
believe that most CIP auditors will not issue a notice of potential violation in
a case where a NERC entity hasn’t applied a patch that clearly isn’t needed.
However, the strict wording of CIP-007 R2 doesn’t allow for such exceptions.
[iii]
NERC calls requirements like this “objectives-based requirements”. I think of
the two terms as being virtually synonymous, since it’s hard to achieve any
objective without considering risk, and risk usually arises along with attempting
to achieve an objective.
No comments:
Post a Comment