Reading · Gavin D. Howard

tl;dr: The industry needs professional certifications and liabilities for not reporting vulnerabilities.

Introduction

I don’t know if you have seen the news, but MITRE’s government contract for CVE was about to expire today (until they got a reprieve).

As techies are wont to do, and since the current administration is behated by most techies, they are up in arms about it.

Let me say upfront: I won’t comment on the politics of this situation.

Instead, might I suggest that we have an opportunity, even with the reprieve?

The Problem

The CVE system has been less good about securing our infrastructure than they have been about giving headaches to some of the most important projects. Curl gets bogus CVEs all the time and has to spend precious time dealing with them. Postgresql does too. The Linux kernel went a different route and just spams CVEs so that kernel CVEs essentially become worthless.

Worthless? Does that mean that CVEs were actually worth something to people?

Yes, absolutely. Script-kiddies that consider themselves “security researchers” try to find bugs in big projects and then get them labeled as CVEs so they can add those CVEs to their résumés. As one user on Hacker News said, “Unfortunately, the CVE database(s) are too noisy to be useful.”

In fact, it got so bad that Curl decided to do extra work to become a CNA, just so they can reject spurious reports and avoid the NVD from giving excessively high vulnerability scores.

Because Daniel Stenberg, the Curl lead, has been so prolific in blogging, people know Curl’s situation well. The first comment on the lobste.rs story said:

Finally a breather for Daniel Stenberg (original author and maintainer of curl, [see] context).
– BenjaminRi

The Solution

In reply, a lobste.rs user called insanitybit said this:

One of two things is going to happen.
We end up with a system like CVE where submitters are in charge of what’s in the database other than egregious cases. This is what MITRE supported as the default unless someone became a CNA, something they’ve been handing out much more freely over the last few years to address public scrutiny.
We end up with a system not like CVE where vendors are in charge of what’s a vulnerability. This seems to be what Daniel and others want.
(1) is not ideal, (2) has historically been terrible. The reason we have (1) is because, historically, vendors were horrible about responding to vulnerabilities, which is why antisec and public 0day drops were how things got fixed. That was the status quo not so long ago - drop a 0day publicly to shame a vendor into fixing the issue.
I think it’s far easier to start with (1) and fix it than to start with (2) and fix it. In fact, Curl already is its own CNA, so Daniel already has what he wants.
– insanitybit

The only thing I think insanitybit got wrong is the proposed solution:

I think it’s far easier to start with (1) and fix it than to start with (2) and fix it.

If you have to start from “bad” and fix it, at least with regards to cybersecurity, you have already lost.

Instead, let’s figure out what would work, with all incentives aligned, and implement it.

Attributes Instead of a Score

First of all, a linear “score” like CVSS just cannot work in cybersecurity. Instead, we should have a system on the attributes of a vulnerability.

And before you say it can’t be done, I think we have had enough experience as an industry to get a good start.

For example, how about two categories of attributes: what a vulnerability needs to be exploited, and what happens when it is.

In the first category, we might have attributes such as:

Needs physical access to the machine.
Needs to have software running on the same machine, even if in a VM.
Needs to run in the same VM.
Needs only network access to the machine.
Needs to interact with software running as root.
Needs root.
Vulnerable machine must have symlinks enabled.
Vulnerable machine must be have <insert_some_OS_here>.
Vulnerable machine must use <insert_some_software_here>.
Etc.

In the second category, we might have attributes such as:

Arbitrary execution.
Data corruption (loss of integrity).
Data exfiltration (loss of confidentiality).
Impersonation or confused deputy (loss of authentication).
Privilege escalation (loss of authorization).
Etc.

I think we can start with some of these attributes and add more later as we find out what is important.

“But Gavin! What if the list of attributes grows without bound?”

That is possible, and I do expect the list to get large. However, while cybersecurity is a large field, the OWASP Top Ten changes slowly, even in our rat race, hyperspeed industry. I just don’t think there is enough variation in vulnerabilities to worry about the list of attributes growing.

But even if it does, storing those attributes instead of a score would allow automatic tools, such as the ones currently using CVSS, to be more sophisticated in what they flag.

Perhaps a company’s servers are all firewalled from the outside Internet, and they don’t host clients. They would not care about vulnerabilities that has to have software running on the same machine, so they could filter out those vulnerabilities.

On the other hand, a hosting company, running client code in VMs that have network access, would probably care about just about everything. Every company and project would be able to customize what vulnerabilities it cares about.

Professional Certification and Required Reporting

The other side of the problem is the incentives around reporting.

Companies don’t want to report vulnerabilities because it makes them look bad. This can go to absurd lengths.

