For a long time, I have been pooh-poohing
the idea that the best way to promote good cybersecurity practices (including use
of software bills of materials, but in no way limited to that) is to regulate those
practices into existence, if they’re not already being followed. In other words,
trying to beat somebody over the head until they finally start doing what you
want them to do really doesn’t help the cause at all. It’s only when existing
practices threaten to get out of hand and cause damage that there is a reason
to regulate a new industry (e.g., AI).
However, when I and probably most
of you think of regulation, it almost always has a negative function: to deter certain
behavior with the threat of penalties. But there’s another type of regulation
that’s followed much less often, despite (or perhaps because of) the fact that it
has a positive function: to incentivize certain positive behaviors, rather than
disincentivize negative behaviors. In other words, it’s the carrot approach to
regulation, not the stick approach.
When I think of positive approaches,
I usually think of my elementary school classes, where I would get to wear a
gold star on my forehead for turning in my homework on time or getting all the
answers correct on a spelling test. I usually don’t think of a positive
approach as something that will work with adults; most of us (perhaps based on
our perception of ourselves) think that the only way to motivate adults to do
the right thing is to make sure it’s too painful/expensive/humiliating/etc. to
do the wrong thing.
However, in cases where negative
regulation isn’t likely to work, such as in encouraging practices that aren’t
being followed much today, perhaps this is really the best way to accomplish
that goal.
This is probably why I’ve come to
like the idea of a device cybersecurity labeling program, which I at first
thought was a strange way to encourage good cybersecurity practices. Most importantly,
the US is going to test that idea starting in 2025, when the Federal
Communications Commission’s (FCC) “Cyber Trust Mark” program will come into
effect. Here is a brief history of how this program came to be:
Executive Order (EO) 14028, “Improving
the Nation’s Cybersecurity”, was issued in May, 2021. Section 4(t) on page
19 reads:
Within 270 days of the date of this
order, the Secretary of Commerce acting through the Director of NIST, in
coordination with the Chair of the Federal Trade Commission (FTC) and
representatives of other agencies as the Director of NIST deems appropriate,
shall identify IoT cybersecurity criteria for a consumer labeling program, and
shall consider whether such a consumer labeling program
may be operated in conjunction with or modeled after any similar existing
government programs consistent with applicable law. The criteria shall
reflect increasingly comprehensive levels of testing and assessment that a
product may have undergone and shall use or be compatible with existing
labeling schemes that manufacturers use to inform consumers about the security
of their products. The Director of NIST shall examine all relevant information,
labeling, and incentive programs and employ best practices. This review shall
focus on ease of use for consumers and a determination of what measures can be
taken to maximize manufacturer participation.
Of course, this paragraph doesn’t explain
where the idea of “device labeling” came from, but it’s an idea for regulation of
devices that has been around for a long time. In the US, the EnergyStar program (which is ongoing) has
been quite successful in encouraging consumers to use more energy efficient
appliances. And in other countries, there have been device cybersecurity labeling
programs in Finland,
Germany
and Singapore that are considered successes, although they all had fairly
modest goals. More importantly, in Europe the idea of testing devices (along
with assessing the manufacturer’s security practices) and issuing a certification
of the device (i.e., a “label”) is much more prevalent; there are organizations
(“testing labs”) that provide this testing and issue labels, including a French
client of mine, Red Alert Labs.
Note that the EO didn’t mandate
any particular program for labeling, since the drafters of this section had
enough wisdom not to think they could figure everything out on their own. Instead,
they ordered NIST to do two things:
1.
Design “criteria” for
the label – i.e., the cybersecurity framework against which it would be tested.
Of course, NIST has been developing cybersecurity frameworks for many years and
in many different areas of security. Asking them to do this was like asking a
fish to swim. They came out with what I believe is an excellent framework, NISTIR
8425.
2.
“…consider whether
such a consumer labeling program may be operated in conjunction with or modeled
after any similar existing government programs consistent with applicable law.”
Note that the EO didn’t order NIST to develop the labeling program, but just to
consider whether there are any existing programs it can be modeled after. However,
this didn’t prevent NIST from trying their hand at designing the program. The result
proved that...well, NIST is very good at designing cybersecurity frameworks,
and perhaps they should stick to that calling. Sometime in early 2922, they seem to have abandoned the idea of designing the program, and decided just to concentrate on the framework.
When NIST introduced NISTIR 8425 in
the fall of 2022, they didn’t even mention a labeling program with it; they
simply presented it as a framework for securing IoT devices. While they said it
was for “consumer” devices – which is of course what the EO had ordered they
address – they made it clear in the NISTIR (see the blog post linked above)
that this could apply equally well to business devices; in other words, “Don’t
look for us to come out with a separate framework for business devices. This
one is good for both.” This doesn’t mean there won’t be more advanced frameworks
in the future for particular types of business devices, etc. But it does mean
that NISTIR 8425 can form a good foundation for both consumer and business
devices, which I agree with.
From the fall of 2022 until the
spring of this year, there was little hard news about the device labeling
program. There were one or two White House meetings on securing consumer
devices, which included an announcement that a labeling program would be
announced by the summer of 2023. Sure enough, this July, the announcement
came out.
As was inevitable (given that NIST’s
suggestions for the labeling program itself weren’t what was needed), the
announcement didn’t provide details on the program. But it did announce the
agency that would run the program, which was a surprise to me and others. Since
the EO had mentioned the Federal Trade Commission and since the FTC has a lot
of experience regulating privacy practices in consumer devices, it seemed very
likely the FTC would be chosen to run this program.
However, it turned out to be the
Federal Communications Commission (FCC) that was anointed to run the labeling
program. While this was a head-scratcher for me, I kept an open mind and waited
to see what the FCC would come up with. They came out with a Notice
of Proposed Rulemaking in August. While I didn’t consider this to be a work
of unsurpassed brilliance, I appreciated – once again – that it showed humility
and made clear that the FCC wants to learn from IoT manufacturers and users on the
best way to put together a device labeling program. The FCC scheduled a comment
period, which expired several months ago. It’s currently expected that they’ll
mull over the comments they received, and come out with a new document (perhaps
another NOPR?) in January 2024.
While nothing in the NOPR should
be considered as the final word on the labeling program, here are some of the most
important points it made:
1.
The Introduction to
the NOPR includes this sentence: “We
anticipate that devices or products bearing the Commission’s cybersecurity
label will be valued by consumers, particularly by those who may otherwise have
difficulty determining whether a product they are thinking of buying meets
basic security standards.” This is a great statement of the “carrot” approach
to regulation: “Mr/Ms device manufacturer, you’re free to ignore the cybersecurity
labeling program altogether if you don’t see any value in it. However, if you
do see value in it and you decide to get the label, we expect you will have
greater success selling to consumers than will your competitors who don’t have
the label. The choice is yours.” My former economics professor Milton Friedman
couldn’t have said this any better.
2.
I want to point out
that this statement, and indeed the whole tone of the NOPR, is in marked
contrast to a statement of Anne Neuberger of the National Security Council at
the July announcement. She said that the labeling program would become a way for
“..Americans to confidently identify which internet and Bluetooth-connected
devices are cybersecure”. Unfortunately, Ms. Neuberger doesn’t seem to have gotten
the memo that said a labeling program needs to provide a positive incentive to
follow the path of (cyber) virtue, not require public shaming (perhaps the
stocks?) for those who don’t want to obtain the label, whatever their reasons.
She also didn’t see the memo that said there’s no way the federal government,
the Vatican, the NSC, or any other entity can determine whether a product is “cybersecure”.
Every product is cybersecure until it gets hacked, at which point it isn’t. The
best that mere mortals can say on this issue is that the device manufacturer
has practices in place that should normally be conducive to good security, and
we hope they’ll keep them up.
Besides doing some things right,
the NOPR does make (or not make) some statements that concern me, although it’s
possible they will change in the document likely to be released in January:
1.
Like the criteria in
almost every NIST framework, the criteria in NISTIR 8425 are risk-based
(although NIST’s term for that is “outcomes-based”). That is, the criteria set
out a risk management goal that the organization being assessed (which in most
cases is a federal agency) needs to aim for, not a set of rigidly defined
actions that the organization must take or be put to death. However, the FCC
doesn’t seem to get this idea, and instead proposes that 8425 be “supplemented”
with a set of measurable criteria, since, of course, those are the only
criteria that can be audited in an up-or-down manner. It’s the old “Give me
something I can measure. I don’t care whether it’s relevant or not” attitude.
Fortunately, I think this objection isn’t likely to be sustained.
2.
One of the points I
objected to in NIST’s 2021 “discussion draft” on the device labeling program
was that, after saying they wanted the criteria for the program to be
risk-based, they then contradicted that by saying they wanted a binary (i.e.
up-or-down) label. I pointed out in my 2021 post
on NIST’s document that proposing a binary label with risk-based criteria is inherently
contradictory. Either the risk-based criteria need to go (which would be
terrible) or the binary label needs to go. NIST also considered the option of
an “informative” label – which doesn’t provide a judgment on the product but
points out what can be learned from the assessment (e.g., the manufacturer implements
good access controls, but isn’t so great at securing communications with other devices). However, they rejected that idea in 2021.
3. The problem with the binary label is that it contains no useful information, other than that somebody somehow
summarized the manufacturer’s response to the 12 or so questions in NISTIR 8425, and then
decided that the manufacturer was good/no good. Why not let the consumer see
how the manufacturer answered the questions and then make up their own mind on
where the risks lie with this product? Why try to make a decision like that for the consumer? It's like telling them that they really need to buy a blue car. The FCC doesn’t seem to be aware of this
contradiction, but my guess is it will become quite obvious later that a binary
label doesn’t make any sense, when the criteria for the label are risk-based,
as in NISTIR 8425.
4.
The FCC left out what
I think is the most important criterion that device manufacturers should follow.
Of course, it isn’t surprising that they left it out, since I’m the only person
that I know of who is advocating for this. As described in this post,
I believe that very few intelligent device manufacturers are reporting
vulnerabilities in their devices to CVE.org (which is how they get into the NVD),
as at least the larger software suppliers routinely do. The fact is that, since
almost all vulnerabilities in software products are only known because the
supplier itself reported them, a lot of devices will appear to have an “all clear”
(i.e., no vulnerabilities) from the NVD, even though they may in fact have many
thousands of vulnerabilities.
5.
The NOPR talks about having
an IoT device registry that will list, among other things, all outstanding
unpatched vulnerabilities found in a device. The FCC obviously thinks this will
ensure the manufacturers have better security, when in fact it will only ensure
one thing: that the manufacturers won’t report vulnerabilities at all, which
seems to be the rule nowadays. It’s literally a waste of time to require
manufacturers to clean up their vulnerabilities, when all you’ll do is ensure they
won’t list any vulnerabilities that need to be cleaned up in the first place.
This isn’t an easy problem to address, but it needs to be addressed before
there’s a big focus on fixing vulnerabilities, whether it’s in the FCC’s device
labeling program, the EU’s Cyber Resilience Act, or any other regulation.
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.
I lead the OWASP SBOM Forum. If
you would like to join or contribute to our group, please go here, or email me with any questions.
No comments:
Post a Comment