Wednesday, December 27, 2023

Is this the best approach to device cybersecurity regulation?


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