Blog: Vulnerability Disclosure

A Vulnerability Disclosure Program is not just a page on a web site

Ken Munro 26 Aug 2020

It’s great to see an increasing number of organisations starting down the path of a Vulnerability Disclosure Program or ‘VDP,’ but it increasingly strikes me that these are ‘check box’ exercises rather than a genuine desire to interact positively with researchers and improve security.

A VDP is a mandatory component of some coming legislation, so we expect to see yet more ‘lip service’ vulnerability disclosure programs coming soon. It’s part of UK DCMS IoT regulation, part of ETSI EN 303 645 (section 4.2) and has a fair chance of being included in EU regulation in the future. PCI DSS already requires a vulnerability management program, though I wonder how long it will be before a VDP is a mandatory requirement?

A current disclosure that @evstykas and I are working on is a case in point. What makes matters worse is that this is a large security product vendor. Surely they should be leading by example, yet they are dragging their heels at best.

  • We disclosed an IDOR in their cloud service after following their VDP. It was a page on their web site that set terms for research and making disclosures. Good start
  • The report was acknowledged within two hours. This is promising
  • The vulnerability was confirmed within three hours. Fantastic
  • The last email even suggested that if we keep quiet about the bug until it has been patched, we could enter their Hall of Fame.
  • WTF? Of course we would keep quiet until the vuln had been resolved! But to offer an entry on a list of researchers on their web site who had made disclosures was frankly patronising.
  • Then things went sideways: the bug was an IDOR. One API request wasn’t being authorised correctly, yet all others were.
  • This shouldn’t be a complex fix, as request authorisation had clearly been overlooked in one case. It was an API call, so no customer software/firmware patches were required and minimal testing would be necessary. One fix to solve it all.
  • Even if a testing program was required, it should be possible to disable the vulnerable functionality to mitigate the risk without causing major customer issues.

The flaw allowed total compromise of every cloud-managed device from said security product vendor. At least 10 million devices. So not a trivial matter…

We were expecting a fix in say 48 hours or so, given the excellent initial responses. Imagine our surprise when we were told that it would be delayed until month end. A full 17 days since disclosure, during which time all of their customers were totally exposed.

No matter how hard we queried and clarified the criticality and immediacy of the issue, we were simply told to ‘be patient’ with no further explanation

A VDP is about culture and communication

The above example isn’t unusual. No-one likes being told that they have made a mistake. “We would have gotten away with it, if it wasn’t for those meddling researchers” but this isn’t fiction, unlike Scooby Doo.

That’s why having a VDP needs to involve cultural change, not just a page on a web site.

You might have a Product Security Incident Response Team (PSIRT) that triage and manage vulnerability reports, but if they aren’t empowered to drive through important changes to fix vulnerabilities, they’re going to lose.

Where does your PSIRT team report in to? Support? Development? The CISO?

Consider the impact of a badly managed disclosure – you might be dealing with crisis PR, bad press, perhaps a stock price drop, maybe even the SEC or other authorities. Consider again who your PSIRT team should report to.

Vulnerability disclosure involves cultural change that accepts that your products and services may not be perfectly secure. It involves accepting and embracing perceived criticism. It involves being grateful to researchers, which may stick in ones throat.

It’s also about communication.

In the above example, comms were excellent initially, but then took a dive. It’s not enough to acknowledge a report well; it’s important to communicate well during the whole process.

If there’s any doubt about how much to communicate, OVER communicate. I would far rather receive a daily update report that I didn’t read than never hear again.

It’s not our job to have to keep needling for an update. We’ve done our bit by finding the vulnerability in our own time and reporting it to you, for free.

If there are challenges that are making it difficult to resolve, explain these to us. We’re reasonable people, we might even have suggestions and workarounds that could help, but being left in the dark isn’t acceptable.

Failing to communicate with researchers simply gets our backs up. The failed disclosure process becomes the story, not the vulnerability. It makes it more likely that journalists will take an interest in the story. Ask Barbra Streisand.

We want to put cool vendors in our hall of fame. We want to congratulate vendors on their excellent disclosure program. We want your customers to be protected.

Good VDP + responsible researchers = customer win

A VDP isn’t only a page on your web site