Cyber ​​Daily recently had the chance to have an in-depth discussion with Logan Carpenter, Senior Vulnerability Analyst at Dragos, about how vulnerability disclosure works, from the process starting with finding a bug to the nature sometimes contradictory collaboration with a supplier to quantify. how bad a bug could be.

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

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

We find the bugs, or we find the product vulnerabilities, and then we go through the process of reporting the bug to the vendor – this can be done through different means. Sometimes the vendors themselves have an incident response team, right? And you’re kind of feeding into those vulnerabilities through that. These are aimed at larger, more mature suppliers; other providers have external services that they use. So it’s basically an external body, what we call CNA (a CVE numbering authority), that will manage their vulnerabilities on their behalf and mediate.

And then the third group is just vendors that don’t have any sort of security team. Basically you just cold email them and try to get in touch with one of their engineers or whoever they have there, which is maybe security related. And so we begin this process.

This process typically involves reserving a CVE first; we have to agree on who books 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 also a CNA, and those are just entities that can actually reserve CVEs.

Once we agree on who books it, we need to agree on two things: results and actual scores. And this is where things get a little complicated in the process and where we sometimes get pushback from vendors for various reasons, such as whether or not they agree that there actually are vulnerabilities or whether they agree on the score.

This is usually the longest part of the whole process, as it usually requires sending emails back and forth, back and forth, back and forth, especially if there is many vulnerabilities or controversial vulnerabilities that the vendor may have reservations about. Then, once we’ve fixed that, we have a vulnerability disclosure policy; and part of that policy is actually coordinating with vendors any type of external reporting that we do.

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

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

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

Cyber ​​Daily: It seems to be a process that can be quite confrontational at times. Is this the case?

Logan Carpenter: Oh yeah, a lot.

Actually, it’s funny; there’s a talk I gave about two weeks ago that was actually aimed at providers – Destigmatizing Vulnerabilities. He went into great detail about what kind of negative experiences we have with suppliers who may not be playing…

I mean, we see things like unnecessary redactions, where they want to remove things that may be unnecessary, that we may deem unnecessary, right? They sometimes kill a product because the vulnerability is too difficult to fix, or perhaps too expensive. I like to call it the end of life. They will simply end the life of the product.

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

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

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

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

Logan Carpenter: Without naming names, of course, we have had issues where we have been threatened with cease and desist orders or threatened with legal action. We have had situations where we actually sent the disclosure to the vendor early in the process – and a year has passed. Some time passed, we reached out, reached out, and we were basically going to force their hand and continue to report on it ourselves.

And they told us not to do it.

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

These are both egregious examples, but we’ve also had examples where a company can end the life of a product simply in response to something. We actually had a situation where the company put the product at end of life, and some time passed. And of course, our analyst Reid, who discovered the vulnerability, told him it’s end of life for your product, and he said, “Well, it doesn’t say it’s end of life.” of your product. He says he’s still taken care of.

And then some time passed, and we discovered that threat groups were actually targeting these same vulnerabilities, for which a patch magically appeared out of nowhere.

It’s another situation of… bad disclosures and how those disclosures can sometimes go wrong.

Cyber ​​Daily: What are the worst examples of the consequences of a company not properly handling vulnerability disclosures, as you just mentioned? How often do you end up seeing these vulnerabilities subsequently exploited?

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

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

There have been a few situations where we have obtained information, someone else has disclosed vulnerabilities that are essentially sandbagged to prevent public disclosure, and then, a few months later, those vulnerabilities are exploited. So it doesn’t work for everyone involved, especially asset owners.

But it’s not very common, but it happens. This is something people need to be aware of, especially when it comes to OT and ICT security. We’re talking about these one-off attacks that can happen, right? This is very rare, but when they do, the consequences are usually quite serious and, in some cases, can be life-threatening.

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