So yes, I get it: we shouldn’t trust companies, or even FOSS projects, to self-report.

Unless…what if we made penalties so large for not reporting, and for getting it wrong, that they would fall over themselves to do so?

“But how do we do that, Gavin? EU GDPR and DMA fines have not been enough to stop companies so far!”

Ah, yes, fines for companies are not enough. I agree.

So what if we made it so those companies simply cannot do business?

Here’s how:

We create a professional certification for professional software engineers (PSWEs).
This certification must be revokable if the PSWE misbehaves or is negligent.
Among other things, we define negligence as not accurately reporting vulnerabilities within a certain time window (90 days?).
This would ensure that PSWEs would absolutely report because they would not want to lose their certifications.
We make certain types of software require a PSWE as an Engineer of Record.
Note that we should NOT specifically require everyone on that project to be certified, just the one in charge. This is to prevent gatekeeping the entire industry.

This has the nice side effect that if a company “lays off” or otherwise gets rid of a PSWE for reporting vulnerabilities, their ability to hire another would probably be severely hampered because other PSWEs would see that company as a problem.

Also, such “laid off” PSWEs would probably easily find work elsewhere since having a certification would be required for a lot of stuff.

All of these things together, while not requiring vulnerability reports, would have that effect. The possible loss of a PSWE, which would then stop a company from doing business with that project, means that the de facto penalty for not reporting would be an instant loss of business.

This is a much higher penalty than a fine. If a business can do business, it can pay fines. If it can’t do business, it dies.

So while it’s not as severe as jailing executives, I would bet that it would make executives act about the same.

Accuracy

The other part of this is: how accurate do reports need to be?

I think the attribute system would help. Instead of a subjective score, each attribute would be objective, and I think this should be a requirement for attributes.

But if attributes are objective, and purely describe facts, then PSWEs MUST be able to get them right.

I think this should only apply within a certain window, maybe 90 days. If no one disputes the accuracy of a report, or the report is found to be correct within that time, then it should stand.

This should prevent future research from getting reports changed after the fact, which would mean a PSWE loses a license; accuracy should only be judged using the facts known at the time.

And I personally would allow a PSWE to be wrong on one attribute. Nobody is perfect.

FOSS

“But Gavin, what about FOSS projects? Would they need PSWEs?”

No, because they are not doing business. I think we should define it such that if no money changes hands, no liability accepted.

“But that just means that companies will only accept liability for their own stuff and use as much FOSS as possible to avoid liability!”

Read the link above carefully; it does nothing of the sort. Companies would still be liable for their entire software stack.

“But that means that companies would be liable for things like Curl that they don’t control.”

Yes, but here’s the deal: those companies could make deals with those projects for those projects to accept liability, and in return, those projects would get money. Of course, the projects would need to have a PSWE at the top, but I think that would be doable.

And then, because those projects have a paid PSWE, they would be required to accurately report vulnerabilities.

In other words, not only would this solve the vulnerability reporting problem, it would solve FOSS funding problem.

Gatekeeping

“But Gavin! Certifications are still gatekeeping and would unfairly hurt those with disadvantages.”

Not necessarily. I believe that the professional body could be set up in such a way as to require current PSWEs to fund the education, training, and certification of those who want the certification:

All educational materials for required knowledge should be free for download. Everything. This is so aspiring PSWEs can study without paying anything except time.
All aspiring PSWEs should have one exam paid for by the professional body, including air fare to a testing site, as well as hotel.
Any aspiring PSWEs that pass the exam should be given an apprenticeship. If no PSWE accepts them, the professional body should assign a PSWE to accept them based on how many apprentices the PSWE already has.
Apprenticeships should be free. This is so they don’t have to worry about education expenses.
Apprentices should be paid a living wage by the PSWE’s employer. This is so they do not have to worry about education and employment at the same time.
Finally, the last step would be an oral and practical exam on required skills by another PSWE. The first of these should be free as well.

Now, would there still be some gatekeeping? Yeah. There might be PSWEs that do not properly help or train some or all apprentices, but we can work around those too:

An apprentice can request a change of PSWE if the PSWE is not discharging their duties appropriately.
When that happens, the professional body should investigate. If the PSWE is found at fault, their license should be revoked.

It is hard to find a balance, but I think a balance can be struck with time if we start on the right foot.

Conclusion

So there you have it: my solution to the current CVE drama.

The theme is to change the incentives, and I am fascinated by how changing the incentives actually solves multiple problems at once!

If you were to ask me, “what’s good for the goose is good for the gander” in that making something good for society also makes that thing good for the individuals involved. You could say “a rising tide lifts all boats.”

Let’s apply that here.

Replacing CVE