CERT: People and Process are Essence of Coordinated Vulnerability Disclosure

Dec 6 2017
luke

We recently held an Ask Me Anything with the co-authors of The CERT Guide to Coordinated Vulnerability Disclosure (CVD). The CERT Coordination Center’s Allen D. Householder, Threat Ecosystem Analysis Team Lead, and Art Manion, Vulnerability Analysis Technical Manager, shared their thoughts on the creation of their guide as well as many of the specific points within the guide.

Even though the challenge of disclosure is still with us 30 years after the advent of the internet, the pace of technological innovation is exceeding the pace of vulnerability coordination. 

As an example, they pointed to the plethora of IoT devices being released by more types of companies for a wider range of use cases. That means more people outside of the technology and the vendor are going to be impacted by vulnerabilities.

“Coordinated disclosure has remained important because it’s reached a much wider audience than the system admins and vendors and vulnerability security technical nerds,” Art said. 

“Any physical thing you have that’s connected to a network and has got embedded software in it could have a vulnerability. In fact, it almost certainly does. And you might want to know about it or have it fixed.”

CVD is a people + process problem

 

The team defined “coordinated disclosure” as telling someone something they don’t yet know, but first giving some consideration to the consequences of your actions and who else might be involved. This base definition points to the recurring people/process aspects of CVD.

“When you’re trying to get people to do things, and possibly lots of people to do things, and do them in a coordinated fashion, this quickly becomes an organizational problem,” said Art. “Very often, those issues outweigh the technical aspects of what’s going on.”

Basically, CVD means that, after you find a vulnerability, “you keep asking ‘who else needs to know about this and what should they do about it’ until you run out of things to do,” added Art.

It’s the people who are vulnerable

 

Art mentioned that he views CVD as sort of “a consumer protection thing,” since so many lives are now connected to technology. From autos and airliners to manufacturing plants and medical devices, companies have to think through the safety implications of every connected device. That safety aspect is another reason CERT released their CVD guide.

“Companies that basically (create) anything that has some safety-critical aspect that also has an internet connection now become a lot more interested in security vulnerabilities,” added Allen. “Because, you know, if it’s not secure then it probably isn’t safe.”

And, it’s the people who need to make the CVD process happen

 

Another impetus for CERT’s CVD guide is to help those who are charged with creating their own vulnerability disclosure policy and process. As more government agencies push vendors to implement VDPs, the need for a public reference manual — for both sides — is something the team envisioned. Because, ultimately, the people creating those policies and procedures are as critical as the process itself.

CERT’s guide also serves as a means for getting lagging industries up the CVD learning curve faster. It took over a decade, said Allen, to get the big-name tech firms to publicly discuss disclosure once the internet took off.

For other industries, especially where safety is critical, it’s important to get them up to speed even faster. “For the car manufacturers and the airplane manufacturers or the medical device people, we don’t have that kind of time to wait for them to take that same learning curve,” added Art. 

It further becomes “a really sticky problem,” as Allen puts it, when multiple vendors are involved. The disclosure timeframe is just one of the many issues to work out. “A large organization might want 60 or 90 days to fix things, and another might want 24 hours,” Allen said.

“How do you know what to do? Do you find the average of those and that’s the disclosure date? Deciding that day becomes very difficult.”

Where to begin? With a Vulnerability Disclosure Policy...and some empathy!

 

Like many others, the team points to a VDP as table stakes in the disclosure process. “Publish your disclosure policy, so at the very least — and it is sort of a minimum bar — others know what to expect from you,” said Allen.

Relying on email as the means for communication and coordination is a mistake, however, according to the CERT guide. The guide states: “Email is not a very good mechanism for tracking multiple cases at once. Vendors...should consider setting up a web-based case tracking system instead.” This is why Adobe, General Motors, and the Department of Defense use the HackerOne Response Product.

Ultimately, Art says, it’s all about the people and the process. “Some empathy goes a long way. Put yourself in someone else's shoes. Yes, we're in a technical world, but a lot of this coordination disclosure process really is humans and organizations.”

You can listen to the entire conversation with Allen and Art and get in touch if you have questions on how we can help you establish a compliant process for receiving and acting on vulnerabilities discovered by third-parties.

Related Posts