In last week’s post regarding FERC’s recent Notice of Proposed Rulemaking (NOPR)
for CIP-013-2, the NERC supply chain cybersecurity risk management standard, I
noted that FERC is apparently quite concerned that NERC entities aren’t properly
performing the three essential elements of any risk management activity:
1.
Identify risks. Of course, in the case of CIP-013, those are supply
chain security risks to the Bulk Electric System (BES). They primarily arise
through the vendors in the supply chain for intelligent hardware and software that
operate or monitor the BES, although they can also arise through the NERC
entity itself (for example, does the entity have a policy always to buy from
the lowest cost vendor, without being concerned with frou-frou like
cybersecurity?).
2.
Assess those risks. The whole point of risk management is that some
risks are very serious and need to be addressed as soon as possible, and others
are not important and can simply be accepted. The assessment tries to
distinguish high from low risks.
3.
Respond to those risks. FERC notes that CIP-013-2 only mentions
identifying and assessing risks, but never requires the entity to do anything
about them. It’s a sure bet that the order FERC issues sometime after the NOPR
comment period ends (in early December) will focus heavily on response.
The NOPR states that FERC proposes
to issue an order for NERC to revise CIP-013-2 (i.e., replace it with a new
standard, which will be CIP-013-3). Since FERC addresses each of the three risk
management elements separately in the NOPR, I’ll discuss them in three separate
posts, starting with risk identification in this post.
Probably the most important lesson
I took from my experience working with NERC entities during the runup to
compliance with CIP-013-1 was the difference between “vendor risk” and “vendor
risks”. By vendor risk, I mean the risk posed by the vendor itself. Vendor risk
is important when you’re considering whether to buy from a particular vendor at
all; for example, when you’re evaluating five vendors with a competitive RFP.
In that case, you ideally want to rank all five vendors by their overall level
of risk (although that’s hard to do in practice).
In the OT world (i.e., the world
that CIP compliance lives in), overall vendor risk isn’t usually a
consideration. This is because the decision which vendor to buy (for example) electronic
relays from is almost always “the same guys we’ve been buying from for the last
15 years”. Your relay vendor was chosen long ago for technical reasons, and your
organization is very familiar with their products. Only a huge screw-up by that
vendor would justify even talking to other vendors – and it still isn’t likely
you would drop them, unless they had done something horrendous.
There are various services that will
sell you risk scores for vendors, which are based on many factors (you can also
compute your own scores, of course). For those rare occasions when you might
switch vendors (or you’re starting to purchase a new type of product that you’ve
never bought before), overall vendor risk scores can be very helpful. But for
most OT procurements, vendor risk scores don’t help much. The engineers will
make the decision based on functionality. Even if one vendor has an overall risk
score that’s higher than another vendor’s, that’s not usually going to sway the
decision.
So, why do you need to “identify”
risks, if the decision which vendor to buy from was made long ago and won’t
change for just one procurement? It’s because the risks that apply to one
vendor can change substantially from one procurement to the next.
For example, suppose your
organization’s last procurement from Vendor A was a year ago. The vendor hasn’t
changed very much, but the environment certainly has. Let’s say that in the
past year, the SolarWinds attack happened. Before SolarWinds, your organization
never even considered whether a vendor maintained a secure software development
environment. This year, you decide you need to ask them questions like
1.
Do you require MFA for
access to your development network?
2.
How do you vet your developers?
3.
Do you utilize a
product like in-toto (an open source product) to verify the integrity of
your development chain?
Or, suppose Vendor A has recently
been acquired by Vendor B. Of course, they assure you up and down that they’re
still the same Vendor A you’ve known and (mostly) loved for the last ten years.
However, you decide that the safe path is to re-assess them before you start a
new procurement. Along with the questions you’ve asked them in previous
assessments, you add new ones like
A.
How have your security
practices changed since you were acquired?
B.
What security certifications
does Vendor B have? If you (Vendor A) don’t have one of them, when will you get
it?
C.
Will you merge your network
with Vendor B’s, and if so, what measures will you take to make sure there’s no
degradation of security controls?
All six of the above questions are
based on new risks; that is, you have identified these as risks that apply to
Vendor A, even though you’re not now even considering whether you want to
continue using them. You’ll keep using them, but at the same time you need to identify
all the risks that now apply to them, so you can pressure the vendor to
mitigate them if needed.
In other words, it isn’t a
question of whether Vendor A is now too risky to continue buying from. Rather,
it’s a question of what are the new risks that apply to A, that didn’t apply
the last time you bought from them? You’re not asking about Vendor A’s overall
risk level; you’re asking what new risks they may pose to you, that arose since
the last time you assessed them.
Any opinions expressed in this
blog post are strictly mine and are not necessarily shared by any of the
clients of Tom Alrich LLC. 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.
No comments:
Post a Comment