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

Dissecting and Exploiting TCP/IP RCE Vulnerability “EvilESP”

September’s Patch Tuesday unveiled a critical remote vulnerability in tcpip.sys, CVE-2022-34718. The advisory from Microsoft reads: “An unauthenticated attacker could send a specially crafted IPv6 packet to a Windows node where IPsec is enabled, which could enable a remote code execution exploitation on that machine.” Pure remote vulnerabilities usually yield a lot of interest, but even over a month after the patch, no additional information outside of Microsoft’s advisory had been publicly published. From my side, it had been a…

Self-Checkout This Discord C2

This post was made possible through the contributions of James Kainth, Joseph Lozowski, and Philip Pedersen. In November 2022, during an incident investigation involving a self-checkout point-of-sale (POS) system in Europe, IBM Security X-Force identified a novel technique employed by an attacker to introduce a command and control (C2) channel built upon Discord channel messages. Discord is a chat, voice, and video service enabling users to join and create communities associated with their interests. While Discord and its related software…

Critical Remote Code Execution Vulnerability in SPNEGO Extended Negotiation Security Mechanism

In September 2022, Microsoft patched an information disclosure vulnerability in SPNEGO NEGOEX (CVE-2022-37958). On December 13, Microsoft reclassified the vulnerability as “Critical” severity after IBM Security X-Force Red Security Researcher Valentina Palmiotti discovered the vulnerability could allow attackers to remotely execute code. The vulnerability is in the SPNEGO Extended Negotiation (NEGOEX) Security Mechanism, which allows a client and server to negotiate the choice of security mechanism to use. This vulnerability is a pre-authentication remote code execution vulnerability impacting a wide…

Containers, Security, and Risks within Containerized Environments

Applications have historically been deployed and created in a manner reminiscent of classic shopping malls. First, a developer builds the mall, then creates the various stores inside. The stores conform to the dimensions of the mall and operate within its floor plan. In older approaches to application development, a developer would have a targeted system or set of systems for which they intend to create an application. This targeted system would be the mall. Then, when building the application, they would…