What is Responsible Disclosure?

Responsible disclosure is a vulnerability disclosure model whereby a security researcher discreetly alerts a hardware or software developer to a security flaw in its most recent product release. The researcher then provides the vendor with an opportunity to mitigate the vulnerability before disclosing its existence to the general public.

In this article, VerSprite security researchers will outline a typical process for zero-day reporting, describe considerations surrounding the ethical question of making a vulnerability public or allowing a manufacturer to first patch the flaw, and take an inside look at VerSprite’s responsible vulnerability disclosure policy. For this article, VerSprite will use a fictional scenario of identifying a security flaw in a keypad that arms a security door.

‍

What Happens Once a Vulnerability is Discovered?

When a security researcher discovers a vulnerability in a product, for example, if holding down the “2” key for 10 seconds on a secured door’s keypad bypasses the need for a code and opens the door, then the security research firm has a decision to make. It has the option to make the vulnerability public by publishing its findings immediately, or may discreetly report the bug to the product’s developer and allow them time to patch the security concern. The day the security researcher discovers the vulnerability is known as “zero-day” or “0-day.” While it is up to the security research company to decide which path it will take, VerSprite and many in the security community promote the more ethical vulnerability disclosure method of allowing the vendor to patch the flaw.

‍

Zero-Days Mean the Clock Starts Ticking for Developers After a Vulnerability Disclosure

After a security researcher has called a company’s attention to a security flaw in its product or software, the proverbial clock starts ticking. The standard amount of time the industry allocates for the company to remediate the security flaw is 90 days from disclosure.

During this responsible disclosure process, the researcher and product developer may negotiate a different timetable depending on how broad or deep the problem runs using gentleman’s rules.

Typically, the researcher agrees to hold the vulnerability discovery in confidence for the agreed-upon time while the hardware or software developer works to patch the security flaw.

Remediation measures could range from creating and pushing a patch for system users over the air to rolling out a hardware replacement. Some vulnerability remediation may be presented to users as “updates,” while others may be presented with full transparency through a detailed security announcement. Once the vulnerability is fixed and disclosed to the public, there are dedicated internet platforms that are devoted to cataloging the security flaws and their fixes, such as MITRE.

‍

Officially Logging a Vulnerability Disclosure with MITRE

After the vendor validates the vulnerability, the researcher who uncovered the security flaw will generally want to register the finding with The MITRE Corporation, an organization that houses a repository of security flaws. MITRE issues Common Vulnerabilities and Exposures (CVE) IDs to the researcher or product owner to register and classify the security flaw. Many large companies reserve batches of these numbers with the expectation of using numerous, separate CVEs throughout the year, where smaller operations may request a CVE on an as-needed basis.

When a CVE ID is activated, MITRE may choose to hold its details in confidence until the researcher and product developer agree that a fix is ready and the public should be alerted.

Following this code of responsible disclosure allows the product developer time to mitigate the security issues without broadcasting the flaw to the public, some of whom could take advantage of it. Once the security flaw is mitigated and its details are published, anyone can search MITRE’s website for information on the vulnerability and locate references to security tool databases that showcase each flaw’s classification, patch information, and other technical data.

Ideally, both the product developer and vulnerability disclosure will be in agreement about the findings and work together to mitigate the issues in a timely fashion while MITRE discreetly holds the details.

One such example of a responsible vulnerability disclosure working as designed is with SolarWinds, a global IT management product provider. SolarWinds had an unauthenticated remote code execution (RCE) on its platform. VerSprite discovered the RCE vulnerability, which would allow anyone worldwide to send a malicious packet to the client and exploit the system.

SolarWinds responded with urgency and concern, and they coordinated a patch for the system just seven days after zero-day reporting. VerSprite’s collaboration with SolarWinds is an example of responsible vulnerability disclosure working the way it was intended—but what happens when a company isn’t as responsive?

‍

What if a Product Developer Does Not Acknowledge a Vulnerability Disclosure?

Sometimes a hardware or software developer will not acknowledge a vulnerability notification, will acknowledge it but not follow up to create a plan to address it, or will communicate poorly or not at all after establishing a plan to mitigate or patch the vulnerability. On occasions such as these, an accepted industry practice is for the responsible discloser to announce the vulnerability so the public can increase its defenses.

VerSprite’s security researchers make every reasonable attempt to contact developers and give them the standard 90-day time frame to address the vulnerability prior to public disclosure. If the vendor is non-responsive, stalls the fix beyond 90 days without reason, or lacks interest in fixing the vulnerability disclosure, VerSprite will notify them of a time frame when it will publicly release the information.

At the very heart of responsible disclosure is the ethical dilemma of whom to tell and when. While the industry has created its 90-day guidelines, it comes down to a human-to-human interaction to determine if a developer will do right by its product users when a vulnerability comes to light.

Some developers legitimately need more time to fix a wide-reaching vulnerability, in which case VerSprite may extend the courtesy of suppressing its findings beyond 90 days. Other developers may be clear from the start that they have no intention of acknowledging or fixing the issue. This may lend to VerSprite’s decision to speed up public disclosure to educate and inform the general public so they may properly gauge their risk or shore up their defenses.

Uncovering and disclosing a hardware or software vulnerability may beg the question—in what other ways might one trigger the same type of system breach? Security researchers ask and answer this question through variant analysis.

