There are currently ongoing discussions about vulnerability disclosures and what is right, what is responsible and who has the interest of securing the Internet from the evils of bad coding or software design. Much of this is a good discussion, while some of it is a rehash of old arguments. The last seminal work on disclosures was performed by the National Infrastructure Advisory Council (NIAC), which published the “Vulnerability Disclosure Guidelines” back in 2004. I had the opportunity to contribute to these efforts. However, a lot has happened over the past decade in IT, so this discussion is probably worth revisiting — and overdue.

Bilateral and Responsible Vulnerability Disclosure

What have we learned over time? What is out of date? These questions are now part of the discussion. I can say that we have moved from a responsible disclosure to a coordinated disclosure thought process, but we have not yet documented such an approach. The moniker of being “responsible” seemingly indicates that only one method is responsible. If everyone else has different approaches, does that mean they are irresponsible? I should say not. As we know in IT, there are many paths one can take to solve an issue, and a vulnerability disclosure is not wholly different here.

So what have we learned over the past decade to change that? Essentially, one must coordinate a vulnerability disclosure with others. In other words, there is no one set or correct path for all to follow — especially not rigidly. We are all situation-dependent, which brings us to the bilateral issue. In the NIAC approach, we essentially looked at a situation as being between two parties. If one party did not know the other or there was a lack trust, we invoked a coordinator to assist us through the process, such as the Computer Emergency Response Team Coordination Center or the Computer Security Incident Response Team to do that for us. Occasionally, it would involve two or three vendors and a researcher, as the intermediary became the trusted communicator and coordinator. It worked for the most part. They had the inside line on what was ground truth and knew the parties involved.

What Changed?

First, we have more parties that have to fix vulnerable conditions. Second, we have built and now use more complex applications. So far, there has been no real change, so there’s no real problem, right? However, then some other things came along. We have applications that run entirely on one platform and are delivered centrally. All that is controlled is updated almost simultaneously. However, we also have another set of conditions. Enterprises now take major applications and add their own code on top of that. In other words, there are major differences in what is deployed from one organization to another, and we haven’t even touched on the international aspect. Furthermore, we have now embedded third-party software — you know, all those special calls and other interfaces that allow communications across applications and platforms. We have seen quite a few large-scale issues this past year with this problem.

This brings us back to the recent set of discussions about disclosures. We now have multiparty, multifaceted coordination needs. These are cross-industry requirements, which means we need to now consider phasing our disclosures. This requires us to open the genie box and reconsider our approach in a more organized manner. No longer can a researcher jump out and save the Internet from itself, since its complexity is beyond that stage. A researcher may understand the bug, but the system of systems and the interactions require a broader group effort.

By the way, “organization” does not refer to government-run and coordinated organizations, although they certainly have an aspect to play — just not a central role. This is a group effort that requires thought-out discussions and consideration. I applaud the efforts of all who are part of the discussion — especially the Forum for Incident Response and Security Teams and the Industry Consortium for Advancement of Security on the Internet for lending a hand to convene the discussion. How far we get depends on how much effort we put into this. However, keep in mind that the Internet now has a lot of business that crosses through it, and we need to consider that while we protect everyone.

More from Software Vulnerabilities

FYSA – Critical RCE Flaw in GNU-Linux Systems

2 min read - Summary The first of a series of blog posts has been published detailing a vulnerability in the Common Unix Printing System (CUPS), which purportedly allows attackers to gain remote access to UNIX-based systems. The vulnerability, which affects various UNIX-based operating systems, can be exploited by sending a specially crafted HTTP request to the CUPS service. Threat Topography Threat Type: Remote code execution vulnerability in CUPS service Industries Impacted: UNIX-based systems across various industries, including but not limited to, finance, healthcare,…

X-Force discovers new vulnerabilities in smart treadmill

7 min read - This research was made possible thanks to contributions from Joshua Merrill. Smart gym equipment is seeing rapid growth in the fitness industry, enabling users to follow customized workouts, stream entertainment on the built-in display, and conveniently track their progress. With the multitude of features available on these internet-connected machines, a group of researchers at IBM X-Force Red considered whether user data was secure and, more importantly, whether there was any risk to the physical safety of users. One of the most…

X-Force releases detection & response framework for managed file transfer software

5 min read - How AI can help defenders scale detection guidance for enterprise software tools If we look back at mass exploitation events that shook the security industry like Log4j, Atlassian, and Microsoft Exchange when these solutions were actively being exploited by attackers, the exploits may have been associated with a different CVE, but the detection and response guidance being released by the various security vendors had many similarities (e.g., Log4shell vs. Log4j2 vs. MOVEit vs. Spring4Shell vs. Microsoft Exchange vs. ProxyShell vs.…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today