Note from Tom:
I have moved to Substack as my primary blgging platform. Please read the post here and join me as either a free or paid subscriber.
Note from Tom:
I have moved to Substack as my primary blgging platform. Please read the post here and join me as either a free or paid subscriber.
Note from Tom:
I have moved to Substack as my primary
blog platform. If you want to see all my new posts, as well as my 1200+ legacy
posts dating from 2013, please support me by becoming a paid subscriber to my
Substack blog. The cost is $30 a year. Thanks!
A few years ago, I came to realize two things:
a.
There are a huge number of (now over 300,000)
identified CVEs; and
b.
Some organizations have literally millions of intelligent
devices that utilize software and firmware that can harbor vulnerabilities.
Thus, the only way for all but the smallest end user
organizations to manage software vulnerabilities in all those devices is to have
a fully automated process. Below are the high-level tasks[i]
that I believe constitute vulnerability management:
One-time tasks (repeated periodically):
1.
Develop a CVE[ii]
risk score based on information about the CVE, including a) presence or absence
of the CVE in CISA’s KEV Catalog, b) CVSS Base score[iii],
c) current EPSS score[iv],
d) values of components of the CVSS vector string, etc. The organization needs
to decide how each of these scores (and any other information deemed important
by the organization, such as a measure of the criticality of a particular asset
to the organization’s mission, if they have one) is incorporated into the CVE
risk score.
2.
Identify a score that
is the “do not fix” threshold. The organization will normally not apply a patch
for a vulnerability whose risk score is below that threshold, although there
will always be cases in which the vulnerability needs to be patched regardless
of its score.
3.
Set up a database in which patches received from
software or firmware providers are cross-referenced with the products that are
reported to be vulnerable to that CVE. For example, if the record for
CVE-2025-12345 lists product A version 2.0 and product B version 3.7 as vulnerable
to the CVE, the user should be able to search the database for both
product/versions and learn that they are vulnerable to that CVE. Of course,
this capability is built into most asset and vulnerability management tools.
Ongoing tasks (repeated daily, if possible)
1.
To the extent
possible, identify the product name and version number of every software and
firmware product in use by the organization.
2.
To the extent
possible, identify a machine readable software identifier – usually CPE or PURL
– for each product/version in the inventory
3.
Search the National
Vulnerability Database (NVD) and other vulnerability databases for
vulnerabilities that apply to any of these product/versions.
4.
Assign a risk score to
each vulnerability identified, based on the previously agreed-upon formula.
5.
Discard any CVE whose
risk score is below the “do not fix” threshold.
6.
Match each patch
received from a software producer with the product/version(s) in the inventory,
to which that patch applies.
7.
Prioritize application
of applicable patches according to the amount of risk mitigated by each patch, as
measured by its risk score.
8.
Apply patches in order
of priority, if possible.
9.
If a patch cannot be
applied when it normally would be, determine what alternate mitigation(s) for
the vulnerability or vulnerabilities addressed in the patch might be implemented.
Leave those mitigations in place until the patch can be applied.
Until fairly recently (probably
last year), I thought that developing a tool to perform all these steps automatically
– i.e., by just setting some parameters and hitting “Start” - shouldn’t be
hard; I was quite surprised when I realized there are no such tools, although
there are lots of excellent tools that automate parts of this process (for
example, the open source Dependency
Track is used over 25 million times a day
to look up an open source component shown in a software bill of materials
(SBOM) in the Sonatype OSS
Index vulnerability database). I was even more
surprised to learn there doesn’t seem to be anyone working feverishly to be the
first to produce such a tool.
At first, I attributed this lack
of activity to security tool vendors not being aware of how important
vulnerability management is. However, after at least a decade of major attacks that
were enabled by unpatched software vulnerabilities - especially ransomware
attacks - it became clear that there must be some other reason for this lack of
tools.
Now the reason is clear as day to
me: There are major obstacles, especially regarding data quality, that inhibit almost
every step of the vulnerability management process. Of course, data quality is
a problem in lots of disciplines; for example, economic data are often flawed
and are never completely reliable (I used to work for an econometric
forecasting firm where the unofficial motto was “We show our forecast values to
six significant digits just to show we have a sense of humor”).
However, the data quality problem
in vulnerability management is of such a magnitude that in many cases, trying
to completely automate vulnerability management would most likely leave an
organization thinking they were much better protected than they really were, due
to all the false negative vulnerability information they would receive. Let’s look
at four of the above vulnerability management tasks, and consider just one of
the obstacles each task might face:
One-time tasks:
Task 1: All four of the data sources that I listed in this task (with
the possible exception of presence in the KEV Catalog) have been the subject of
lots of articles and blog posts stating that they are worthless for determining
the true risk posed by a software vulnerability. That doesn’t mean that CVSS,
EPSS, and KEV are in fact worthless; in fact, it’s certain that they have value
if they’re utilized properly. However, an automated tool is unlikely to
appreciate the nuance of “proper” utilization, meaning it’s not a great idea to
utilize these to measure risk in an automated tool.
But what other risk data are
publicly available and easy to access? Not much, so even though lots of
security professionals understand that for example CVSS scores don’t give a
true indication of risk, they stick with them as their measure of risk because
nothing better is readily available. It’s like the man who walks out of his
house at night and sees his neighbor on his hands and knees under the
streetlight, searching for something:
Man: “What are you looking for?”
Neighbor: “My car keys.”
Man: “Where did you have them last?”
Neighbor (gesturing toward dark
front lawn): “Over there.”
Man: “So, why are you looking for
them here?”
Neighbor: “The light’s better
here.”
Task 2: There is no good way to calculate the optimal “do not fix”
threshold, since there’s no way to assign measurable values to the costs and
benefits of using any particular value as the threshold, let alone comparing
multiple values.
I suspect that most organizations
say (in effect), “Our budget for patching vulnerabilities is $X. If we try to
patch every vulnerability we receive (equivalent to setting the threshold at
zero) for all of the software products we utilize, we will spend some huge
multiple of that. On the other hand, if we set the threshold at the maximum
value (meaning we won’t apply any patch we receive), we will greatly increase
our likelihood of being hacked. What’s the threshold value that will allow us
to stay within our budget, yet still apply what an auditor will believe is a
reasonable percentage of the patches we receive?”
This reasoning makes sense in the world
in which we live, although it doesn’t make sense in an ideal world in which
cybersecurity measures need to be as comprehensive as possible, cost be damned.
But what organization on the planet – outside of, perhaps, the military or a
nuclear safety agency – could possibly even consider following the latter
course?
Ongoing tasks:
Task 2: I have written a lot of blog posts on the two most widely
used machine-readable software identifiers: CPE and PURL. While PURL is a very
accurate identifier, it currently can only identify open source software
distributed through package managers – which is not how most government and
private organizations obtain the software they use. CPE, on the other hand, is
a very unreliable identifier, due in part to reasons identified on pages 4-6 of
this white paper by the OWASP SBOM Forum; however, it does identify
commercial software.
Thus, for commercial software, there
is no reliable machine-readable identifier (although there is a proposal on the table to extend PURL to cover commercial as well as
open source software). This means that looking up a commercial product in the
NVD, or another database based on the NVD, is unlikely to display a CVE if the CPE
included in the CVE record doesn’t exactly match the one being searched for –
even if both CPEs refer to exactly the same product. In other words, searching
for vulnerabilities in the NVD yields an unacceptable number of false negative
findings.
Task 3: Besides the problem with CPE just mentioned, there is an
even greater source of unreliability when it comes to vulnerability databases
based on the CPE identifier (primarily the NVD, of course). The additional
unreliability is due to:
a.
As stated above, to
locate a software product in the NVD, a fully automated process requires that the
CPE number entered exactly match the CPE number of that product in the
NVD.
b.
As I’ve just pointed
out, CPE is an inherently unreliable identifier. This is primarily because of
two fields in the CPE spec: “product” and “vendor”. Both products and vendors
have many names at different times and different contexts. A friend of mine
once asked people who worked for Microsoft the name of the company they worked
for; she received over 20 different answers.
c.
The only way for a
fully automated process to find a product in the NVD is to create a CPE name
that follows the CPE specification, then search on that name. CPE names are originally
created by the NVD, which employs contractors to perform this task (the NVD is
part of NIST, which is part of the Department of Commerce). When they create a
CPE name (which currently is for only about half of new CVE
records), they have to make choices like whether
the vendor name should be “Microsoft”, “Microsoft Europe”, “Microsoft, Inc.”,
“Microsoft Inc.”, etc. Using any one of these options will produce a different
CPE name from all the others. The NVD has no official guide to making these
choices, so the contractor just takes their best guess regarding which to include
in a particular CPE name.
d.
Thus, when an
automated tool searches for a Microsoft product in the NVD or one of the other
databases based on the NVD, it needs to guess which choice the contractor made
for the vendor name. Of course, if there are one hundred options for
Microsoft’s name (and I’m sure there are many thousands, when you consider companies
Microsoft acquired, software versions in other languages, name changes for
marketing purposes, etc.), the tool will have only a 1-in-100 likelihood of
making the right choice.
e.
Even worse, when the
searcher’s CPE name for the product doesn’t match the one the NVD contractor
created (perhaps years ago), the searcher will receive the message, “There are
0 matching records”. This is the same message the searcher would receive if they
had guessed the correct CPE name, but no vulnerabilities had been reported for
that product. Of course, most people will take the more favorable
interpretation and assume that no vulnerabilities have been reported in the
product. Because of this, they may not apply a patch issued for the product,
since they think it's not needed. This is probably the biggest danger posed by
false positive vulnerability findings.
What’s the answer to the question in the title of this post? Just based on the obstacles I’ve pointed out in this post, the answer is clearly “No”. There are a lot more obstacles to discuss in future posts.
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 or
comment on this blog’s Substack community chat.
I’m now in the training business! See this
post for more information.
[i]
There could be a lot more steps in this list, depending on what a vulnerability
management program applies to.
[ii]
There are other types of vulnerabilities than CVE, including OSV, GitHub
Security Advisories (GHSA), CISA’s ICS Advisories (ICSA), etc. However, there
are far fewer of each of these other types than there are CVEs; plus, the other
vulnerability types are often directly mapped to a CVE, meaning that a comprehensive
CVE management program is likely to include them anyway.
[iii] The
CVSS score is composed of three Metric Groups: Base, Temporal and
Environmental. The CVSS scores published in the NVD just include the Base group.
Temporal group metrics change over time, while Environmental metrics tailor the
score to a specific user's context. If an organization wishes to use the latter
two metric groups, they will normally have to create and include them in the CVSS
scores themselves.
[iv]
Since the EPSS scores for all 300,000+ CVE records are updated daily by
FIRST.org, it is always a good idea to use the most recent score available.
Since my new Substack blog is off to a good start and most of my readers have switched to reading posts there, starting on October 15 I will no longer put up new posts on this site (Blogspot). If you are a subscriber to this site, you have been automatically provided a free subscription on Blogspot; you should be receiving an email from both sites every time I put up a new post. As a way to show your support for me, and also to allow you to access the 1200+ legacy posts (written between 2013 and this past August) on the Substack site, please consider upgrading your free subscription to a paid one for $30 per year, or a founding subscription for $100 the first year.
If you aren't now receiving the posts by email from Substack, that means you're not a subscriber there. Please go to the link above and sign up as a free, paid or founding subscriber.
I have recently signed up as a Speaker for the fast-growing compliancewebinars.com site; I will be delivering live and recorded webinars on NERC CIP and on vulnerability management (and perhaps other topics in the future). Here is how it works:
1. I have initially committed to
delivering ten different webinar topics, which are listed below, with a link for
more information and to sign up. A webinar is tentatively scheduled for each of
those topics. All webinars are 90 minutes long, including 15 minutes of
Q&A.
2. At all the links below, you can enroll
in the webinar described at the link, delivered at the scheduled time. You can sign
up as an individual or as a group (multiple people from one organization).
3. The members of a group (usually a
company) will be able to attend a webinar from different connections (i.e.,
they don’t all have to be gathered around one screen).
4. Each webinar listed below is currently
scheduled, but it will only be presented if there are three or more attendees
signed up. Note that a group counts as one attendee. So, if you have a group of
four or more that wants to attend a webinar, it would be smart to have two members
of the group sign up as individuals. That way, the webinar will definitely be
held.
5. Of course, any money you have paid
will be refunded if the webinar isn’t held, although you will also be offered a
voucher good for any other webinar (presented by any Speaker, not just me) over
the next year.
6. You can also sign up for a link to
the recording of a webinar. The link will be for you only, but you can view the
recording as many times as you want. Another
option is to sign up for a “Combo” of both the live webinar and the recording.
7. When a group signs up for a
recording, all members of the group can view it through a link with a password.
The password will expire in six months.
I hope to
see you at one of the webinars! Please email me if you have any questions.
Webinars on NERC CIP:
History
and Future of NERC CIP
NERC
CIP-013, the Supply Chain Cyber Risk Management Standard
NERC
CIP-011, BCSI and the Information Protection Program
Introduction
to the North American Electric Reliability Corporation (NERC)
The
six NERC Regional Entities (REs)
Introduction
to the Federal Energy Regulatory Commission (FERC)
Webinars on Vulnerability Management:
What
is the National Vulnerability Database (NVD)?
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 or
comment on this blog’s Substack community chat.
Note from Tom:
I have moved to Substack as my primary
blog platform. If you want to see all my new posts, as well as my 1200+ legacy
posts dating from 2013, please support me by becoming a paid subscriber to my
Substack blog. The cost is $30 a year. Thanks!
Last Thursday, FERC released new orders related to CIP-013 and CIP-003 respectively. I’ll
discuss the CIP-003 order in a future post. Before I discuss the CIP-013 order,
which is officially a Final Rule, here’s some important background information:
1.
FERC ordered NERC to develop a “supply chain
cyber security risk management standard” in July 2016. They gave NERC only one
year to develop and fully approve the new standard. Since just approval of a
new CIP standard usually requires a full year (including four ballots by the
NERC Ballot Body, plus a comment period of more than a month between each pair
of ballots), you can see this is lightning fast by NERC standards. FERC did
this because they could see that supply chain security attacks – of which there
had been very few at that time – would soon rapidly increase, both in numbers
and magnitude.
2.
FERC turned out to be right about the attacks
(think SolarWinds,
Kaseya,
XY
Utils, and more). However, to meet FERC’s unrealistic one-year goal, the
NERC Standards Drafting Team (SDT) had to make CIP-013-1 as
bland as possible, so they could obtain the necessary expedited approval by
the NERC Ballot Body.
3.
CIP-013-1 became enforceable on October 1, 2020.
FERC auditors, who reported
in 2023 on CIP-013 audits they had led, stated (on page 17), “While the
requirement language obligates entities to develop a supply chain risk
management plan with various characteristics, it does not mandate that the plan
apply to contracts that were in effect at the effective date of the Reliability
Standard.” Since the most important OT contracts are almost always multi-year,
this meant that some of the most important supply chain risks were originally deemed
by many NERC entities to be out of scope for CIP-013-1 compliance, even though there
was nothing in the wording of CIP-013-1 Requirement R1 suggesting that risks
from existing suppliers should (or even could) be ignored.
4.
FERC’s 2023 report continued, “Additionally, the
standard does not require the plan to incorporate responses to the risks
identified by the entity in the plan except in limited circumstances
(Requirement Part 1.4.2[i]).”
This was the most mystifying omission in CIP-013-1: the fact that it requires
the entity to “identify and assess” supply chain risks, but not to do anything
about the risks they’ve identified. It’s like you saw a runaway truck barreling
toward you in the street but you decided not to move out of the way, since the
law doesn’t require you to do that. I wrote about this issue in several posts
in 2019 and 2020, culminating in this
one.
FERC’s NOPR
In September 2024, FERC issued a Notice of Proposed
Rulemaking (NOPR) that laid out their concerns about CIP-013-1 and CIP-013-2 (version
2 added EACMS and PACS to the scope of CIP-013-1 but left the rest of the
standard unchanged). I wrote this
post about the NOPR. Since it’s a long post (surprise, surprise!), I recently
boldfaced three paragraphs that I consider especially important. However, the
whole post is still quite relevant, if you have time to read it.
In the NOPR, FERC identified two problems they were
considering ordering NERC to correct. The last sentence of paragraph 2 on page
3 describes these problems as, “(A) sufficiency of responsible entities’ SCRM[ii]
plans related to the (1) identification of, (2) assessment of, and (3) response
to supply chain risks, and (B) applicability of SCRM Reliability Standards to
PCAs[iii].”
Indeed, the Final Rule released last week requires NERC to act in both of those
areas.
What actions did FERC require NERC to take? To take item (B)
first, there weren’t any objections (in the filings received by FERC in
response to the NOPR) to including PCAs in the scope of CIP-013-2. This was probably
because
i.
Since a PCA is always installed on the same routable
protocol network as a component of a BES Cyber System (BCS), common sense seems
to dictate that it should receive the same level of protection as the BCS; and
ii.
Often, the same type of asset - such as an
electronic relay - might be a BCS component in one case, but not in another
case. The NERC entity is unlikely to use a different supplier for relays used in
the first case than relays used in the second case, so including PCAs to the
CIP-013 scope will not usually add much to an entity’s compliance workload.
Regarding item (A), FERC lists three NERC actions that they
considered ordering, although in fact they only ordered two of them in their
Final Rule last week:
1. To address the issue of NERC entities not
identifying risks that were due to suppliers whose contracts predated the
effective date of CIP-013-1 (October 1, 2020), NERC considered (and asked for
comments on) the idea of setting a maximum time between risk assessments for a
vendor – for example, a NERC entity would need to repeat a risk assessment for
a vendor every three years. Thus, if a vendor’s contract had started on for
example September 1, 2023, the vendor would need to conduct a new risk
assessment by September 1, 2026.
This idea drew criticism from some commenters, but FERC
decided to go ahead with it anyway. However, they changed it in one important way:
They will let the Standards Drafting Team leave it to the individual NERC
entity to decide what interval between risk assessments is appropriate. FERC
also said the SDT could allow the entity to identify more than one interval,
based on criteria they identify (for example, risks for software products are
likely to change more rapidly than risks for devices. This means the mandatory
assessment interval for a software product might be shorter than the interval
for a device).
2. In their NOPR, FERC suggested they might require
NERC entities to verify cybersecurity information that a supplier provides, for
example, in response to a questionnaire from the entity. Since this would be
almost impossible for a NERC entity to do without having to pay big bucks to
get a major auditing firm to audit the supplier, I wasn’t surprised that the
comments FERC received on this issue were mostly negative. I was also pleased
that FERC realized this was a bad idea and dropped it.
3. The third and final question on which FERC’s NOPR
solicited comments was “whether and how a uniform documentation process could
be developed to ensure entities can properly track identified risks and
mitigate those risks according to the entity’s specific risk assessment.[iv]
CIP-013-2 Requirement Part R1.1 states that the Responsible
Entity must “identify and assess cyber security risk(s) to the Bulk Electric
System from vendor products or services…” Notice that the word “mitigate” was
left out here, even though it should have been included (the Purpose of CIP-013,
listed in item 3 on the first page of the standard, is “To mitigate cyber
security risks to the reliable operation of the Bulk Electric System (BES) by
implementing security controls for supply chain risk management of BES Cyber
Systems”).
I’ve heard that more than a few NERC entities, whether or
not they noticed that “mitigation” was missing from Part R1.1, acted as if it
was missing. That is, they diligently sent out security questionnaires to
suppliers, but then either a) paid little or no attention to the responses, or
b) evaluated the responses and noted which were unsatisfactory, yet never
contacted the supplier to find out when and how they would mitigate that risk.[v]
As you may have guessed, FERC’s Final Rule mandates that the
revised version of CIP-013 (which will be CIP-013-3, of course) require NERC entities
to identify, assess and mitigate vendor risks. However, FERC worded this
a little differently. They stated (in paragraph 53 on page 33), “…we adopt the
NOPR proposal and direct NERC to develop and submit for Commission approval new
or modified Reliability Standards that require responsible entities to
establish a process to document, track, and respond to all identified supply
chain risks.”
In other words, instead of mandating that CIP-013-3 require NERC
entities to “identify, assess and mitigate” supply chain risks to BCS, EACMS,
PACS and (soon) PCAs, FERC wants entities to “document, track and respond” to
those risks. In practice, these amount to the same thing. Nobody can document
and track a risk without also identifying and assessing it. Moreover, responding
to a risk is the same as mitigating it, since responding by doing nothing at
all about a risk will no longer be an option in CIP-013 compliance.
Risk identification
As I’ve already implied, I consider CIP-013-1 and CIP-013-2
to have been largely a failure, at least in relation to what they might have
been, if FERC had given NERC more time to develop and approve the standard. Fortunately,
FERC is giving NERC 18 months to develop and approve CIP-013-3; I consider that
an improvement, but 24 months would have been even better. This is because CIP-013
was the first what I call risk-based CIP standard (NERC calls these objectives-based
standards, which in my opinion amounts to almost the same thing). Since the
drafting team in 2016 didn’t have the time to consider what should be in a
risk-based standard, the new drafting team will need to do that.
CIP-013 was risk based because FERC’s Order 829
of July 2016 specifically called for a “supply chain risk management”
standard (my emphasis). FERC contrasted this with a “one size fits all”
standard - i.e., a prescriptive standard that doesn’t take account of risk at
all. Of course, in 2016 and even today, most of the CIP requirements are prescriptive,
not risk based. But I want to point out that there doesn’t seem to be any real
debate in NERC CIP circles anymore about which type of requirement is better.
Cybersecurity is a risk management discipline, so cybersecurity standards need
to be risk based. In fact, since CIP version 5 came into effect in 2016,
literally every new CIP standard and requirement has been risk based.
The biggest problem with the first two versions of CIP-013
is they require the NERC entity to “identify” supply chain cybersecurity risks,
but they provide no guidance on how to do that. This means that a NERC entity could
literally comply with CIP-013 R1.1 – which requires the NERC entity to create a
supply chain cybersecurity risk management plan – by writing “Supply Chain Cybersecurity
Risk Management Plan” at the top of a sheet of paper, then writing below that, “We
couldn’t identify any supply chain security risks at all; therefore, we have
not taken any further steps required by this standard.” It would be very hard
for the auditors to issue a “potential non-compliance” (PNC) finding for this.[vi]
The comments cited in FERC’s order last week make it clear
that NERC entities want guidance on how to “identify” supply chain security
risks. Since such guidance was missing in CIP-013-1 and CIP-013-2, I’m sure the
legal staff at utilities told the CIP compliance people not to identify any
risks beyond those behind the six mandatory controls listed in CIP-013
Requirement 1 Part 1.2. Of course, it’s a cardinal rule of regulatory legal
practice not to expose the company to compliance risk beyond what is necessary.
I’ve been talking with CIP compliance people since 2008,
when FERC approved CIP version 1, and I can attest that most of them prefer to
comply with challenging CIP requirements than with watered-down CIP requirements
or no CIP requirements at all. However, lawyers must protect the company (or
the cooperative or the municipal utilities department); that requires reducing
the compliance footprint as much as possible, which in turn precludes going beyond
the strict wording of the requirement. By the same token, NERC CIP auditors can’t
audit a requirement that just says the entity must “identify risks”, without
giving any guidance on how that can be done. In other words, CIP-013 R1 was foreordained
to fail.
The new drafting team can break this cycle by adding some “meat”
to the risk identification bones of the current CIP-013-2 R1.1. What the team shouldn’t
do is choose an existing risk management framework like NIST 800-161r1, “Cybersecurity
Supply Chain Risk Management Practices for Systems and Organizations” and require
NERC entities to “comply” with it. Risk management frameworks are meant to
cover the waterfront, as one glance at 800-161 will reveal. Only the largest
organizations could dedicate the resources required to address all the
provisions in that framework.
Instead, I think the new SDT should make it clear that the Responsible
Entity needs to identify (say) ten important supply chain cybersecurity risks
and just focus on those. In fact, they might suggest that the entity choose ten
important risks from the North American Transmission forum’s (NATF) Supply
Chain Security Criteria, which is my favorite “risk registry” for OT[vii]
supply chain risks to the electric power industry.
While I used to think differently, I now realize it’s
impossible to even itemize all the most important supply chain security risks,
let alone mitigate a good portion of them. If you don’t currently maintain and utilize
a supply chain security risk registry, it’s better to start somewhere
than to wait until your organization has the resources and knowledge to develop
a comprehensive risk management program, which may never happen.
Fortunately, since it will be a couple of years before taking
this approach is mandatory, you have some time to try this out. You also have
an incentive, since if you work for a NERC entity with a high or medium impact BES
environment, you’re supposed to review and update your CIP-013 supply chain
cybersecurity risk management plan every 15 months. Instead of keeping your
plan as is, why don’t you find 5-10 risks that you can identify, assess and mitigate?
At least, if you make a mistake, you won’t be facing a PNC (potential non-compliance)
finding.
I’ll be glad to discuss this with you. Please drop me an
email.
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 or comment on this blog’s Substack community chat. If you would like to join my CIP Cloud Risks Working Group described in the italicized paragraphs at the end of this post, please email me.
[i] There
is no Requirement Part 1.4.2 in CIP-013-1, but there is a Requirement Part
1.2.4. This might have been what FERC was referring to.
[ii]
Supply chain risk management.
[iii] PCA
stands for “Protected Cyber Asset”. These are Cyber Assets that don’t meet the
definition of BES Cyber Asset, but which are installed on the same routable network
as a BCA, or any component of a BES Cyber System. If compromised, they could be
used to launch an attack on the BCS components on the same network.
[iv] Quotation
from paragraph 49 on page 30 of FERC’s Final Rule.
[v]
There’s a third possibility here: A NERC entity accomplished a) and b), meaning
they got the supplier to confirm they had a security deficiency and promise to
fix it. However, they never c) contacted the supplier again – more than once if
necessary - to make sure they followed through on their promise. It’s important
that a NERC entity accomplish all these steps for every supplier risk that was
identified through a questionnaire, audit, news story, etc.
[vi] I’m
sure this scenario hasn’t happened and won’t happen. However, I hear there are
many NERC entities whose plan consists entirely of putting in place the six
controls listed inCIP-013 Requirement 1 Parts R1.2.1 to R1.2.6. Since those six
controls are mandatory, many NERC entities decided they were the only risks
that they needed to identify in their supply chain cyber risk management plans,
when in fact that wasn’t t why they were included in the standard. Those six
controls were called out at random places in FERC’s 2016 order; the drafting
team just gathered them into one Requirement Part. They were never meant to
constitute the entire set of supply chain cybersecurity risks that NERC
entities need to include in their plans.
[vii] For
CIP-013 compliance, it’s important to identify OT supply chain risks. What I call
“IT risks” (like those found in the NIST CSF and NIST 800-161) focus on
protecting confidentiality of data. While that’s very important for banking OT
systems, it’s not important for power industry OT systems, where availability
and integrity are much more important.
Note from Tom:
I have moved to Substack as my
primary blog platform. If you want to see all my new posts, as well as my 1200+
legacy posts starting in 2013, please support me by becoming a paid subscriber
to my Substack blog. The cost is $30 a year. Thanks!
The “Links” section of Dale Peterson’s weekly newsletter today
contained this bullet point: “MITRE’s
Project Homeland is trying to map US critical infrastructure.” Even
though mapping critical infrastructure is a worthwhile goal that could bring
lots of benefits, I must admit that, when I saw this, a bunch of red flags
immediately appeared in my field of vision. After all, wouldn’t a map of US
critical infrastructure be an early Christmas present for Valdimir Putin, Xi Jinping,
and Kim Jong-Un?
I started to read the article, expecting to be quickly
reassured that the leaders of this project, MITRE Corporation (whom I praised in
my post just yesterday
– for something completely different, of course) have security considerations
firmly in mind and are going out of their way to protect this treasure trove of
critical infrastructure data. I was reassured when I read the second and third paragraphs:
“As MITRE’s senior principal scientist, Philp has spent four
years working to understand how America’s critical infrastructure systems are
interconnected and where they’re most vulnerable.
“We’re more at risk today than we were in 2001,” said Philp,
who has spent much of his career working on infrastructure vulnerability
assessments. “The question is, with less money, how do we reduce the greatest
amount of risk?””
However, I was soon disappointed. Here are some further
quotes, in the order in which they appear in the article (my comments are in italics).
What emerged was something unprecedented: a spatial knowledge
graph that could power dynamic visualizations showing exactly where critical
infrastructure exists, how it’s all connected, and where those connections
create the greatest vulnerabilities. (my emphasis)
* * *
“The sheer number of infrastructure points and the intricate
web of connections among them were staggering…The graph revealed not only the
complexity but also enabled staff to see each entity, such as a hospital, in
isolation related to its dependency on water and power.”
When you’re talking about power connections, you need to
be quite clear about what you mean. You could say that, within each
Interconnect in North America (the four are the Eastern Interconnect, Western
Interconnect, ERCOT – which covers a large part of Texas - and Quebec) every
power source, no matter how mighty, is “connected” to every residence, no
matter how humble.
Of course, if you include each of those connections in your
map, or even just the major ones, the map will be close to black with power
connections. However, if you ask the really important question, “How many hospitals
will lose power – or at least have to go on backup generation – if there’s a
total outage at Grand Coulee Dam (the largest power source in North America)?”,
the answer should usually be “None”.
This is because each Interconnect has lots of redundancy
built into it. It’s the job of the ISOs/RTOs
and the Reliability Coordinators to make sure that, at literally every second
of the day and night, there are backup power sources (and preferably backups of
backups) ready to cover for every possible contingency – such as a power plant unexpectedly
going down at that moment. Utilities are closely monitored for how good a job
they do of keeping the lights on.
On the other hand, there’s certainly some combination of
power sources, the loss of which would bring down a substantial number of – say
- hospitals in one of the Interconnects. If you’re trying to cause such an
event, MITRE’s map would probably be very helpful.
* * *
The map and graph together shed light on not just
infrastructure networks but also human networks such as the highly skilled
workers who maintain the infrastructure. The graph can reveal who works with
whom, while the map shows where they work and can even track their location in
real time.
* * *
The team gathered detailed data about critical infrastructure
and then used graph data science tools in ArcGIS Knowledge to analyze
dependencies, revealing the web of vulnerabilities from the national scale down
to individual city blocks. In Fort Lauderdale, for example, the system could
show how a flood affecting one neighborhood’s electrical substation might upset
water treatment systems, hospitals, and emergency services across the region.
Of course, the effects of a flood in a substation would be
similar to those of a cyber or physical attack on the substation. The most
chilling example of the latter is the Metcalf attack.
My guess is that, if someone writing the article had asked MITRE
what risks the map itself might pose, they would have been assured that the
risks were very low, since each of these assets is very well protected against
both cyber and physical attacks. Moreover, the map doesn’t reveal IP addresses,
firewall types, or any other information that could be used to launch an attack
on one or more assets.
That is most likely true, but it completely misses the main
point: The map itself, if it fell into the wrong hands, might be a great tool
for plotting a massive physical or cyber attack on the grid. For example, you
might use the data from the map to answer the question, “Which generating
facilities and substations would we need to take out, to bring down most of the
hospitals in City X?”[i]
I’m sure there’s not enough data to get an exact answer to this question, but at
least the map will put you on the road to having that answer.
Were there any statements in the article that warned of the
dangers of gathering so much critical infrastructure information in one huge
map? Not even one. The closest to a warning statement that I found was this one:
“MITRE needs cutting-edge technology from trusted partners—like Esri—that are
committed to protecting sensitive customer data.” This isn’t a warning about
the map at all, but just a pledge to protect sensitive data of the users of
ESRI’s software.
I’m not saying that MITRE should
abandon this project, since the map will be incredibly useful in the case of
physical disasters like hurricanes. But they obviously need to start thinking
about how they’ll protect access to the map itself, not just “sensitive customer
data”. This isn’t a map of risks; rather, the map itself is the risk.
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 or comment on this blog’s Substack community chat.
[i] Why
would someone want to execute such an attack? Certainly, a terrorist might want
to. But what’s often overlooked is the opportunity to make money in financial
markets by short selling for example healthcare stocks or municipal bonds,
before launching an attack like that.
Note from Tom:
I have moved to Substack as my
primary blog platform. If you want to see all my new posts, as well as my 1200+
legacy posts starting in 2013, please support me by becoming a paid subscriber
to my Substack blog. The cost is $30 a year. Thanks!
Last week, my friend Patrick Garrity of VulnCheck – the most respected
vulnerability researcher cum skateboarder in the world – posted
on LinkedIn about a paper that CISA put out last week titled “CISA
Strategic Focus: CVE Quality for a Cyber Secure Future”. The paper
describes what CISA would like to do to improve the CVE Program. For a short
101-level overview of that program, go here.
Since the CVE Program isn’t run by CISA, you may wonder why CISA
is concerned about improving the program. The answer is that CISA fully funds
the CVE Program, although it is operated by the MITRE Corporation, a
(nonprofit) Federally-Funded Research and Development Center, under the
direction of the Board of the nonprofit CVE.org.
CISA fully funds MITRE’s contract, which costs, as I’ve heard from different sources,
somewhere between $44 and $57 million per year.
On April 15, the international vulnerability management
community was shaken by a letter sent by MITRE to the members of the CVE.org
board; the letter indicated their contract wasn’t going to be renewed by CISA
and the program would have to shut down the
next day. The letter caused a veritable firestorm of concern and criticism,
which immediately bore fruit. By the next day, MITRE announced that
everything was hunky-dory again, since the contract had been extended after
all.
But everything really wasn’t hunky-dory. The fact that the
contract had almost been cancelled and that CISA was (and still is) planning to
cut a lot more people, led me and many others to conclude that it was close to
certain the contract won’t be renewed next March (don’t ask me why the renewal
was in April this year but will be in March next year. Such questions are above
my pay grade).
Fortunately, literally at that moment a white knight
appeared on the horizon, in the form of a new international non-profit organization
called the CVE Foundation. The
Foundation’s Board is comprised entirely of longtime members of the CVE.org Board,
including Lisa Olsen of Microsoft (an important contributor to the CVE Program,
who is also now Executive Director of the Foundation), my friend Pete Allor of
Red Hat, and Dave Waltermire of NIST. I was quite impressed
when their lineup was finally announced a few weeks after April 16, the day the
Foundation was officially launched.
The Foundation’s board members have all been in the thick of
discussions about what’s needed in the CVE Program during the 25 years that CVE
records have been reported and disseminated. In fact, one of those board
members has been involved with CVE since 1999 (that was the year CVE records
started to be disseminated. That year, around 350 CVEs were identified. This
year, probably around 45,000 new CVEs will be identified – and those are still
just the tip of the iceberg). While the board members haven’t put out a plan
for the changes they want to make, I know they’re already working hard on them.
However, there’s something else that the Foundation’s board
members have been working on: fundraising. They have been approaching private
organizations and government agencies worldwide and are getting a great
response. They already have a lot of funds committed; they’re sure they will have
more than enough funds available when it comes time to buy out MITRE’s contract
next March.
Which brings me back to CISA. They are now making a big
effort to make amends for their mistake in April and are campaigning
hard to keep the CVE Program under their belt. Their document describes a
lot of nice things they pledge to maintain or put in place. Here are three of
them.
1. Good governance
Without naming the CVE Foundation, CISA’s document attacks the
Foundation’s proposal to take over funding and running the CVE Program – in partnership
with MITRE. They call this “privatization” and imply that governance would
suffer because the Foundation won’t be able to ensure “conflict-free and vendor
neutral stewardship, broad multi-sector engagement, transparent processes, and
accountable leadership.” Given the chaotic history of CISA since the new
administration came in, including the many threats to close the agency
entirely, the complete elimination of entire programs (and their staffs)
without any attempt to demonstrate why this was necessary, and most importantly
the outright hostility exhibited to longtime employees before they were
terminated (as if they were doing something wrong just by being employed by
CISA), this assertion seems a little out of place.
2. “Public good”
The second section of CISA’s document includes these two
sentences: “Privatizing the CVE Program would dilute its value as a public
good. The incentive structure in the software industry creates tension for
private industry, who often face a difficult choice: promote transparency to
downstream users through vulnerability disclosure or minimize the disclosure of
vulnerabilities to avoid potential economic or reputational harm.”
Essentially, this is saying that accepting money from software
companies – along with government agencies from all over the world, nonprofit
foundations, and many other types of organizations – will inevitably corrupt the
CVE Foundation, since software companies face the “difficult choice” of whether
to disclose vulnerabilities.
I don’t deny that software companies face that choice, but I
can attest that at least the larger software companies (who produce a huge
percentage of all commercially available software products) have almost all
made the choice for the side of Virtue, since they’re the biggest advocates for
(and funders of) software security. In fact, I’m sure that over 95% of CVE
records are generated by either
1.
A CNA that works for the software company (or open
source community like the Linux Foundation or GitHub) that developed or
supports the software (e.g., Microsoft, Oracle, HPE, Red Hat, Cisco, Siemens,
Schneider Electric, etc.), or
2.
A CNA that the developer approached to create
the record (usually because the developer is in the CNA’s “scope”).
In fact, on the second page, CISA writes, “Many in the
community have requested that CISA consider alternative funding sources. As
CISA evaluates potential mechanisms for diversified funding, we will update the
community.” Of course, given the extreme pressure on the entire federal
government to cut costs as much as possible, it’s quite understandable that CISA
would want to look for alternative funding sources. Setting aside the question
of whether they would be allowed to accept funding from outside the government
(see below), it’s worth noting that one of the most likely prospects to help
CISA out is…you guessed it: large software companies.
3. Dump MITRE?
Patrick Garrity pointed out in his LinkedIn post that CISA’s
document never mentions MITRE. Patrick speculates this means CISA is
considering not renewing MITRE’s contract next March, even though they clearly want
to keep the CVE program going. Unfortunately, CISA is deluded if they think
they can keep the program going by themselves, let alone improve it. MITRE staffs
the whole CVE Program now (along with many volunteers, most notably the 470+ CVE Numbering
Authorities). They have been running the program since 1999, when two MITRE
researchers came up with the CVE idea and described it at a conference.
The MITRE team reports to the Board of Trustees of the
nonprofit CVE.org; that board includes
representatives from government (including CISA and the National Vulnerability
Database - NVD), as well as private industry (as mentioned earlier, the entire
board of the CVE Foundation consists of current members of the CVE.org board).
While there are certainly things MITRE has not done well in their many years
running the CVE Program, it would be hard to find anyone knowledgeable about
the situation who says MITRE’s work hasn’t overall been good, if not excellent.
Of course, I’m sure CISA management thinks they can do
better than MITRE at running the program. If they drop the MITRE contract, they
will presumably have a lot of money available to lavish on their own people. One
of those people was Edward Coristine. He was listed as a Senior Advisor to CISA
in February, having been installed by the “Department of Governmental
Efficiency” or DOGE (Coristine had a famous nickname that I can’t repeat here,
since this is a family blog).
Mr. Coristine had success
in the cybersecurity field while still in high school (which wasn’t long
ago, since he was 19 when he was at CISA. He’s either 19 or 20 today). He must be
quite good at whatever he does, since his company, DiamondCDN, was complimented
by a customer called EGoodly. They posted on Telegram, “"We extend our
gratitude to our valued partners DiamondCDN for generously providing us with
their amazing DDoS protection and caching systems, which allow us to securely
host and safeguard our website…”
What kind of company, pray tell, is (or was) Egoodly? They
were described by Reuters (in the article linked above) as “a ring of
cybercriminals”. Perhaps I’m old-fashioned, but it doesn’t seem to me that
someone who has done work for cybercriminals should be installed as a senior
advisor to CISA (with access to their most sensitive systems, of course). At
the very least, one would expect that CISA’s (and DHS’s) management team would
have requested a background check first – and if it was refused, they would
have refused to give Mr. Coristine access to any system, except perhaps the cafeteria
menu system. But it seems there was no background check.
Of course, I’m sure that CISA management last February and
March was under tremendous pressure to do whatever DOGE told them to do. Even
if DOGE demanded system access for Vladimir Putin, it would probably have been
granted. I guess we can at least be happy that didn’t happen.
Nevertheless, I think this incident alone should disqualify
CISA from taking over operation of the CVE Program from MITRE next year. The
CVE Foundation is much more qualified, experienced, and connected than whoever
happens to be in charge of CISA this month. They will be able to raise much
more money than CISA could raise on their own – even if CISA were allowed to
raise money from private sector organizations (of course, they’re not. That’s
known as bribery). And of course, whatever money CISA has today may very well
be gone tomorrow. That’s how things happen in Washington nowadays.
Most importantly, the CVE Foundation will build on MITRE’s vast
experience, starting with their “invention” of CVE. I know for a fact they won’t
let MITRE just continue to do the same old same old, but I also know for a fact
that the MITRE staff members I know are quite motivated to make improvements
(and they’re continually making them now); they also don’t want the same old
same old. Next year, working with the CVE Foundation, they’ll continue to make
improvements, and even pick up the pace. The CVE Foundation is making big
plans.
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 or comment on this blog’s Substack community chat.