ISO/IEC TR 5895:2022
(Main)Cybersecurity — Multi-party coordinated vulnerability disclosure and handling
Cybersecurity — Multi-party coordinated vulnerability disclosure and handling
This document clarifies and increases the application and implementation of ISO/IEC 30111 and ISO/IEC 29147 in multi-party coordinated vulnerability disclosure (MPCVD) settings, including the evolving commonly adopted practices in this area, by articulating: — The MPCVD life cycle and application of coordinated vulnerability disclosure (CVD) stages (preparation, receipt, verification, remediation[1] development, release, post-release) in MPCVD settings. — Stakeholders involved in MPCVD include users, vendors (coordinating, mitigating, and dependent vendors), reporters, and non-vendor coordinators (entities defined in ISO/IEC 29147 and ISO/IEC 30111). — The exchange of information between stakeholders during the vulnerability handling and disclosure process in a MPCVD settings. Clarifying the application of ISO/IEC 30111 and ISO/IEC 29147 in MPCVD settings illustrates the benefits of vulnerability disclosure processes. [1] Remediation is a defined term used in ISO/IEC 30111 and ISO/IEC 29147. This document uses the term "remediation" and verb “remediate” in the context of this definition.
Cybersécurité — Divulgation et traitement de vulnérabilité coordonnée entre plusieurs parties
General Information
Buy Standard
Standards Content (Sample)
TECHNICAL ISO/IEC TR
REPORT 5895
First edition
2022-06
Cybersecurity — Multi-party
coordinated vulnerability disclosure
and handling
Cybersécurité — Divulgation et traitement de vulnérabilité
coordonnée entre plusieurs parties
Reference number
ISO/IEC TR 5895:2022(E)
© ISO/IEC 2022
---------------------- Page: 1 ----------------------
ISO/IEC TR 5895:2022(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2022
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
© ISO/IEC 2022 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC TR 5895:2022(E)
Contents Page
Foreword .v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Concepts . 1
4.1 General . 1
4.2 Relationship with other International Standards . 3
4.2.1 I SO/IEC 29147 - Vulnerability disclosure . 3
4.2.2 I SO/IEC 30111 - Vulnerability handling processes . 3
4.2.3 Risk reduction effectiveness . 4
5 MPCVD scenarios . 5
5.1 General . 5
5.2 MPCVD led by the vendor-coordinator (the owner of the technology developed) –
the “mitigating vendor” . 5
5.3 MPCVD process in non-owner cases . 5
6 MPCVD stakeholders .5
6.1 General . 5
6.2 Vendor . 5
6.2.1 Mitigating vendor . 5
6.2.2 Dependent vendor . 6
6.2.3 Mitigating vendor and coordination . 6
6.3 Non-vendor coordinator . . 6
6.4 Reporters . 6
6.5 Users . 6
6.6 Product security incident response team (PSIRT) function . 6
7 MPCVD life cycle . 6
7.1 General . 6
7.2 Policy development . 7
7.2.1 Preparation . 7
7.2.2 Policy . 7
7.3 Strategy development . 7
7.3.1 Information sharing strategy . 7
7.3.2 Disclosure strategy . 7
7.4 Know your customers . 8
7.5 Encrypted communication methods and conference calls . 8
7.6 Processes and controls . 8
8 MPCVD life cycle for each product .8
8.1 Product and user mapping . 8
8.2 Component analysis . 8
8.3 User analysis . 9
9 MPCVD life cycle for each vulnerability . 9
9.1 Receipt. 9
9.2 V erification . . 9
9.3 Remediation development . 10
9.4 Release . 10
9.5 Post-release . 10
9.6 Embargo period . 10
10 Information exchange .11
11 Disclosure .12
iii
© ISO/IEC 2022 – All rights reserved
---------------------- Page: 3 ----------------------
ISO/IEC TR 5895:2022(E)
12 Use case for hardware and further considerations .12
Bibliography .14
iv
© ISO/IEC 2022 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/IEC TR 5895:2022(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance
are described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria
needed for the different types of ISO documents should be noted. This document was drafted in
accordance with the editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives
orwww.iec.ch/members_experts/refdocs).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/
or on the ISO list of patent declarations received (see www.iso.org/patents) or the IEC list of patent
declarations received (see patents.iec.ch).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to
the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see
www.iso.org/iso/foreword.html. In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 27, Information security, cybersecurity and privacy protection.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-committees.
v
© ISO/IEC 2022 – All rights reserved
---------------------- Page: 5 ----------------------
ISO/IEC TR 5895:2022(E)
Introduction
Remediation of vulnerabilities in modern technology systems can vary and depend on the nature of the
vulnerable component. Certain vulnerability handling efforts can require multiple ecosystem players
taking action at multiple and interdependent layers within a given information and communication
technology (ICT) system. Mitigation can necessitate the engagement of the broad ecosystem of
stakeholders to develop, test and deploy mitigations in a manner geared to incentivize adoption by end
users.
For example, a vulnerability in a widely used software library (protocol) can entail action by different
ecosystem players as part of the remediation effort. As another example, a remediation development
and testing for a vulnerability in a hardware component can depend on an operating system running
on the hardware, and require different actions from different operating system providers. Due to
these considerations, multiple vendors need to participate in remediation efforts involving certain
vulnerabilities.
Yet vulnerability disclosure and handling processes as described in ISO/IEC 29147 and
ISO/IEC 30111 primarily focus on processes involving one reporter and one vendor. Further discussion
and considerations are necessary to explain how ISO/IEC 29147 and ISO/IEC 30111 practices apply in
the context of multi-party coordinated vulnerability handling and disclosure (MPCVD).
ISO/IEC 29147 and ISO/IEC 30111:2019, Clause 8 briefly and generally address the complex
situation of MPCVD, where a broader collaboration within the ecosystem is needed to identify and
validate vulnerabilities, develop and test mitigations and finally make them available for end users.
ISO/IEC 30111 refers to these situations as “cases where vendors can share vulnerability information in
order to resolve the issue that involves components from multiple vendors” and provide five examples
of such situations or reasons:
a) A vulnerability which was reported that affects a specific piece of software, but is caused by an
issue in an underlying operating system or hardware.
b) Vulnerabilities in various product implementations of a flawed standard functional specification or
in published algorithms.
c) Vulnerabilities that are naturally induced by so far widely accepted development methodology.
d) Vulnerabilities in commonly used libraries.
e) Vulnerabilities in software components that lack a current maintainer.
The MPCVD effort for a vulnerability in a technology owned and manufactured by the vendor leading
the process – the coordinating vendor, or mitigating vendor manages and leads the coordination effort.
The mitigating vendor (example a) above) can entail different processes from one in which a broader
collaboration is needed and there is no one distinct vendor of the technology (e.g. protocol-level
vulnerabilities) (examples b) to e) above). These examples include both vendor-coordinated MPCVD
and non-owner MPCVD. Recognizing MPCVD can raise unique considerations for vulnerability handling
given the technical and coordination complexities. Several documents have been published to share
norms and best practices in this evolving area. These best practices continue to be developed, iterated
and improved as new challenges arise. This document builds upon these sources and refers to them.
The audience for this document includes, among others, the participants of the MPCVD process such
as vendors (defined in ISO/IEC 29147:2018, 3.4), maintainers, producers, developers, manufacturers,
1)
suppliers , installers, or providers of a product or service, coordinators (including public coordinators),
reporters (e.g. security researchers), and users of information technology products and services.
1) By way of example, when the open source maintainer is leading the coordination effort in the non-owner
MPCVD case or as “dependent vendor”, a “vendor” can also include open-source software maintainers who develop
and distribute code.
vi
© ISO/IEC 2022 – All rights reserved
---------------------- Page: 6 ----------------------
TECHNICAL REPORT ISO/IEC TR 5895:2022(E)
Cybersecurity — Multi-party coordinated vulnerability
disclosure and handling
1 Scope
This document clarifies and increases the application and implementation of ISO/IEC 30111 and
ISO/IEC 29147 in multi-party coordinated vulnerability disclosure (MPCVD) settings, including the
evolving commonly adopted practices in this area, by articulating:
— The MPCVD life cycle and application of coordinated vulnerability disclosure (CVD) stages
2)
(preparation, receipt, verification, remediation development, release, post-release) in MPCVD
settings.
— Stakeholders involved in MPCVD include users, vendors (coordinating, mitigating, and dependent
vendors), reporters, and non-vendor coordinators (entities defined in ISO/IEC 29147 and
ISO/IEC 30111).
— The exchange of information between stakeholders during the vulnerability handling and disclosure
process in a MPCVD settings.
Clarifying the application of ISO/IEC 30111 and ISO/IEC 29147 in MPCVD settings illustrates the
benefits of vulnerability disclosure processes.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 29147:2018, Information technology — Security techniques — Vulnerability disclosure
ISO/IEC 30111:2019, Information technology — Security techniques — Vulnerability handling processes
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 30111 and ISO/IEC 29147
and the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
4 Concepts
4.1 General
MPCVD processes are generally based on two concepts: (1) when security vulnerabilities arise, vendors
work quickly, collaboratively and effectively to mitigate the vulnerabilities, and (2) all involved parties
(which includes the various entities working on the mitigations and the reporters who discovered
2) Remediation is a defined term used in ISO/IEC 30111 and ISO/IEC 29147. This document uses the term
"remediation" and verb “remediate” in the context of this definition.
1
© ISO/IEC 2022 – All rights reserved
---------------------- Page: 7 ----------------------
ISO/IEC TR 5895:2022(E)
or reported the vulnerabilities, if applicable) simultaneously take steps to decrease the risk that
information about the vulnerabilities becomes publicly available before mitigations are available, in
order to protect end users.
The implication for MPCVD is that processes can take a longer period than in other environments (such
as traditional CVD processes involving one entity in the handling processes) to fully develop, validate
and deploy mitigations while information concerning the vulnerability is simultaneously kept in
confidence (often termed, “embargo”) to protect end users from potential exploitation. The embargo
period is during the vulnerability handling process but prior to public disclosure, during which
information concerning the vulnerability is kept in confidence and only shared with entities necessary
for the remediation development process. Similar to other CVD processes, MPCVD processes rely on
the notion that information concerning the vulnerability is generally publicly disclosed only after
mitigations are available to end users.
The MPCVD effort for a vulnerability in a technology owned and manufactured by the vendor leading
the process can entail different processes from one in which a broader collaboration is needed and
there is no one distinct vendor of the technology (e.g. protocol-level vulnerabilities).
MPCVD processes, generally include a higher level of complexity and involvement by a wide range of
stakeholders in the various stages of CVD, as shown in Figure 1. For example, generally the MPCVD
process cases where there is a security vulnerability affecting hardware often need broader
collaboration within the ecosystem. Mitigation of vulnerabilities in hardware can require acting at
multiple and interdependent layers within a given computing system. This, in turn, can necessitate the
engagement of a larger number of third-party participants to develop, test and deploy mitigations in
a manner most likely to incentivize adoption by end users. Mitigation of a hardware vulnerability can
require updates to processor microcode and/or firmware, as well as interdependent updates to the
operating system software or other system software. These updates are then delivered to end-users
through multiple channels, including operating system (OS) and virtualization vendors, cloud service
providers (CSP) or original equipment system manufacturers (OEM). Hardware manufacturers often
do not have a means to unilaterally deliver mitigations without the direct participation of such entities
in the global supply chain.
Figure 1 — Example of vendor-coordinator led MPCVD process — coordinated vulnerability
[1]
disclosure in hardware systems
2
© ISO/IEC 2022 – All rights reserved
---------------------- Page: 8 ----------------------
ISO/IEC TR 5895:2022(E)
4.2 Relationship with other International Standards
4.2.1 ISO/IEC 29147 - Vulnerability disclosure
ISO/IEC 29147 is used in conjunction with this document. The relationship between the two documents
is shown in Figure 2.
ISO/IEC 29147 provides guidelines for vendors on how to process and remediate potential vulnerabilities
reported by internal or external individuals or organizations. While this document deals with the
interface between multiple vendors, layers of customers, cross manufacturer collaborative mitigation
strategies and multiple reporters, ISO/IEC 29147 provides guidelines for vendors to include in their
normal business processes when receiving reports about potential vulnerabilities from external
individuals or organizations and when distributing vulnerability remediation information to affected
users. This document clarifies the application of these disclosure-related processes in MPCVD settings.
4.2.2 ISO/IEC 30111 - Vulnerability handling processes
ISO/IEC 30111 is used in conjunction with this document. The relationship between the two documents
is shown in Figure 2.
ISO/IEC 30111 gives guidelines on how to investigate, process and resolve potential vulnerability
reports. While this document deals with the interface between multiple vendors, layers of customers,
cross manufacturer collaborative mitigation strategies and multiple reporters, ISO/IEC 30111 deals
with internal vendor processes including the triage, investigation and remediation of vulnerabilities,
whether the source of the report is external to the vendor or from within the vendor’s own security,
development or testing teams. This document clarifies the application of these handling-related
processes in MPCVD settings.
3
© ISO/IEC 2022 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/IEC TR 5895:2022(E)
Figure 2 — The relationship between ISO/IEC 29147 and ISO/IEC 30111 with respect to MPCVD
4.2.3 Risk reduction effectiveness
Similar to the concept of the impact of successful exploitation referred to in ISO/IEC 30111, risk
reduction effectiveness is an element that can be considered in the context of MPCVD. The risk
reduction effectiveness measures the effectiveness of public disclosure and associated mitigation
and/or remediation against the total cost to society if the vulnerability is exploited. Risk reduction
effectiveness is a function that is affected by a variety of uncertainties, such as:
— Malicious attackers gaining knowledge about vulnerabilities from disclosed vulnerability and
mitigation information, increasing exploitation risk.
— Delayed delivery and/or publication of mitigations and vulnerabilities because there are multiple
contributors (e.g. vendors and open source maintainers) that need to be engaged or added to the
engagement.
— The need for collaboration between vendors across the supply chain, either vertically (vendors
participating and supplying various components to the final product) or horizontally (vulnerability-
affected vendors scattered in a supply chain) can increase the coordination period and introduce
unpredictable variables along the process that can impact expectations around timeline/embargo
periods.
4
© ISO/IEC 2022 – All rights reserved
---------------------- Page: 10 ----------------------
ISO/IEC TR 5895:2022(E)
MPCVD increases the summation of the risk reduction effectiveness. In other words, a primary
purpose of MPCVD is to reduce the potential harm to users and the public by increasing the effective
collaborations in the relevant CVD stages prior the public release, which includes increasing the
completeness and effectiveness of the proposed remediation while incentivizing its adoption by end
users at disclosure.
5 MPCVD scenarios
5.1 General
Clause 5 provides common scenarios of MPCVD in the scope of this document.
5.2 MPCVD led by the vendor-coordinator (the owner of the technology developed) –
the “mitigating vendor”
In the MPCVD case of the vendor-coordinator (e.g. hardware), there is generally a clear owner/developer
of the underlying vulnerable technology who is typically best-situated to lead the coordination effort
as the most technically knowledgeable of the product and component supply chain. For example,
software companies, including operating systems and firmware vendors, and virtualization vendors
can be integral to the process of developing and testing a mitigation for a hardware-based vulnerability
(taking part in the handling processes), which are coordinated and led by the hardware manufacturer,
as the mitigating vendor. In different MPCVD settings where there is no clear owner of the technology/
manufacturer best-situated to lead the coordination efforts (for example, in certain protocol-level
vulnerabilities), a different entity can act as a coordinator, leading the coordination effort.
5.3 MPCVD process in non-owner cases
In the case where there is no clear owner of the technology who is typically best-situated to lead the
remediation development and other CVD processes, a different “coordinator” (see ISO/IEC 29147:2018,
5.5.5) can act as the entity or intermediary leading the MPCVD process.
6 MPCVD stakeholders
6.1 General
Clause 6 describes significant stakeholder roles beyond those found in ISO/IEC 29147.
6.2 Vendor
ISO/IEC 29147 provides the definition of a vendor. Vendors are described as individuals or organizations
who create or provide software products, including manufacturers, developers, or distributors. MPCVD
allows for vendors to take on the following roles. Additionally, vendors can also act as coordinators
depending on the issue.
6.2.1 Mitigating vendor
Mitigating vendors lead the MPCVD process, including facilitating the coordination with dependent
vendors (e.g. disseminating the proposed mitigation developed by the mitigating vendor to dependent
vendors and coordinating its testing in various environments). This can include coordinating the
dependent vendor contribution to the remediation development (e.g. if independent mitigations
developed by the dependent vendor need to be applied along with the proposed remediation to fully
protect against a specific security vulnerability and subsequently released together).
5
© ISO/IEC 2022 – All rights reserved
---------------------- Page: 11 --------
...
0ISO/IEC TR 5895/SC 27 Nxxx
Date: 2022-01-11
ISO/IEC TR 5895, :2022(E)
Date: 2022-04-22
Cybersecurity — Multi-party coordinated vulnerability disclosure and handling
---------------------- Page: 1 ----------------------
ISO/IEC TR 5895 (2022)
© ISO 2022
All rights reserved. Unless otherwise specified, or required in the context of its implementation,
no part of this publication may be reproduced or utilized otherwise in any form or by any means,
electronic or mechanical, including photocopying, or posting on the internet or an intranet,
without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.orgwww.iso.org
Published in Switzerland
ii © ISO 2021– All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC TR 5895
Contents
Foreword . v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Concepts . 1
4.1 General . 1
4.2 Relationship with other International Standards . 3
4.2.1 ISO/IEC 29147 - Vulnerability disclosure . 3
4.2.2 ISO/IEC 30111 - Vulnerability handling processes . 3
4.2.3 Risk Reduction Effectiveness . 4
5 MPCVD Scenarios in Scope . 5
5.1 General . 5
5.2 MPCVD lead by the vendor-coordinator (the owner of the technology
developed) – the “mitigating vendor” . 5
5.3 MPCVD process in non-owner cases . 5
6 MPCVD Stakeholders . 5
6.1 General . 5
6.2 Vendor . 5
6.2.1 Mitigating Vendor . 5
6.2.2 Dependent Vendor . 6
6.2.3 Mitigating Vendor and Coordination . 6
6.3 Non-Vendor Coordinator . 6
6.4 Reporters . 6
6.5 Users . 6
6.6 Product Security Incident Response Team (PSIRT) Function . 6
7 MPCVD Lifecycle . 7
7.1 General . 7
7.2 Policy Development . 7
7.2.1 Preparation . 7
7.2.3 Policy . 7
7.3 Strategy development . 7
7.3.1 Information Sharing Strategy . 7
7.3.2 Disclosure Strategy . 8
7.4 Know your customers . 8
7.5 Encrypted Communication Methods and Conference Calls . 8
7.6 Processes and Controls . 8
8 MPCVD lifecycle for each product . 9
8.1 Product and User Mapping . 9
8.2 Component Analysis . 9
8.3 User Analysis . 9
9 MPCVD lifecycle for each vulnerability . 9
9.1 Receipt . 9
9.2 Verification . 9
9.3 Remediation development . 10
© ISO 2022 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/IEC TR 5895 (2022)
9.4 Release . 10
9.5 Post Release . 10
9.6 Embargo Period . 11
10 Information exchange . 12
11 Disclosure . 12
12 Considerations for further improvement . 13
Bibliography . 15
iv © ISO 2021– All rights reserved
---------------------- Page: 4 ----------------------
ISO/IEC TR 5895
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national
standards bodies (ISO member bodies). The work of preparing International Standards is normally
carried out through ISO technical committees. Each member body interested in a subject for which
a technical committee has been established has the right to be represented on that committee.
International organizations, governmental and non-governmental, in liaison with ISO, also take
part in the work. ISO collaborates closely with the International Electrotechnical Commission (IEC)
on all matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for
the different types of ISO documents should be noted. This document was drafted in accordance
with the editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives). or
www.iec.ch/members_experts/refdocs).
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO shall not be held responsible for identifying any or all such patent rights.
Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www.iso.org/patents).) or
the IEC list of patent declarations received (see patents.iec.ch).
Any trade name used in this document is information given for the convenience of users and does
not constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see
www.iso.org/iso/foreword.html. In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Technical Committee ISO/IEC JTC 1/SC 27, Information
technology, Subcommittee SC 27, Information security, cybersecurity and privacy protection, WG 3
“Security evaluation, testing and specification”.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html. and
www.iec.ch/national-committees.
© ISO 2022 – All rights reserved v
---------------------- Page: 5 ----------------------
ISO/IEC TR 5895 (2022)
Introduction
Remediation of vulnerabilities in modern technology systems can vary and depend on the nature
of the vulnerable component. Certain vulnerability handling efforts can require multiple ecosystem
players taking action at multiple and interdependent layers within a given information and
communication technology (ICT) system. Mitigation can necessitate the engagement of the broad
ecosystem of stakeholders to develop, test and deploy mitigations in a manner geared to incentivize
adoption by end users.
For example, a vulnerability in a widely used software library (protocol) can entail action by
different ecosystem players as part of the remediation effort. As another example, a remediation
development and testing for a vulnerability in a hardware component can depend on an operating
system running on the hardware, and require different actions from different operating system
providers. Due to these considerations, multiple vendors need to participate in remediation efforts
involving certain vulnerabilities.
Yet vulnerability disclosure and handling processes as described in ISO/IEC 29147 and ISO/IEC
30111 focus primarily focus on processes involving one reporter and one vendor. Further
discussion and considerations are necessary to explain how ISO/IEC 29147 and ISO/IEC 30111
practices apply in the context of Multi-Party Coordinated Vulnerability Handling and
Disclosuremulti-party coordinated vulnerability handling and disclosure (MPCVD).
ISO/IEC 29147 and ISO/IEC 30111 standards :2019, Clause 8 briefly and generally address, under
clause 8 of ISO/IEC 30111: 2019, the complex situation of MPCVD, where a broader collaboration
within the ecosystem is needed to identify and validate vulnerabilities, develop and test mitigations
and finally make them available for end users. ISO/IEC 30111 refers to these situations as “cases
where vendors can share vulnerability information in order to resolve the issue that involves
components from multiple vendors” and provide five examples of such situations or reasons:
a) A vulnerability which was reported that affects a specific piece of software, but is caused by an
issue in an underlying operating system or hardware;.
b) Vulnerabilities in various product implementations of a flawed standard functional
specification or in published algorithms;.
c) Vulnerabilities that are naturally induced by so far widely accepted development
methodology;.
d) Vulnerabilities in commonly used libraries;.
e) Vulnerabilities in software components that lack a current maintainer.
The MPCVD effort for a vulnerability in a technology owned and manufactured by the vendor
leading the process – the coordinating vendor, or mitigating vendor manages and leads the
coordination effort. The mitigating vendor (example a.) above) can entail different processes
thanfrom one in which a broader collaboration is needed and there is no one distinct vendor of the
technology (e.g.,. protocol-level vulnerabilities) (exampleexamples b-) to e) above). These
examples include both vendor-coordinated MPCVD and non-owner MPCVD. Recognizing MPCVD
can raise unique considerations for vulnerability handling given the technical and coordination
complexities. Several documents have been published to share norms and best practices in this
evolving area. These best practices continue to be developed, iterated, and improved as new
challenges arise. This document builds upon these sources and refers to them.
vi © ISO 2021– All rights reserved
---------------------- Page: 6 ----------------------
ISO/IEC TR 5895
The audience for this document includes, among others, the participants of the MPCVD process
such as vendors (defined in clause 3.4 of ISO/IEC 29147: 2018, 3.4), maintainers, producers,
1
developers, manufacturers, suppliers , installers, or providers of a product or service, coordinators
(including public coordinators), reporters (e.g.,. security researchers), and users of information
technology products and services.
1
By way of example, when the open source maintainer is leading the coordination effort in the non-owner
MPCVD case, or as “dependent vendor”, a “Vendor” mayvendor” can also include open-source software
maintainers who develop and distribute code.
© ISO 2022 – All rights reserved vii
---------------------- Page: 7 ----------------------
ISO/IEC TR 5895 (:2022(E)
Information security, cybersecurity and privacy protection —
8 © ISO 2021– All rights reserved
viii © ISO/IEC 2022 – All rights reserved
---------------------- Page: 8 ----------------------
TECHNICAL REPORT ISO/IEC TR 5895:2022(E)
Cybersecurity — Multi-party coordinated vulnerability
disclosure and handling
1 Scope
This document clarifies and augmentsincreases the application and implementation of ISO/IEC
30111 and ISO/IEC 29147 in multi-party coordinated vulnerability disclosure (MPCVD) settings,
including the evolving commonly adopted practices in this area, by articulating:
— The MPCVD lifecyclelife cycle and application of coordinated vulnerability disclosure (CVD)
2
stages (Preparation, Receipt, Verification, Remediation Development, Release,
3
Postpreparation, receipt, verification, remediation development, release, post-release) in
MPCVD settings.
— Stakeholders involved in MPCVD include users, vendors (Coordinating,
Mitigatingcoordinating, mitigating, and Dependentdependent vendors), reporters, and
Nonnon-vendor coordinators (entities defined in ISO/IEC 29147, and ISO/IEC 30111).
— The exchange of information between stakeholders during the vulnerability handling and
disclosure process in a MPCVD settings.
Clarifying the application of ISO/IEC 30111 and ISO/IEC 29147 in MPCVD settings illustrates the
benefits of vulnerability disclosure processes.
2 2 Normative references
No normative references.
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments)
applies.
ISO/IEC 29147:2018, Information technology — Security techniques — Vulnerability disclosure
ISO/IEC 30111:2019, Information technology — Security techniques — Vulnerability handling
processes
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 30111 and ISO/IEC
29147 and the following apply.
2
Remediation is a defined term used in ISO/IEC 30111:2019 and ISO/IEC 29147:2018,this document uses
the term remediation and verb “remediate”, in the context of this definition.
3
Remediation is a defined term used in ISO/IEC 30111 and ISO/IEC 29147. This document uses the term
"remediation" and verb “remediate” in the context of this definition.
© ISO/IEC 2022 – All rights reserved 1
---------------------- Page: 9 ----------------------
ISO/IEC TR 5895 (:2022(E)
ISO and IEC maintain terminologicalterminology databases for use in standardization at the
following addresses:
— ISO Online browsing platform: available at
https://www.iso.org/obphttps://www.iso.org/obp
— IEC Electropedia: available at http://www.electropedia.org/https://www.electropedia.org/
4 Concepts
4.1 General
MPCVD processes are generally based on two concepts: (1) when security vulnerabilities arise,
vendors work quickly, collaboratively, and effectively to mitigate the vulnerabilities, and (2) all
involved parties (which includes the various entities working on the mitigations and the reporters
who discovered or reported the vulnerabilities, if applicable) simultaneously take steps to decrease
the risk that information about the vulnerabilities becomes publicly available before mitigations
are available, in order to protect end users.
The implication for MPCVD is that processes can take a longer period than in other environments
(such as traditional CVD processes involving one entity in the handling processes) to fully develop,
validate and deploy mitigations while information concerning the vulnerability is simultaneously
kept in confidence (often termed, “embargo”) to protect end users from potential exploitation. The
embargo period is during the vulnerability handling process but prior to public disclosure, during
which information concerning the vulnerability is kept in confidence and only shared with entities
necessary for the remediation development process. Similar to other CVD processes, MPCVD
processes rely on the notion that information concerning the vulnerability is generally publicly
disclosed only after mitigations are available to end users.
The MPCVD effort for a vulnerability in a technology owned and manufactured by the vendor
leading the process can entail different processes thanfrom one in which a broader collaboration
is needed and there is no one distinct vendor of the technology (e.g.,. protocol-level vulnerabilities).
MPCVD processes, generally include a higher level of complexity and involvement by a wide range
of stakeholders in the various stages of CVD, as illustratedshown in figure Figure 1. For example,
generally the MPCVD process cases where there is a security vulnerability affecting hardware often
requiresneed broader collaboration within the ecosystem. Mitigation of vulnerabilities in
hardware can require acting at multiple and interdependent layers within a given computing
system. This, in turn, can necessitate the engagement of a larger number of third-party participants
to develop, test and deploy mitigations in a manner most likely to incentivize adoption by end users.
Mitigation of a hardware vulnerability can require updates to processor microcode and/or
firmware, as well as interdependent updates to the operating system software or other system
software. These updates are then delivered to end-users through multiple channels, including
Operating Systemoperating system (OS) and virtualization vendors, Cloud Service Providerscloud
service providers (CSP) or Original Equipment System Manufacturersoriginal equipment system
2 © ISO 2022– All rights reserved
2 © ISO/IEC 2022 – All rights reserved
---------------------- Page: 10 ----------------------
ISO/IEC TR 5895:2022(E)
manufacturers (OEM). Hardware manufacturers often do not have a means to unilaterally deliver
mitigations without the direct participation of such entities in the global supply chain.
© ISO 2022 – All rights reserved 3
© ISO/IEC 2022 – All rights reserved 3
---------------------- Page: 11 ----------------------
ISO/IEC TR 5895 (:2022(E)
1. FINDER(S) 2. COMPONENT OWNER 3. PATCH DEVELOPMENT & TESTING
COORDINATION PARTNERS
Component
PATCHING
vendors with TESTING Cloud
operating system
Coordinated vulnerability disclosure
similar providers
(OS) testing
vulnerabilities partners
Find vulnerabilities and
Validates vulnerability and
share details with the
develops foundational
component manufacturer/
level fixes.
vendors.
CERTS
PATCHING
Original PATCHING Basic TESTING
equipment Input/Output virtualization
Computer Emergency Response
manufacturers System TESTING vendors
Teams
(OEMs) TESTING
STANDARDS PARTNERS
4. PATCH DISTRIBUTION PARTNERS 5. THE PATCH IS RELEASED TO THE PUBLIC
Coordinated vulnerability disclosure
standards development organizations
Public can be corporate enterprises and/or
When the patch is ready, it is sent to distribution consumers. The patch can be shared by one of the
partners to include within their patch release cycle partners or from the component manufacturer/
vendor themselves.
4 © ISO 2022– All rights reserved
4 © ISO/IEC 2022 – All rights reserved
---------------------- Page: 12 ----------------------
ISO/IEC TR 5895:2022(E)
Figure 1: — Example of vendor-coordinator led MPCVD process — Coordinated
Vulnerability Disclosurecoordinated vulnerability disclosure in Hardware
4 [1]
Systems hardware systems
4.2 Relationship with other International Standards
4.2.1 ISO/IEC 29147 - Vulnerability disclosure
ISO/IEC 29147 is used in conjunction with this document. The relationship between the two
documents is illustratedshown in Figure 2.
ISO/IEC 29147 This document provides guidelines for vendors on how to process and remediate
potential vulnerabilities reported by internal or external individuals or organizations. While this
document deals with the interface between multiple vendors, layers of customers, cross
manufacturer collaborative mitigation strategies and multiple reporters, ISO/IEC 29147 provides
guidelines for vendors to include in their normal business processes when receiving reports about
potential vulnerabilities from external individuals or organizations and when distributing
vulnerability remediation information to affected users. This document clarifies the application of
these disclosure-related processes in MPCVD settings.
4.2.2 ISO/IEC 30111 - Vulnerability handling processes
ISO/IEC 30111 is used in conjunction with this document. The relationship between the two
documents is illustratedshown in Figure 2.
ISO/IEC 30111 gives guidelines on how to investigate, process, and resolve potential vulnerability
reports. While this document deals with the interface between multiple vendors, layers of
customers, cross manufacturer collaborative mitigation strategies and multiple reporters, ISO/IEC
30111 deals with internal vendor processes including the triage, investigation, and remediation of
vulnerabilities, whether the source of the report is external to the vendor or from within the
vendor’s own security, development, or testing teams. This document clarifies the application of
these handling-related processes in MPCVD settings.
4
Derived from source available at Center for Cybersecurity Policy and Law, Improving Hardware
Component Vulnerability Disclosure (see https://centerforcybersecuritypolicy.org/improving-hardware-
component-vulnerability-disclosure).
© ISO 2022 – All rights reserved 5
© ISO/IEC 2022 – All rights reserved 5
---------------------- Page: 13 ----------------------
ISO/IEC TR 5895 (:2022(E)
ISO/IEC 29147 ISO/IEC 30111 Multi-Party Coordinated
Vulnerability Disclosure Vulnerability Handling Process Vulnerability Disclosure
Develop vulnerability Develop mapping of
Develop vulnerability
handling policy and product/vendor
disclosure policy
organizational framework interdependency
Develop list of vendors that
Develop capability to receive
can assist in mitigations vs
and publish vulnerability
those only dependent on
information
mitigations
Develop framework for
Receive vulnerability report Identify vulnerability from disclosing to vendors and
from an external source internal source reporters and coordinating
public disclosure
Acknowledge Receipt Verify report
Determine if other vendors
Inform Reporter Vulnerability verified?
may be impacted.
No
Yes
Develop and deploy
Publish Advisory
remediation
Notify vendors that can
contribute to the
mitigation, inform the
reporters of MPCVD
strategy,
Engage in post-remediation
activities
6 © ISO 2022– All rights reserved
6 © ISO/IEC 2022 – All rights reserved
---------------------- Page: 14 ----------------------
ISO/IEC TR 5895:2022(E)
Figure 2: — The relationship between ISO/IEC 29147 and ISO/IEC 30111 with respect to
MPCVD.
4.2.3 Risk Reduction Effectiveness reduction effectiveness
Similar to the concept of the impact of successful exploitation, referred to in ISO/IEC 30111, Risk
Reduction Effectivenessrisk reduction effectiveness is an element that can be considered in the
context of MPCVD. The Risk Reduction Effectivenessrisk reduction effectiveness measures the
effectiveness of public disclosure and associated mitigation and/or remediation against the total
cost to society if the vulnerability is exploited. Risk Reduction Effectivenessreduction effectiveness
is a function that is affected by a variety of uncertainties, such as:
— Malicious attackers gaining knowledge about vulnerabilities from disclosed vulnerability and
mitigation information, increasing exploitation risk.
© ISO 2022 – All rights reserved 7
© ISO/IEC 2022 – All rights reserved 7
---------------------- Page: 15 ----------------------
ISO/IEC TR 5895 (:2022(E)
— Delayed delivery and/or publication of mitigations and vulnerabilities because there are
multiple contributors (e.g.,. vendors and open source maintainers) that need to be engaged or
added to the engagement.
— The need for collaboration between vendors across the supply chain:, either vertically
(vendors participating and supplying various components to the final product) or horizontally
(vulnerability-affected vendors scattered in a supply chain) can increase the coordination
period, and introduce unpredictable variables along the process that can impact expectations
around timeline/embargo periods.
MPCVD increases the summation of the Risk Reduction Effectiveness.risk reduction effectiveness.
In other words, a primary purpose of MPCVD is to reduce the potential harm to users and the public
by increasing the effective collaborations in the relevant CVD stages prior the public release, which
includes increasing the completeness and effectiveness of the proposed remediation while
incentivizing its adoption by end users at disclosure.
5 MPCVD Scenarios in Scope scenarios
5.1 General
This clauseClause 5 provides common scenarios of MPCVD in the scope forof this document.
5.2 MPCVD led by the vendor-coordinator (the owner of the technology developed)
– the “mitigating vendor”
In the MPCVD case of the vendor-coordinator (e.g.,. hardware), there is generally a clear
owner/developer of the underlying vulnerable technology who is typically best -situated to lead
the coordination effort as the most technically knowledgeable of the product and component
supply chain. For example, software companies, including operating systems and firmware
vendors, and virtualization vendors can be integral to the process of developing and testing a
mitigation for a hardware-based vulnerability (taking part in the handling processes), which are
coordinated and led by the hardware manufacturer, as the mitigating vendor. In different MPCVD
settings where there is no clear owner of the technology/manufacturer best -situated to lead the
coordination efforts (for example, in certain protocol-level vulnerabilities), a different entity can
act as a coordinator, leading the coordination effort.
5.3 MPCVD process in non-owner cases
In the
...
TECHNICAL ISO/IEC TR
REPORT 5895
First edition
Cybersecurity — Multi-party
coordinated vulnerability disclosure
and handling
PROOF/ÉPREUVE
Reference number
ISO/IEC TR 5895:2022(E)
© ISO/IEC 2022
---------------------- Page: 1 ----------------------
ISO/IEC TR 5895:2022(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2022
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
PROOF/ÉPREUVE © ISO/IEC 2022 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC TR 5895:2022(E)
Contents Page
Foreword .v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Concepts . 1
4.1 General . 1
4.2 Relationship with other International Standards . 3
4.2.1 I SO/IEC 29147 - Vulnerability disclosure . 3
4.2.2 I SO/IEC 30111 - Vulnerability handling processes . 3
4.2.3 Risk reduction effectiveness . 4
5 MPCVD scenarios . 5
5.1 General . 5
5.2 MPCVD led by the vendor-coordinator (the owner of the technology developed) –
the “mitigating vendor” . 5
5.3 MPCVD process in non-owner cases . 5
6 MPCVD stakeholders .5
6.1 General . 5
6.2 Vendor . 5
6.2.1 Mitigating vendor . 5
6.2.2 Dependent vendor . 6
6.2.3 Mitigating vendor and coordination . 6
6.3 Non-vendor coordinator . . 6
6.4 Reporters . 6
6.5 Users . 6
6.6 Product security incident response team (PSIRT) function . 6
7 MPCVD life cycle . 6
7.1 General . 6
7.2 Policy development . 7
7.2.1 Preparation . 7
7.2.2 Policy . 7
7.3 Strategy development . 7
7.3.1 Information sharing strategy . 7
7.3.2 Disclosure strategy . 7
7.4 Know your customers . 8
7.5 Encrypted communication methods and conference calls . 8
7.6 Processes and controls . 8
8 MPCVD life cycle for each product .8
8.1 Product and user mapping . 8
8.2 Component analysis . 8
8.3 User analysis . 9
9 MPCVD life cycle for each vulnerability . 9
9.1 Receipt. 9
9.2 V erification . . 9
9.3 Remediation development . 10
9.4 Release . 10
9.5 Post-release . 10
9.6 Embargo period . 10
10 Information exchange .11
11 Disclosure .12
iii
© ISO/IEC 2022 – All rights reserved PROOF/ÉPREUVE
---------------------- Page: 3 ----------------------
ISO/IEC TR 5895:2022(E)
12 Use case for hardware and further considerations .12
Bibliography .14
iv
PROOF/ÉPREUVE © ISO/IEC 2022 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/IEC TR 5895:2022(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance
are described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria
needed for the different types of ISO documents should be noted. This document was drafted in
accordance with the editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives
orwww.iec.ch/members_experts/refdocs).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/
or on the ISO list of patent declarations received (see www.iso.org/patents) or the IEC list of patent
declarations received (see patents.iec.ch).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to
the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see
www.iso.org/iso/foreword.html. In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Technical Committee ISO/IEC JTC 1/SC 27, Information technology,
Subcommittee SC 27, Information security, cybersecurity and privacy protection.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-committees.
v
© ISO/IEC 2022 – All rights reserved PROOF/ÉPREUVE
---------------------- Page: 5 ----------------------
ISO/IEC TR 5895:2022(E)
Introduction
Remediation of vulnerabilities in modern technology systems can vary and depend on the nature of the
vulnerable component. Certain vulnerability handling efforts can require multiple ecosystem players
taking action at multiple and interdependent layers within a given information and communication
technology (ICT) system. Mitigation can necessitate the engagement of the broad ecosystem of
stakeholders to develop, test and deploy mitigations in a manner geared to incentivize adoption by end
users.
For example, a vulnerability in a widely used software library (protocol) can entail action by different
ecosystem players as part of the remediation effort. As another example, a remediation development
and testing for a vulnerability in a hardware component can depend on an operating system running
on the hardware, and require different actions from different operating system providers. Due to
these considerations, multiple vendors need to participate in remediation efforts involving certain
vulnerabilities.
Yet vulnerability disclosure and handling processes as described in ISO/IEC 29147 and
ISO/IEC 30111 primarily focus on processes involving one reporter and one vendor. Further discussion
and considerations are necessary to explain how ISO/IEC 29147 and ISO/IEC 30111 practices apply in
the context of multi-party coordinated vulnerability handling and disclosure (MPCVD).
ISO/IEC 29147 and ISO/IEC 30111:2019, Clause 8 briefly and generally address the complex
situation of MPCVD, where a broader collaboration within the ecosystem is needed to identify and
validate vulnerabilities, develop and test mitigations and finally make them available for end users.
ISO/IEC 30111 refers to these situations as “cases where vendors can share vulnerability information in
order to resolve the issue that involves components from multiple vendors” and provide five examples
of such situations or reasons:
a) A vulnerability which was reported that affects a specific piece of software, but is caused by an
issue in an underlying operating system or hardware.
b) Vulnerabilities in various product implementations of a flawed standard functional specification or
in published algorithms.
c) Vulnerabilities that are naturally induced by so far widely accepted development methodology.
d) Vulnerabilities in commonly used libraries.
e) Vulnerabilities in software components that lack a current maintainer.
The MPCVD effort for a vulnerability in a technology owned and manufactured by the vendor leading
the process – the coordinating vendor, or mitigating vendor manages and leads the coordination effort.
The mitigating vendor (example a) above) can entail different processes from one in which a broader
collaboration is needed and there is no one distinct vendor of the technology (e.g. protocol-level
vulnerabilities) (examples b) to e) above). These examples include both vendor-coordinated MPCVD
and non-owner MPCVD. Recognizing MPCVD can raise unique considerations for vulnerability handling
given the technical and coordination complexities. Several documents have been published to share
norms and best practices in this evolving area. These best practices continue to be developed, iterated
and improved as new challenges arise. This document builds upon these sources and refers to them.
The audience for this document includes, among others, the participants of the MPCVD process such
as vendors (defined in ISO/IEC 29147:2018, 3.4), maintainers, producers, developers, manufacturers,
1)
suppliers , installers, or providers of a product or service, coordinators (including public coordinators),
reporters (e.g. security researchers), and users of information technology products and services.
1) By way of example, when the open source maintainer is leading the coordination effort in the non-owner
MPCVD case or as “dependent vendor”, a “vendor” can also include open-source software maintainers who develop
and distribute code.
vi
PROOF/ÉPREUVE © ISO/IEC 2022 – All rights reserved
---------------------- Page: 6 ----------------------
TECHNICAL REPORT ISO/IEC TR 5895:2022(E)
Cybersecurity — Multi-party coordinated vulnerability
disclosure and handling
1 Scope
This document clarifies and increases the application and implementation of ISO/IEC 30111 and
ISO/IEC 29147 in multi-party coordinated vulnerability disclosure (MPCVD) settings, including the
evolving commonly adopted practices in this area, by articulating:
— The MPCVD life cycle and application of coordinated vulnerability disclosure (CVD) stages
2)
(preparation, receipt, verification, remediation development, release, post-release) in MPCVD
settings.
— Stakeholders involved in MPCVD include users, vendors (coordinating, mitigating, and dependent
vendors), reporters, and non-vendor coordinators (entities defined in ISO/IEC 29147 and
ISO/IEC 30111).
— The exchange of information between stakeholders during the vulnerability handling and disclosure
process in a MPCVD settings.
Clarifying the application of ISO/IEC 30111 and ISO/IEC 29147 in MPCVD settings illustrates the
benefits of vulnerability disclosure processes.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 29147:2018, Information technology — Security techniques — Vulnerability disclosure
ISO/IEC 30111:2019, Information technology — Security techniques — Vulnerability handling processes
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 30111 and ISO/IEC 29147
and the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
4 Concepts
4.1 General
MPCVD processes are generally based on two concepts: (1) when security vulnerabilities arise, vendors
work quickly, collaboratively and effectively to mitigate the vulnerabilities, and (2) all involved parties
(which includes the various entities working on the mitigations and the reporters who discovered
2) Remediation is a defined term used in ISO/IEC 30111 and ISO/IEC 29147. This document uses the term
"remediation" and verb “remediate” in the context of this definition.
1
© ISO/IEC 2022 – All rights reserved PROOF/ÉPREUVE
---------------------- Page: 7 ----------------------
ISO/IEC TR 5895:2022(E)
or reported the vulnerabilities, if applicable) simultaneously take steps to decrease the risk that
information about the vulnerabilities becomes publicly available before mitigations are available, in
order to protect end users.
The implication for MPCVD is that processes can take a longer period than in other environments (such
as traditional CVD processes involving one entity in the handling processes) to fully develop, validate
and deploy mitigations while information concerning the vulnerability is simultaneously kept in
confidence (often termed, “embargo”) to protect end users from potential exploitation. The embargo
period is during the vulnerability handling process but prior to public disclosure, during which
information concerning the vulnerability is kept in confidence and only shared with entities necessary
for the remediation development process. Similar to other CVD processes, MPCVD processes rely on
the notion that information concerning the vulnerability is generally publicly disclosed only after
mitigations are available to end users.
The MPCVD effort for a vulnerability in a technology owned and manufactured by the vendor leading
the process can entail different processes from one in which a broader collaboration is needed and
there is no one distinct vendor of the technology (e.g. protocol-level vulnerabilities).
MPCVD processes, generally include a higher level of complexity and involvement by a wide range of
stakeholders in the various stages of CVD, as shown in Figure 1. For example, generally the MPCVD
process cases where there is a security vulnerability affecting hardware often need broader
collaboration within the ecosystem. Mitigation of vulnerabilities in hardware can require acting at
multiple and interdependent layers within a given computing system. This, in turn, can necessitate the
engagement of a larger number of third-party participants to develop, test and deploy mitigations in
a manner most likely to incentivize adoption by end users. Mitigation of a hardware vulnerability can
require updates to processor microcode and/or firmware, as well as interdependent updates to the
operating system software or other system software. These updates are then delivered to end-users
through multiple channels, including operating system (OS) and virtualization vendors, cloud service
providers (CSP) or original equipment system manufacturers (OEM). Hardware manufacturers often
do not have a means to unilaterally deliver mitigations without the direct participation of such entities
in the global supply chain.
Figure 1 — Example of vendor-coordinator led MPCVD process — coordinated vulnerability
[1]
disclosure in hardware systems
2
PROOF/ÉPREUVE © ISO/IEC 2022 – All rights reserved
---------------------- Page: 8 ----------------------
ISO/IEC TR 5895:2022(E)
4.2 Relationship with other International Standards
4.2.1 ISO/IEC 29147 - Vulnerability disclosure
ISO/IEC 29147 is used in conjunction with this document. The relationship between the two documents
is shown in Figure 2.
ISO/IEC 29147 provides guidelines for vendors on how to process and remediate potential vulnerabilities
reported by internal or external individuals or organizations. While this document deals with the
interface between multiple vendors, layers of customers, cross manufacturer collaborative mitigation
strategies and multiple reporters, ISO/IEC 29147 provides guidelines for vendors to include in their
normal business processes when receiving reports about potential vulnerabilities from external
individuals or organizations and when distributing vulnerability remediation information to affected
users. This document clarifies the application of these disclosure-related processes in MPCVD settings.
4.2.2 ISO/IEC 30111 - Vulnerability handling processes
ISO/IEC 30111 is used in conjunction with this document. The relationship between the two documents
is shown in Figure 2.
ISO/IEC 30111 gives guidelines on how to investigate, process and resolve potential vulnerability
reports. While this document deals with the interface between multiple vendors, layers of customers,
cross manufacturer collaborative mitigation strategies and multiple reporters, ISO/IEC 30111 deals
with internal vendor processes including the triage, investigation and remediation of vulnerabilities,
whether the source of the report is external to the vendor or from within the vendor’s own security,
development or testing teams. This document clarifies the application of these handling-related
processes in MPCVD settings.
3
© ISO/IEC 2022 – All rights reserved PROOF/ÉPREUVE
---------------------- Page: 9 ----------------------
ISO/IEC TR 5895:2022(E)
Figure 2 — The relationship between ISO/IEC 29147 and ISO/IEC 30111 with respect to MPCVD
4.2.3 Risk reduction effectiveness
Similar to the concept of the impact of successful exploitation referred to in ISO/IEC 30111, risk
reduction effectiveness is an element that can be considered in the context of MPCVD. The risk
reduction effectiveness measures the effectiveness of public disclosure and associated mitigation
and/or remediation against the total cost to society if the vulnerability is exploited. Risk reduction
effectiveness is a function that is affected by a variety of uncertainties, such as:
— Malicious attackers gaining knowledge about vulnerabilities from disclosed vulnerability and
mitigation information, increasing exploitation risk.
— Delayed delivery and/or publication of mitigations and vulnerabilities because there are multiple
contributors (e.g. vendors and open source maintainers) that need to be engaged or added to the
engagement.
— The need for collaboration between vendors across the supply chain, either vertically (vendors
participating and supplying various components to the final product) or horizontally (vulnerability-
affected vendors scattered in a supply chain) can increase the coordination period and introduce
unpredictable variables along the process that can impact expectations around timeline/embargo
periods.
4
PROOF/ÉPREUVE © ISO/IEC 2022 – All rights reserved
---------------------- Page: 10 ----------------------
ISO/IEC TR 5895:2022(E)
MPCVD increases the summation of the risk reduction effectiveness. In other words, a primary
purpose of MPCVD is to reduce the potential harm to users and the public by increasing the effective
collaborations in the relevant CVD stages prior the public release, which includes increasing the
completeness and effectiveness of the proposed remediation while incentivizing its adoption by end
users at disclosure.
5 MPCVD scenarios
5.1 General
Clause 5 provides common scenarios of MPCVD in the scope of this document.
5.2 MPCVD led by the vendor-coordinator (the owner of the technology developed) –
the “mitigating vendor”
In the MPCVD case of the vendor-coordinator (e.g. hardware), there is generally a clear owner/developer
of the underlying vulnerable technology who is typically best-situated to lead the coordination effort
as the most technically knowledgeable of the product and component supply chain. For example,
software companies, including operating systems and firmware vendors, and virtualization vendors
can be integral to the process of developing and testing a mitigation for a hardware-based vulnerability
(taking part in the handling processes), which are coordinated and led by the hardware manufacturer,
as the mitigating vendor. In different MPCVD settings where there is no clear owner of the technology/
manufacturer best-situated to lead the coordination efforts (for example, in certain protocol-level
vulnerabilities), a different entity can act as a coordinator, leading the coordination effort.
5.3 MPCVD process in non-owner cases
In the case where there is no clear owner of the technology who is typically best-situated to lead the
remediation development and other CVD processes, a different “coordinator” (see ISO/IEC 29147:2018,
5.5.5) can act as the entity or intermediary leading the MPCVD process.
6 MPCVD stakeholders
6.1 General
Clause 6 describes significant stakeholder roles beyond those found in ISO/IEC 29147.
6.2 Vendor
ISO/IEC 29147 provides the definition of a vendor. Vendors are described as individuals or organizations
who create or provide software products, including manufacturers, developers, or distributors. MPCVD
allows for vendors to take on the following roles. Additionally, vendors can also act as coordinators
depending on the issue.
6.2.1 Mitigating vendor
Mitigating vendors lead the MPCVD process, including facilitating the coordination with dependent
vendors (e.g. disseminating the proposed mitigation developed by the mitigating vendor to dependent
vendors and coordinating its testing in various environments). This can include coordinating the
dependent vendor contribution to the remediation development (e.g. if independent mitigations
developed by the dependent vendor need to be applied along with the proposed remediation to fully
protect against a specific security vulnerability and subsequently released together).
5
© ISO/IEC 2022 – All rights reserved PROOF/ÉPREUVE
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.