ISO/IEC 30111:2013 Information Technology – Security Techniques – Vulnerability Handling Processes

ISO/IEC 30111:2013 Information Technology – Security Techniques – Vulnerability Handling Processes

Status: Final Published

Date: November 2013, Version 1

Region: Global

Document: Link

Background

ISO 30111 is to be used in conjunction with ISO 29147. It 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.

While ISO 39417 deals with vulnerability disclosure policies and advisories on collecting and disseminating vulnerability information, ISO 30111 provides guidelines on how to process and resolve potential vulnerability information in a product or service. As such, it provides information on how vendors should investigate and resolve potential vulnerabilities, regardless of source. It is targeted at those vendors involved in handling vulnerabilities.

ISO 30111 also takes into consideration ISO/IEC 15408-3:2008 on Information technology — Security techniques — Evaluation criteria for IT security — Part 3: Security assurance components. The standard is under review and will be eventually superseded by ISO/IEC FDIS 30111, which is under development currently.

Summary

The standard recommends that vendors put in place a process and an organizational structure to support vulnerability investigation and remediation. This includes developing a vulnerability handling policy and an organizational framework that can fully support the process.
The basic phases listed for dealing with vulnerability are outlined as followed:

  • Vulnerability Report Received: Either external finder or internal testing; if an external finder
    was the source, then ISO 29147 applies here.
  • Verification: Initial investigation, root cause analysis, further investigation, and prioritization.
    Possible exit conditions for this step include no repro (the bug could not be reproduced), duplicate bug, obsolete product bug, non-security bug, and third-party bug.
  • Resolution Development: These steps include making a resolution decision, producing the appropriate remediation, and testing the remediation.
  • Release Phase: Depending on the type of product affected, the vendor should either plan
    for online service vulnerability resolution, or product vulnerability resolution (release an advisory, for example).
  • Post Release: Case maintenance, security development life cycle feedback (and reference is made here to ISO/IEC 27034 Information technology – Security techniques – Application security), and monitoring.

Vendors are encouraged to coordinate internally (with product business division), with other vendors where appropriate (including within their supply chain), and with affected users. Further, the standard recommends that vendors monitor the time it takes to address a vulnerability using this process, including monitoring the completeness (thoroughness) of the remediation.

Finally, the standard also provides guidance on how to maintain the confidentiality of sensitive vulnerability information (and notably when Personally Identifiable Information (PII) is involved or where the publication of the vulnerability may inordinately benefit attackers). There can be a risk of premature disclosure of sensitive vulnerability information that can potentially increase the costs and risks to vendors and users; therefore, reasonable steps should be taken to protect vulnerability information.

Notes

It is clear that the automotive industry is new to vulnerability handling in the traditional (IT) sense, but the increasing connectivity of both vehicles and transport infrastructure is pushing OEMs to put in place effective vulnerability handling processes. Also, the UNECE WP.29 requires these processes as mandatory, as a part of the CSMS functions.

The Auto-ISAC’s Automotive Cybersecurity Best Practices specifically recommends using ISO 30111 under its Threat Detection and Protection recommendations. It is also recommended by the U.S. DOT’s Volpe National Transportation System Center, which is part of the DOT’s Office of Research and Technology.

As a result, a number of automotive OEMs are working toward implementing appropriate organizational structures, although this is a relatively long and slow process for an industry that is not well-versed in vulnerability handling. Many are looking to external advisors (notably cybersecurity firms) to help them build the appropriate frameworks.

Learn how we bring peace of mind for millions of drivers