The Importance of Effective Researcher-Vendor Engagement in the Vulnerability Disclosure Process

Claroty

By Bar Ofner, Claroty Team82 Security Researcher

---

Over the past several years, thousands of new and exploitable vulnerabilities have been disclosed that affected cyber-physical systems (CPS). This increase in cyber-physical vulnerability disclosures can be seen as a response to mounting cyber threats, which put added pressure on vendors to better understand and collaborate with the research community. It's also important for vendors to develop effective strategies that enable them to triage and remediate security flaws within connected devices before they're exploited in the wild.

For many OT and IoT vendors, navigating the vulnerability disclosure process is new territory. Smaller vendors may be just now taking their first steps toward establishing a successful vulnerability remediation program. In this article, we hope to bring some clarity to the vulnerability disclosure process from the researcher's point of view.

Our Insights From Disclosing 300 Vulnerabilities

Uncovering vulnerabilities in cyber-physical systems takes a substantial amount of experience because it requires the ability to understand how software and firmware packages work, as well as how to trigger vulnerabilities that can be exploited by a threat actor.

Since the inception of Claroty's Team82 research team, we've disclosed close to 400 vulnerabilities to more than 50 affected vendors. After working with so many different vendors, we can draw numerous takeaways:

• In many cases, vendors are diligent about product security and care deeply about their customers, but they lack the expertise and/or technological capabilities to mitigate threats to cyber-physical systems.
• Vendors unfamiliar with the vulnerability disclosure process may be wary of security researchers who discover flaws in their devices, so it's crucial for researchers to communicate clearly that they're here to help.
• Effective communication between researchers and affected vendors remains a challenge, especially for some vendors who haven't established mature disclosure programs and lack secure communication mechanisms.
• Patience is a virtue, and disclosure is a journey. Researchers must take care to treat the other party with utmost respect and establish the rapport needed to work together toward a common goal.

Roadblocks to Communicating Vulnerabilities to Affected Vendors

Often, the first indication a vendor gets about a vulnerability is from a research organization such as Team82, unless an undisclosed flaw is discovered and exploited by adversaries in the wild. Team82 has worked with vendors with varying levels of maturity to disclose vulnerabilities within their devices.

Some vendors' vulnerability disclosure programs start with a dedicated product security page, which should provide a secure email address for reporting vulnerabilities. This page should also make a public PGP key available for encrypted communication about the disclosure. A secure contact page is an indication that the vendor has a well-defined process for accepting vulnerability reports and is intent on improving the overall security of its products.

Five Key Steps to Coordinated Vulnerability Disclosure

1. Vulnerability Discovery: Uncovering new vulnerabilities in one or more of a vendor's products often requires extensive examinations of software and firmware packages, understanding logic flows and code dependencies, and the use of manual and automated means to trigger conditions that would allow an attacker to either crash a device or execute code.
2. Vulnerability Reporting: Once a vulnerability has been confirmed, the researcher reaches out to the affected vendor and shares their findings. This requires researchers to contact the vendors using the dedicated email address provided on the product security page, encrypting the session with a PGP key, getting a ticket/issue-tracking number in response. The researchers must provide as much detailed technical information as possible, including PoCs, and perhaps videos demonstrating exploitation. Ideally, the vendor will then respond to the researchers, letting them know that their disclosure is being reviewed and verified.
3. Vulnerability Triage: The vendor should confirm that the vulnerability indeed exists and assesses its severity. If the vendor has a product computer emergency response team (PCERT), that team should conduct initial review and triage and pass the ticket to the relevant body within the organization, if necessary. Using the information and PoCs provided by the researchers, the PCERT should try to reproduce the vulnerabilities internally, and also target a wider range of versions of the same product that may be affected, as well as other products and specific configurations. Next, the vendor will map all vulnerable product versions that will be used to assess the risk level of this vulnerability.
4. Vulnerability Remediation: The vendor will try to patch or mitigate the vulnerabilities and provide a secure solution to its users. Vendors should also try to understand the root cause in order to prevent the same class of vulnerabilities from surfacing again.
5. Vulnerability Disclosure: The affected vendor must next disclose to users—and the public—that a vulnerability has been reported and patched, either through an advisory or a post on their product security page. The affected vendor should assign each vulnerability a CVE ID through the relevant CVE number authority (CNA). After a CVE ID has been assigned, a relevant advisory should be published. A patch must also be released and distributed to users.

Other Best Practices for Effective Vulnerability Disclosure

• Establish a Product Security Page: This page should serve as the gateway for the PCERT to interact with external researchers finding vulnerabilities in the vendor's products.
• Leverage PGP for Vulnerability Disclosure: PGP (Pretty Good Privacy) is an encryption program for private data communications recommended by Team82. It provides a private channel for disclosing vulnerabilities without the opportunity for a malicious actor to learn about them from the communication between the researcher and affected vendor.
• Disclose Vulnerabilities Across Multiple Channels: Affected vendors may choose to publicly disclose by issuing a security notice email, publishing a security advisory via PDF or other formats, and sharing a security advisory via REST API. All three used in conjunction provides the best experience for the wide range of users who may be interested in knowing which of their devices are vulnerable.
• Components of an Effective Security Advisory: Security advisories should follow a consistent format while containing the following components: CVE ID, Common Vulnerability Scoring System (CVSS) rating, attack vector, Common Weakness Enumeration (CWE), fixed versions, mitigations, documentation, researcher acknowledgements, and related advisories or links if necessary.

Conclusion
Standard practices for vulnerability disclosures are essential and must be adhered to industry-wide. Many cyber-physical system vendors are unprepared when a researcher finds and reports a vulnerability in their products. Team82 recommends vendors follow these guidelines to make their internal and external vulnerability disclosure processes better, safer, and faster.

Original material: claroty.com/team82/blog/understanding-and-improving-the-xiot-vulnerability-disclosure-and-publishing-processes