ISO/IEC 29147:2018 Information Technology – Security Techniques – Vulnerability Disclosure

ISO/IEC 29147:2018 Information Technology – Security Techniques – Vulnerability Disclosure

Status: Final Published

Date: February 2014, Version 1; October 2018, Revised

Region: Global

Document: Link

Background

ISO 29147 has been developed by the ISO and IEC’s JTC 1/SC 27 Technical Committee on Information security, cybersecurity and privacy protection. The standard is available for purchase online in paper or digital copy, although the first version is available for free online.

The standard provides guidance to vendors on how to disclose vulnerabilities in products and services. The goal is to reduce the risk associated with exploiting vulnerabilities. ISO 29147 should be used in conjunction with ISO/IEC 30111:2013 Information Technology — Security Techniques — Vulnerability Handling Processes. Further, ISO 29147 complements technical vulnerability management techniques found in ISO/IEC 27002:2013 Information technology — Security techniques — Code of practice for information security controls.

Summary

Vulnerability disclosure focuses on the techniques and policies for vendors to receive vulnerability reports and publish remediation information. As such, the standard provides a number of tools:

  • Guidelines on receiving reports about potential vulnerabilities
  • Guidelines on disclosing vulnerability remediation information
  • Terms and definitions that are specific to vulnerability disclosure
  • An overview of vulnerability disclosure concepts
  • Techniques and policy considerations for vulnerability disclosure
  • Examples of techniques, policies (Annex A), and communications (Annex B)

The standard starts within definitions (of systems, components, and services) and the roles of the various stakeholders (users, vendors, reporters, coordinators). As such, three main sections are outlined in the standard: receiving vulnerability reports, publishing vulnerability advisories, and creating a vulnerability disclosure policy.

The first section, receiving vulnerability reports, outlines the various ways vendors can set up process to receive information about vulnerabilities and the steps to deal with the information disclosed to them. This includes having the capability to receive reports in the first place (with a dedicated lead capable of monitoring, tracking, and acknowledging the report). The standard provides recommendations on how to assess and investigate the report, as well as how to ensure ongoing communication internally, with the reporter, and coordinate with other affected vendors.

The second section, publishing vulnerability advisories, provides the steps on how to publish information on vulnerabilities (whether received through a vulnerability report, or other). A list of basic advisory elements are listed, which include: identifiers, date and time, title, overview, affected products, intended audience, localization, description, impact, severity, remediation, references, credit, contact information, revision history, and terms of use. Further guidance is offered on the publication timing and communication, the format, and the remediation steps.
A small section is also dedicated to coordination, as products and service can be composed of parts from several vendors. Recommendations are provided on how to report vulnerabilities among vendors.

The last section concerns vulnerability disclosure policies and how to develop them. There are a number of required (contact mechanisms) and recommended (vulnerability report contents, secure communication options, communication expectations, scope, publication and recognition) policy elements outlined, as well as some optional ones (legal considerations and disclosure timeline) that the vendors can include.
The Annexes provide examples of how to implement the three sections. Existing vulnerability disclosure policies reference those from Facebook, CERT/CC, Cisco, and Rapid7, among others. Some example advisories are also provided in another Annex for reference.

Notes

The automotive industry is fairly new to vulnerability disclosure. A number of automotive OEMs have only recently availed themselves of the techniques in light of increasing vulnerability disclosures by security professionals in the last few years (kickstarted by cybersecurity researchers Valasek and Miller in 2015, which started the domino effect for vulnerability disclosure in the automotive industry). Since then, vulnerability disclosure mechanisms such as IDPS are required to be deployed in every connected car, as mentioned in UNECE WP.29.

Auto-ISAC estimates that about 20% of its OEM members have some sort of vulnerability disclosure program in place, and some are also adopting bug bounty programs. This is the easiest way for automotive OEMs to implement vulnerability disclosure. A few (such as Ford, Fiat Chrysler, Toyota, Volkswagen, Hyundai, GM, Nissan, Renault) are using either HackerOne or Bugcrowd, which are ISO 29147-compliant bug bounty platforms to promote their vulnerability disclosure programs, rather than implement their own. The use of specialists in the field, which are already compliant with ISO 29147, significantly facilitates automotive OEMs’ ability to put in place vulnerability disclosure processes.

Learn how we bring peace of mind for millions of drivers