Interview: How the vulnerability disclosure process works, with Dragos’ Logan Carpenter

Cyber Daily recently had the chance to have an in-depth chat with Dragos’ principal vulnerability analyst, Logan Carpenter, about how vulnerability disclosure works, from where the process starts with finding a bug to the sometimes adversarial nature of working with a vendor to quantify just how severe a bug might be.

Cyber Daily: So let’s start with the basics of vulnerability disclosure – what is the nature of your work, especially when it comes to working with vendors during the process of disclosure?

Logan Carpenter: So the process looks a little bit like this.

We find the bugs, or we find the vulnerabilities in the product, and then we go through the process of reporting the bug to the vendor – that can be through a few different means. Sometimes, the vendors themselves have an Incident Response Team, right? And you kind of feed those vulnerabilities in through there. Those are for the larger, more mature vendors; other vendors have external services that they use. So it’s basically like an external, what we call CNA (a CVE numbering authority), that will handle their vulnerabilities on their behalf, and mediate it.

And then, the kind of third group is just the vendors that don’t have any kind of security team at all. Basically, you just kind of cold email them and try to get in contact with one of their engineers or whoever they have there that’s maybe related to security. And so we start that process off.

That process usually entails first reserving a CVE; we have to agree on who reserves them, right? So whether or not they have their third-party CNA, sometimes a vendor like Siemens and Cisco, they are their own CNA. Dragos is a CNA as well, and these are just entities that can actually reserve CVEs.

Once that’s agreed on who’s reserving it, we have to agree on two things – the findings and the actual scores. And this is where things get a little hairy in the process and where we sometimes will get pushback from vendors for various different reasons, like whether or not they agree there are actually vulnerabilities or agreeing on the score.

That’s usually the longest part of the whole process because it usually requires sending emails back and forth, back and forth, back and forth, especially if there are a lot of vulnerabilities or some contentious ones that maybe the vendor has some reservations about. Then, once we get that settled, we have a vulnerability disclosure policy; and part of that policy is actually coordinating with vendors about any kind of external reporting we do.

VIEW ALL

So, if we find a vulnerability, we usually create our own report that goes out to our customers, and we always give the vendor a final review. We don’t always honour everything that they tell us, but we try to be as reasonable as possible. If they have legitimate concerns or they don’t feel comfortable … Out of just trying to foster better relationships between vendors, we try to oblige them.

Now, if it’s something egregious, or it takes away from the report significantly, we’ll kind of override it, but that’s basically how the process goes.

We find the bugs, report the bugs, reserve CVEs, agree on those findings, create those scores, and then we report.

Cyber Daily: It sounds like it’s a process that can be quite adversarial at times. Is that the case?

Logan Carpenter: Oh yeah, very much.

Actually, it’s funny; there’s a talk that I gave about two weeks ago that was actually directed towards vendors – Destigmatising Vulnerabilities. It went into deep detail about these kinds of various negative experiences that we have with vendors who maybe aren’t playing ...

I mean, we see things like unnecessary redactions, where they want to take things out that may be unnecessary, that we may feel is unnecessary, right? They’ll sometimes kill off a product because the vulnerability is too hard to patch, or maybe too expensive. I like to call that end-of-life-ing. They’ll just end the life of the product.

We’ve had issues with score haggling – I actually got a vendor to admit this, a very large vendor, to admit that vendors will actually intentionally try to get the CVSS score as low as possible. And so what will happen is some of those attributes in that CVSS scoring system that are a little more subjective, they will try to get those scores as low as possible. Sometimes, that has a little bit of back and forth.

They will also try to delay or obstruct disclosures. They don’t want a vulnerability getting reported … Let’s say it’s been a year and they want more time. Or they’ll actually try to prevent us from disclosing, stuff like that.

So it’s, it’s a bunch of different negative experiences that we have.

Cyber Daily: What are some of the most extreme examples of a company not wanting to disclose an extreme vulnerability?

Logan Carpenter: Without naming any names, of course, we’ve had issues where we’ve been threatened with cease-and-desist orders or threatened with lawsuits. We’ve had situations where we actually sent the disclosure to the vendor at the beginning of the process – and a year went by. Some time went by, we reached out, reached out, and we basically were going to force their hand on it and move on with reporting ourselves.

And they told us not to.

We said, “Sorry, it’s been over a year,” and they responded by actually contacting Rob (Robert M. Lee), our CEO, and basically telling him to tell us to stand down. Rob came to us and asked us, “What’s going on?” And, long story short, they never read the disclosure policy. After a certain amount of time, we’re going to move ahead.

Those are two egregious examples, but we’ve also had examples where a company may end-of-life a product just in response to something. We actually had a situation where the company end-of-lifed the product, and a little bit of time went by. And, of course, our analyst Reid, who discovered the vulnerability, they told him it was end-of-life, and he said, “Well, it doesn’t say it’s end-of-life for your product. It says it’s still supported.”

And then some time went by, and we found out threat groups were actually targeting those same vulnerabilities, for which a patch magically appeared out of thin air.

That’s another situation of just … bad disclosures and how those disclosures can kind of go sideways at times.

Cyber Daily: What are some of the worst examples of the follow-on effects from a company not handling vulnerability disclosures properly, as you just mentioned? How often do you end up seeing these vulnerabilities then exploited?

Logan Carpenter: When it happens, it’s pretty bad.

There are some pretty popular vulnerabilities, pretty popular attacks that this kind of behaviour has been associated with, whether it be on the front end or the back end. So there’s been situations where there’s been a serious attack on critical infrastructure, and basically, we were told not to talk about it or talk about the vulnerabilities related to it. And I think that’s in itself … it’s not the best situation for the community.

There have been a few situations where we’ve gotten intel, somebody else has disclosed vulnerabilities that are basically being sandbagged to prevent public disclosure, and then, a couple of months later down the road, those vulnerabilities are getting exploited. And so it doesn’t work out for anyone involved, especially the asset owners.

But it’s not super common – but it does happen. That’s the thing – especially when it comes to OT and ICT security – that people have to realise. We’re talking about these one-off attacks that may happen, right? It’s very seldom that they do, but when they do, the ramifications are usually pretty severe and, in certain cases, could be life-threatening.

And so just because it doesn’t happen all the time, the fact that it happens is kind of an issue.

David Hollingworth

David Hollingworth has been writing about technology for over 20 years, and has worked for a range of print and online titles in his career. He is enjoying getting to grips with cyber security, especially when it lets him talk about Lego.