‍

Conducting Variant Analysis for a Vulnerability Disclosure

Researchers may use variant analysis to discover additional ways to generate the same vulnerability. Returning to the keypad example, a security researcher may use variant analysis to try to bypass the door’s security code in another way, such as holding down the “4” key or a combination of keys in an attempt to activate the same type of unwanted response that occurs when the “2” key is depressed at length.

‍

Different Attack Vectors Call for New CVEs and a New Zero-Day

If the manufacturer upgraded the same keypad to be Bluetooth capable, it would introduce a new attack vector, or avenue, to breach the keypad. If a researcher were to find a way to lock or jam the keypad through Bluetooth, that vulnerability would be classified as a new security flaw, and it would have its own zero-day—separate from the zero-day that began with the discovery that depressing the “2” key at length would open the secure door.

Even though jamming the door via Bluetooth is a flaw with the same keypad, it would require a CVE ID different from the one used for the malfunctioning keys that bypassed the door’s security code. Each time a researcher remediates and rolls out a vulnerability’s fix, the timeline tied to its responsible disclosure process moves to N-days, or the number of days since the developer disclosed the vulnerability to the public and made a patch available.

‍

VerSprite’s Responsible Vulnerability Disclosure Policy

Rarely does a general product user stumble across a security flaw in everyday software or hardware use. Researchers uncover vulnerabilities often by choosing specific targets of study. VerSprite specializes in uncovering vulnerabilities to strengthen security on widely used products and to uphold its distinction as a world-class security researcher, as touted by NordVPN.

VerSprite’s team of security researchers choose different targets on which to perform attack surface enumeration and look at different vectors that they can use to exploit a device or program. Common vulnerabilities include improper access controls, missing data encryption, and system-level processes that enable privilege escalation. Once researchers locate a security flaw, they follow the tenets of responsible vulnerability disclosure and alert the vendor, set up an action plan, and negotiate a timeline for the fix before releasing their findings to the public.

‍

Why Put Manpower into Finding Vulnerabilities in Others’ Products?

Security consultants often safety-test the world’s software and products on their dime. The time and resources that firms like VerSprite put into research help harden security as a benefit to the industry. It advances knowledge on the intricacies of the applications and contributes to the security of those products the general public relies on in the day-to-day operations of their work and personal lives.

When a researcher uncovers and discloses a security flaw to the vendor, there is no grand payday. While there are a few bug bounty platforms and research programs that offer awards or payment for submitting vulnerabilities, those do not make up the bulk of overall vulnerability reporting. Rather than monetary gain, there are opportunities for security firms to publish their findings, deepen their credibility in the industry, and flaunt their technical prowess.

Responsible vulnerability disclosure that results from these independent findings in current applications, software, and hardware can serve as an introduction to forming new alliances in the tech field and help keep the general population safe. Some companies will form a business agreement with the security firm that uncovered a vulnerability in their product, oftentimes to extricate bugs in the same class.

Bringing security vulnerabilities to hardware and software companies through responsible vulnerability disclosure can also open the door to future work, as was the case when VerSprite located a vulnerability in one of NordVPN’s products.

‍

Building Relationships Between Cybersecurity Firms and Vendors

When VerSprite uncovered and disclosed vulnerabilities its researchers found to NordVPN, SolarWinds, and Western Digital, client relationships ensued. Once their security flaws were rectified, VerSprite was able to release details about the exploits.

Researchers frequently publish vulnerability analyses like these across the web. Common platforms include Reddit, Twitter, Hacker News, LinkedIn, GitHub, and various web repositories for collective vulnerability data such as the National Institute of Standards and Technology (NIST) Information Technology Laboratory’s National Vulnerability Database (NVD). Generally, these sites either house the technical intricacies surrounding the vulnerability or link users to websites that do.

For example, NVD’s website provides details on NordVPN’s system privilege escalation vulnerability VerSprite uncovered. Follow-up pieces tell the story of the alliance that formed as a result of responsible vulnerability disclosure, such as this piece NordVPN published on the security audit VerSprite completed to test and analyze its infrastructure.

Security firms and vendors often profile vulnerability reports on their sites as well, such as VerSprite’s responsible disclosure to Western Digital—a massive consumer manufacturer of hard disk drives and data storage. VerSprite located remote command injection and cross-site request forgery (CSRF) vulnerabilities and informed Western Digital. Upon receiving the information, Western Digital acted swiftly to verify and address the issues. It took the initiative to understand the root causes and design strategies to improve its company’s security posture.

Responsible disclosure where VerSprite informed NordVPN, SolarWinds, and Western Digital led to collaboration between VerSprite and each vendor, which in turn resulted in the design and implementation of a more robust security posture for each of the three companies. A look at the wide array of case profiles on NVD or MITRE’s websites quickly reveals that sharing one’s findings through responsible vulnerability disclosure, as VerSprite does, ultimately helps the tech industry further hone its craft and refine security for the betterment of global technology and its users.

‍

VerSprite Security Research for a Vulnerability Disclosure

Maintain awareness regarding unknown threats to your products, technologies, and enterprise networks. Organizations that are willing to take the next step in proactively securing their flagship product or environment can leverage our zero-day vulnerability research offering. Our subscription-based capability provides your organization with immediate access to zero-day vulnerabilities affecting your products and software.

Contact VerSprite →