IEC/TR 80001-2-9:2017
(Main)Application of risk management for IT-networks incorporating medical devices — Part 2-9: Application guidance — Guidance for use of security assurance cases to demonstrate confidence in IEC/TR 80001-2-2 security capabilities
Application of risk management for IT-networks incorporating medical devices — Part 2-9: Application guidance — Guidance for use of security assurance cases to demonstrate confidence in IEC/TR 80001-2-2 security capabilities
IEC TR 80001-2-9:2017(E) establishes a security case framework and provides guidance to health care delivery organizations (HDO) and medical device manufacturers (MDM) for identifying, developing, interpreting, updating and maintaining security cases for networked medical devices. Use of this part of 80001 is intended to be one of the possible means to bridge the gap between MDMs and HDOs in providing adequate information to support the HDOs risk management of IT-networks. This document leverages the requirements set out in ISO/IEC 15026-2 for the development of assurance cases. It is not intended that this security case framework will replace a risk management strategy, rather, the intention is to complement risk management and in turn provide a greater level of assurance for a medical device by: - mapping specific risk management steps to each of the IEC TR 80001-2-2 security capabilities, identifying associated threats and vulnerabilities and presenting them in the format of a security case with the inclusion of a re-useable security pattern; - providing guidance for the selection of appropriate security controls to establish security capabilities and presenting them as part of the security case pattern (IEC TR 80001-2-8 provides examples of such security controls); - providing evidence to support the implementation of a security control, hence providing confidence in the establishment of each of the security capabilities. The purpose of developing the security case is to demonstrate confidence in the establishment of IEC TR 80001-2-2 security capabilities. The quality of artifacts gathered and documented during the development of the security case is agreed and documented as part of a responsibility agreement between the relevant stakeholders. This document provides guidance for one such methodology, through the use of a specific security pattern, to develop and interpret security cases in a systematic manner.
Application du management du risque aux réseaux des technologies de l'information contenant les dispositifs médicaux — Partie 2-9: Guide d'application — Lignes directrices pour l'utilisation de cas d'assurance de sécurité pour démontrer la confiance dans la IEC/TR 80001-2-2 capacités de sécurité
General Information
Standards Content (Sample)
IEC TR 80001-2-9
Edition 1.0 2017-01
TECHNICAL
REPORT
Application of risk management for it-networks incorporating medical devices –
Part 2-9: Application guidance – Guidance for use of security assurance cases
to demonstrate confidence in IEC TR 80001-2-2 security capabilities
IEC TR 80001-2-9:2017-01(en)
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form
or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from
either IEC or IEC's member National Committee in the country of the requester. If you have any questions about
ISO/IEC copyright or have an enquiry about obtaining additional rights to this publication, please contact the address
below or your local IEC member National Committee for further information.
IEC Central Office Tel.: +41 22 919 02 11
3, rue de Varembé Fax: +41 22 919 03 00
CH-1211 Geneva 20 info@iec.ch
Switzerland www.iec.ch
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.
About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigenda or an amendment might have been published.
IEC Catalogue - webstore.iec.ch/catalogue Electropedia - www.electropedia.org
The stand-alone application for consulting the entire The world's leading online dictionary of electronic and
bibliographical information on IEC International Standards, electrical terms containing 20 000 terms and definitions in
Technical Specifications, Technical Reports and other English and French, with equivalent terms in 16 additional
documents. Available for PC, Mac OS, Android Tablets and languages. Also known as the International Electrotechnical
iPad. Vocabulary (IEV) online.
IEC publications search - www.iec.ch/searchpub IEC Glossary - std.iec.ch/glossary
The advanced search enables to find IEC publications by a 65 000 electrotechnical terminology entries in English and
variety of criteria (reference number, text, technical French extracted from the Terms and Definitions clause of
committee,…). It also gives information on projects, replaced IEC publications issued since 2002. Some entries have been
and withdrawn publications. collected from earlier publications of IEC TC 37, 77, 86 and
CISPR.
IEC Just Published - webstore.iec.ch/justpublished
Stay up to date on all new IEC publications. Just Published IEC Customer Service Centre - webstore.iec.ch/csc
details all new publications released. Available online and If you wish to give us your feedback on this publication or
also once a month by email. need further assistance, please contact the Customer Service
Centre: csc@iec.ch.
IEC TR 80001-2-9
Edition 1.0 2017-01
TECHNICAL
REPORT
Application of risk management for it-networks incorporating medical devices –
Part 2-9: Application guidance – Guidance for use of security assurance cases
to demonstrate confidence in IEC TR 80001-2-2 security capabilities
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
ICS 11.040.01, 35.240.80 ISBN 978-2-8322-3907-0
– 2 – IEC TR 80001-2-9:2017 © IEC 2017
CONTENTS
FOREWORD . 4
INTRODUCTION . 6
1 Scope . 8
2 Normative references . 8
3 Terms, definitions and abbreviated terms . 9
3.1 Terms and definitions . 9
3.2 Abbreviated terms . 12
4 ASSURANCE case . 12
5 Use of this document . 13
5.1 Intended use . 13
5.2 Intended audience . 13
5.2.1 Intended purpose . 13
5.2.2 MEDICAL DEVICE MANUFACTURERS (MDM) . 13
5.2.3 Healthcare delivery organizations (HDO) . 14
5.2.4 Other stakeholders . 15
6 General guidelines. 15
6.1 General . 15
6.2 Overview of the SECURITY CASE framework . 15
6.3 Notation . 16
6.3.1 Components of a SECURITY CASE . 16
6.3.2 Goal . 16
6.3.3 Strategy . 17
6.3.4 Justification . 17
6.3.5 Context . 17
6.3.6 Solution (EVIDENCE) . 18
6.3.7 Stakeholder . 18
6.3.8 Notation extensions . 18
7 Developing the SECURITY CASE . 19
8 SECURITY CASE change management . 28
Annex A (informative) Exemplar SECURITY PATTERNS . 29
A.1 General . 29
A.2 Exemplar SECURITY PATTERN for person authentication (PAUT) — SECURITY
CAPABILITY PAUT established by MDM for a medical system . 29
A.2.1 Goal G6: Replay attack mitigated. 29
A.2.2 Goal G8: ‘Man-in-the-middle’ attack mitigated. 29
A.2.3 Goal G10: Brute force attack mitigated . 29
A.2.4 Goal G13, G14: Denial of service attacks due to account lockout
controls mitigated . 30
A.3 Exemplar SECURITY PATTERN for automatic logoff (ALOF) established for a
thin client terminal system . 31
A.3.1 Goal: Patient safety RISK with short session timeouts in OR mitigated . 31
A.3.2 Goal: Patient safety RISK with restoring sessions in the OR and ICU
mitigated . 31
A.4 Exemplar SECURITY PATTERN for audit controls (AUDT) for a system or a
device in a HDO facility such as a pharmacy system or an EMR, where
multiple people require access to the same data set— Goal G6: Keep a
correct audit trail of attending staff in the OR while sessions are kept open . 33
IEC TR 80001-2-9:2017 © IEC 2017 – 3 –
Bibliography . 35
Figure 1 – Example GOAL (top-level) . 17
Figure 2 – Example strategy . 17
Figure 3 – Example justification . 17
Figure 4 – Example context . 18
Figure 5 – Example solution (EVIDENCE) . 18
Figure 6 – Example stakeholder . 18
Figure 7 – Leading components – Steps 1 through 9 . 19
Figure 8 – SECURITY CAPABILITY pattern . 22
Figure 9 – SECURITY CASE structure . 27
Figure A.1 – Exemplar SECURITY PATTERN for PAUT . 30
Figure A.2 – Exemplar SECURITY PATTERN for ALOF . 32
Figure A.3 – Exemplar SECURITY PATTERN for AUDT . 34
Table 1 – Notation extensions . 18
Table 2 – SECURiTY CASE steps 1 through 9 . 20
Table 3 – SECURITY CASE steps 10 through 26 . 23
– 4 – IEC TR 80001-2-9:2017 © IEC 2017
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
APPLICATION OF RISK MANAGEMENT FOR IT-NETWORKS
INCORPORATING MEDICAL DEVICES –
Part 2-9: Application guidance – Guidance for use of security assurance
cases to demonstrate confidence in IEC TR 80001-2-2 security capabilities
FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
The main task of IEC technical committees is to prepare International Standards. However, a
technical committee may propose the publication of a technical report when it has collected
data of a different kind from that which is normally published as an International Standard, for
example "state of the art".
IEC TR 80001-2-9, which is a technical report, has been prepared by subcommittee 62A:
Common aspects of electrical equipment used in medical practice, of IEC technical committee
62: Electrical equipment in medical practice, and ISO technical committee 215: Health
informatics.
IEC TR 80001-2-9:2017 © IEC 2017 – 5 –
It is published as a double logo technical report.
The text of this technical report is based on the following documents:
Enquiry draft Report on voting
62A/1097/DTR 62A/1128/RVDTR
Full information on the voting for the approval of this technical report can be found in the
report on voting indicated in the above table.
This document has been drafted in accordance with the ISO/IEC Directives, Part 2.
Terms defined in Clause 3 of this standard are printed in SMALL CAPITALS.
A list of all parts of the 80001 series, published under the general title Application of risk
management for IT-networks incorporating medical devices, can be found on the IEC website.
The committee has decided that the contents of this document will remain unchanged until the
stability date indicated on the IEC website under "http://webstore.iec.ch" in the data related to
the specific document. At this date, the document will be
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
A bilingual version of this publication may be issued at a later date.
– 6 – IEC TR 80001-2-9:2017 © IEC 2017
INTRODUCTION
This document outlines a process for supporting CONFIDENCE in the use of the 80001 series by
developing security ASSURANCE cases (henceforth SECURITY CASEs) to complement a security
RISK MANAGEMENT process. IEC 80001-1 provides the roles, responsibilities and activities
necessary for RISK MANAGEMENT.
IEC TR 80001-2-2 provides additional guidance in relation to how SECURITY CAPABILITIES might
be referenced (disclosed and discussed) in both the RISK MANAGEMENT process and
stakeholder communications and agreements phases. IEC TR 80001-2-2 contains an
informative set of common, descriptive SECURITY CAPABILITIES intended to be the starting point
for a security-centric discussion between the vendor and purchaser or among a larger group
of stakeholders involved in a MEDICAL DEVICE IT-NETWORK project. Scalability is possible
across a range of different sizes of RESPONSIBLE ORGANIZATIONS (henceforth called healthcare
delivery organizations – HDOs) as each evaluates RISK using the SECURITY CAPABILITIES and
decides what to include or not to include according to their RISK tolerance, intended use and
available resources. This information may be used by HDOs as input to their IEC 80001-1
PROCESS or to form the basis of RESPONSIBILITY AGREEMENTS among stakeholders.
IEC TR 80001-2-1 provides step-by-step guidance in the RISK MANAGEMENT PROCESS.
IEC TR 80001-2-2 SECURITY CAPABILITIES encourages the disclosure of more detailed
SECURITY CONTROLS.
IEC TR 80001-2-8 identifies SECURITY CONTROLS from key security standards which aim to
provide guidance to HDOS, MEDICAL DEVICE manufacturers (MDMs) when adapting the
framework outlined in IEC TR 80001-2-2 and establishing each of the SECURITY CAPABILITIES
presented here. A SECURITY CAPABILITY, as defined in IEC TR 80001-2-2, represents a broad
1)
category of technical, administrative and/or organizational SECURITY CONTROLS required to
manage RISKS to confidentiality, integrity, availability and accountability of data and systems.
IEC TR 80001-2-8 presents these categories of SECURITY CONTROLS prescribed for a system to
establish SECURITY CAPABILITIES to support the maintenance of confidentiality and the
protection from intentional or unintentional intrusion that may lead to compromises in integrity
or system/data availability. IEC TR 80001-2-8 provides HDOs and MDMs with a catalogue of
technical, management, operational and administrative controls. IEC TR 80001-2-8 presents
the 19 SECURITY CAPABILITIES, their respective “requirement goal” and “user need” (identical to
that in IEC TR 80001-2-2) with a corresponding list of SECURITY CONTROLS from a number of
security standards.
This document integrates the information and guidance contained in IEC TR 80001-2-2 and
IEC TR 80001-2-8 together to provide guidance to HDOs and MDMs for identifying,
developing, interpreting, updating and maintaining security ASSURANCE cases. Although other
means of establishing CONFIDENCE in a particular property (e.g. security) exist, this document
provides one such way in assuring CONFIDENCE in the establishment of IEC TR 80001-2-2
SECURITY CAPABILITIES through the use of SECURITY CASES. The purpose of the SECURITY CASE
is to provide CONFIDENCE in the establishment of the IEC TR 80001-2-2 SECURITY CAPABILITIES
for networked MEDICAL DEVICES. This is achieved by applying a SECURITY PATTERN to each of
the 19 SECURITY CAPABILITIES. The objectives of the SECURITY PATTERN are as follows:
– to reduce the time required to develop the SECURITY CASE by providing a repeatable and
systematic step-by-step, RISK based blue-print;
– provide a means to re-use components of the SECURITY PATTERN either within a SECURITY
CASE or from one SECURITY CASE to another;
– to reduce the complexity often associated with the development of SECURITY CASES;
– provide a visible traceability matrix linking the SECURITY CONTROLS to the security threats
and vulnerabilities identified during RISK MANAGEMENT;
___________
1)
For the purpose of consistency throughout this document, the terms SECURITY CONTROLS refer to the technical,
management, administrative and organizational controls/safeguards prescribed to establish SECURITY
CAPABILITIES.
IEC TR 80001-2-9:2017 © IEC 2017 – 7 –
– reduce the likelihood of missing a step in the ARGUMENT;
– improve the readability of the SECURITY CASE;
– provide CONFIDENCE regarding the integrity of the EVIDENCE collected based on the
information presented in the ARGUMENT.
The process of developing the SECURITY CASE is not intended to replace a RISK MANAGEMENT
process nor does it generate new processes, rather, the SECURITY CASE should complement
the RISK MANAGEMENT process with a reference to, or, inclusion of the following supporting
documentation by MDMs and HDOs:
– information regarding the intended use of the MEDICAL DEVICE, operational environment,
network structure, interfaces, boundaries etc.;
– information regarding system description, security objectives and assets to be protected;
– justification for selection of SECURITY CAPABILITIES;
– justification for non-selection of SECURITY CAPABILITIES;
– assets being protected by specific SECURITY CAPABILITY;
– RISK acceptability criteria policy;
– all identified unacceptable threats/vulnerabilities;
– threat / vulnerability / RISK log;
– impact / threat scenario / consequence information;
– reference to source for selection of SECURITY CONTROLS (e.g. IEC TR 80001-2-8 tables).
The above information becomes part of, and remains with the SECURITY CASE from concept
phase through to development, operation and retirement. Supporting information such as this
can aid in better design choices, better maintenance during operation and more efficient and
informative feedback practices.
This document is not intended to provide exhaustive guidance for the application of a RISK
MANAGEMENT process nor does it mandate the use of any particular RISK MANAGEMENT process
however IEC 80001-1 provides guidance on how to carry out RISK MANAGEMENT for medical IT-
networks. Similarly, ISO 14971 provides guidance for the process of conducting RISK
MANAGEMENT for MEDICAL DEVICES. For RISK MANAGEMENT processes such as RISK/benefit
analysis, which is not covered in this document, HDOs refer to IEC 80001-1:2010, 4.4.5 and
MDMs refer to ISO 14971,6.5.
– 8 – IEC TR 80001-2-9:2017 © IEC 2017
APPLICATION OF RISK MANAGEMENT FOR IT-NETWORKS
INCORPORATING MEDICAL DEVICES –
Part 2-9: Application guidance – Guidance for use of security assurance
cases to demonstrate confidence in IEC TR 80001-2-2 security capabilities
1 Scope
This part of 80001 establishes a SECURITY CASE framework and provides guidance to health
care delivery organizations (HDO) and MEDICAL DEVICE MANUFACTURERS (MDM) for identifying,
developing, interpreting, updating and maintaining SECURITY CASES for networked MEDICAL
DEVICES. Use of this part of 80001 is intended to be one of the possible means to bridge the
gap between MDMs and HDOs in providing adequate information to support the HDOS RISK
MANAGEMENT of IT-NETWORKS. This document leverages the requirements set out in
2)
ISO/IEC 15026-2 for the development of ASSURANCE cases . It is not intended that this
SECURITY CASE framework will replace a RISK MANAGEMENT strategy, rather, the intention is to
complement RISK MANAGEMENT and in turn provide a greater level of ASSURANCE for a MEDICAL
DEVICE by:
– mapping specific RISK MANAGEMENT steps to each of the IEC TR 80001-2-2 SECURITY
CAPABILITIES, identifying associated threats and vulnerabilities and presenting them in the
format of a SECURITY CASE with the inclusion of a re-useable SECURITY PATTERN;
SECURITY CONTROLS to establish
– providing guidance for the selection of appropriate
SECURITY CAPABILITIES and presenting them as part of the SECURITY CASE pattern
(IEC TR 80001-2-8 provides examples of such SECURITY CONTROLS);
– providing EVIDENCE to support the implementation of a SECURITY CONTROL, hence providing
CONFIDENCE in the establishment of each of the SECURITY CAPABILITIES.
The purpose of developing the SECURITY CASE is to demonstrate CONFIDENCE in the
SECURITY CAPABILITIES. The quality of artifacts gathered
establishment of IEC TR 80001-2-2
and documented during the development of the SECURITY CASE is agreed and documented as
part of a RESPONSIBILITY AGREEMENT between the relevant stakeholders. This document
provides guidance for one such methodology, through the use of a specific SECURITY PATTERN,
to develop and interpret SECURITY CASES in a systematic manner.
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.
IEC TR 80001-2-2:2012, Application of risk management for IT-networks incorporating
medical devices – Part 2-2: Guidance for the disclosure and communication of medical device
3)
security needs, risks and controls
___________
2)
These requirements are adapted for networked MEDICAL DEVICES where the sole critical property is “security”
and where the CLAIM relates to the establishment of the IEC TR 80001-2-2 SECURITY CAPABILITIES with the
inclusion of a specific security ARGUMENT PATTERN.
3)
IEC TR 80001-2-2 contains many additional standards, policies and reference materials which are also
indispensible for the application of this document.
IEC TR 80001-2-9:2017 © IEC 2017 – 9 –
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following
addresses:
• IEC Electropedia: available at http://www.electropedia.org/
• ISO Online browsing platform: available at http://www.iso.org/obp.
3.1.1
ASSURANCE
grounds for justified CONFIDENCE that a CLAIM has been or will be achieved
[SOURCE: ISO/IEC 15026-1:2013, 3.1.1]
3.1.2
ARGUMENT
connected series of CLAIMS intended to establish an overall CLAIM
[SOURCE: GSN Community Standard Version 1:2011, 0.3]
3.1.3
CLAIM
proposition being asserted by the author that is a true or false statement
[SOURCE: GSN Community Standard Version 1:2011, Glossary]
3.1.4
CONFIDENCE
quality or state of being certain that the ASSURANCE case is appropriately and effectively
structured, and correct
[SOURCE: Definition by: Grigorova, S., & Maibaum, T. S. E. (2013, November). Taking a
page from the law books: Considering evidence weight in evaluating assurance case
confidence. In Software Reliability Engineering Workshops (ISSREW), 2013 IEEE
International Symposium on (pp. 387-390). IEEE. Definition: page 388]
3.1.5
EVIDENCE
information or objective artefacts being offered in support of one or more CLAIMS
[SOURCE: GSN Community Standard Version 1:2011, Glossary]
3.1.6
MEDICAL DEVICE
any instrument, apparatus, implement, machine, appliance, implant, in vitro reagent or
calibrator, software, material or other similar or related article:
a) intended by the manufacturer to be used, alone or in combination, for human beings for
one or more of the specific purpose(s) of:
– diagnosis, prevention, monitoring, treatment or alleviation of disease,
– diagnosis, monitoring, treatment, alleviation of or compensation for an injury,
– investigation, replacement, modification, or support of the anatomy or of a
physiological process,
– 10 – IEC TR 80001-2-9:2017 © IEC 2017
– supporting or sustaining life,
– control of conception,
– disinfection of MEDICAL DEVICES,
– providing information for medical or diagnostic purposes by means of in vitro
examination of specimens derived from the human body; and
b) which does not achieve its primary intended action in or on the human body by
pharmacological, immunological or metabolic means, but which may be assisted in its
intended function by such means.
Note 1 to entry The definition of a device for in vitro examination includes, for example, reagents, calibrators,
sample collection and storage devices, control materials, and related instruments or apparatus. The information
provided by such an in vitro diagnostic device may be for diagnostic, monitoring or compatibility purposes. In some
jurisdictions, some in vitro diagnostic devices, including reagents and the like, may be covered by separate
regulations.
Note 2 to entry Products which can be considered to be MEDICAL DEVICES in some jurisdictions but for which there
is not yet a harmonized approach, are:
‒ aids for disabled/handicapped people;
‒ devices for the treatment/diagnosis of diseases and injuries in animals;
‒ accessories for MEDICAL DEVICES (see Note to entry 3);
‒ disinfection substances;
‒ devices incorporating animal and human tissues which can meet the requirements of the above definition but
are subject to different controls.
Note 3 to entry Accessories intended specifically by manufacturers to be used together with a ‘parent’ MEDICAL
DEVICE to enable that MEDICAL DEVICE to achieve its intended purpose should be subject to the same GHTF
procedures as apply to the MEDICAL DEVICE itself. For example, an accessory will be classified as though it is a
MEDICAL DEVICE in its own right. This may result in the accessory having a different classification than the ‘parent’
device.
Note 4 to entry Components to MEDICAL DEVICES are generally controlled through the manufacturer’s quality
management system and the conformity assessment procedures for the device. In some jurisdictions, components
are included in the definition of a ‘MEDICAL DEVICE’.
[SOURCE: IEC 80001-1:2010, 2.14]
3.1.7
RESPONSIBILITY AGREEMENT
one or more documents that together fully define the responsibilities of all relevant
stakeholders
Note 1 to entry This agreement can be a legal document, e.g. a contract.
[SOURCE: IEC 80001-1:2010, 2.21]
3.1.8
RESPONSIBLE ORGANIZATION
entity accountable for the use and maintenance of a MEDICAL IT-NETWORK
Note 1 to entry The accountable entity can be, for example, a hospital, a private clinician or a telehealth
organization.
Note 2 to entry Adapted from IEC 60601-1:2005, 3.101.
[SOURCE: IEC 80001-1:2010, 2.22]
3.1.9
RISK
combination of the probability of occurrence of HARM and the severity of that HARM
[SOURCE: IEC 80001-1:2010, 2.23]
IEC TR 80001-2-9:2017 © IEC 2017 – 11 –
3.1.10
RISK MANAGEMENT
systematic application of management policies, procedures and practices to the tasks of
analyzing, evaluating, controlling, and monitoring RISK
[SOURCE: IEC 80001-1:2010, 2.28]
3.1.11
SECURITY CAPABILITY
broad category of technical, administrative or organizational controls to manage RISKS to
confidentiality, integrity, availability and accountability of data and systems
[SOURCE: IEC TR 80001-2-8:2016, 3.21]
3.1.12
SECURITY CASE
reasoned, auditable artefact created that supports the contention that its top-level CLAIM (or
set of CLAIMS) is satisfied, including structured and explicit argumentation and its underlying
EVIDENCE and explicit assumptions that support the CLAIM(s)
Note 1 to entry A SECURITY CASE contains the following and their relationships:
one or more CLAIMS about the critical property security;
ARGUMENTs that logically link the EVIDENCE and any assumptions to the CLAIM(s);
a body of EVIDENCE and possibly assumptions supporting these ARGUMENTs for the CLAIM(s);
justification of the choice of the top-level CLAIM and the method of reasoning.
[SOURCE: ISO/IEC 15026-1:2013, 3.1.3, modified — Adapted and amended definition of
“ASSURANCE CASE” specifically addressing security as the critical property]
3.1.13
SECURITY CONTROL
management, operational, and technical controls (i.e. safeguards or countermeasures)
prescribed for an information system to protect the confidentiality, integrity, and availability of
the system and its information
[SOURCE: FIPS Publication 199, Appendix A]
3.1.14
SECURITY PATTERN
a means of documenting and reusing successful security ARGUMENT structures
[SOURCE: Adapted and amended definition in Kelly, T.P., & McDermid, J.A. (1997). Safety
Case Construction and Reuse using Patterns 16th International Conference on Computer
Safety, Reliability and Security (SAFECOMP' 97) (pp. 55-69): Springer London]
– 12 – IEC TR 80001-2-9:2017 © IEC 2017
3.2 Abbreviated terms
ALOF Automatic logoff
AUDT Audit controls
AUTH Authorization
CNFS Configuration of security features
CSUP Cyber security product upgrades
DIDT Health DATA de-identification
DTBK Data backup and disaster recovery
EMRG Emergency access
IGAU Health data integrity and authenticity
MLDP Malware protection/recovery
NAUT Node authentication
PAUT Person authentication
PLOK Physical locks on device
RDMP Third party components and roadmaps
SAHD System and application hardening
SGUD Security guides
STCF Health data storage confidentiality
TXCF Transmission confidentiality
TXIG Transmission integrity
MDM MEDICAL DEVICE manufacturer
HDO Healthcare delivery organization
SDLC System/software development lifecycle
4 ASSURANCE case
An ASSURANCE case is a structured, EVIDENCE based ARGUMENT used to demonstrate
CONFIDENCE that a system holds a particular critical property. ASSURANCE cases have been
commonly applied to the safety domain, specifically addressing safety concerns for systems,
however the use of ASSURANCE cases has expanded and nowadays address other critical
properties such as dependability, reliability and security across a range of safety critical
ASSURANCE case is called a
domains such as automotive, railway, defence, aviation etc. An
safety case when used to argue the safety of a system. Similarly they are referred to as
SECURITY CASES and dependability cases when arguing security and dependability
respectively.
A SECURITY CASE is required due to the associated security RISK related properties of certain
MEDICAL DEVICES where CONFIDENCE is required to demonstrate security ASSURANCE of such
MEDICAL DEVICES.
An ARGUMENT is a connected series of CLAIMS intended to establish an overall CLAIM. This
hierarchy of CLAIMS presents the ARGUMENT of a SECURITY CASE. The ARGUMENT in a SECURITY
CASE shows how a high-level CLAIM is supported by a number of child CLAIMS, which, in turn
are supported by detailed presentation of EVIDENCE. It is the combination of CLAIMS and
EVIDENCE that provide CONFIDENCE in the overall high level CLAIM for the SECURITY CASE. In
ASSURANCE of a MEDICAL DEVICE, it is difficult to see the adequacy
demonstrating the security
of the EVIDENCE (e.g. test results) if no ARGUMENT supporting the CLAIM of the MEDICAL DEVICE
exists. Presenting the ARGUMENT and EVIDENCE in a structured approach reduces the
likelihood of uncertainty and allows for a better analysis of the achievement of the set of
objectives (the CLAIMS).
IEC TR 80001-2-9:2017 © IEC 2017 – 13 –
The SECURITY CASE also provides a mechanism for capturing supporting information (by
means of additional notations which can form part of an ARGUMENT) in the form of
assumptions, justifications and context. This information supports rationale and decision
making while developing, interpreting and updating the SECURITY CASE.
5 Use of this document
5.1 Intended use
The following subclause outlines the use of this document for MDMS and HDOs.
5.2 Intended audience
5.2.1 Intended purpose
This document is intended to supply MDMs and HDOs with guidance for the development,
interpretation, updating and maintenance of SECURITY CASES. It specifically guides MDMs,
HDOs and other stakeholders for supporting a security dialogue through the use of
ASSURANCE cases as a shared approach between all stakeholders. This document details the
application of SECURITY CASES by providing examples with the use of Goal Structure Notation
(GSN) while acknowledging that other annotations and other means to communicate are also
applicable.
5.2.2 MEDICAL DEVICE MANUFACTURERS (MDM)
This document provides guidance to MDMs for developing a SECURITY CASE to demonstrate
CONFIDENCE in the achievement of IEC TR 80001-2-2 SECURITY CAPABILITIES for the purpose of
providing HDOs with the appropriate level of information to adequately support the HDO’s
RISK MANAGEMENT of MEDICAL DEVICES on a MEDICAL DEVICE IT-network.
A SECURITY CASE should be treated as a ‘living document’ that is continuously developed
maintained and updated during design, production and operation of a MEDICAL DEVICE
maintaining the traceability between the SECURITY CONTROLS, security RISKs and their
associated SECURITY CAPABILITIES CLAIMS. Treating a SECURITY CASE as a ‘living’ document
MEDICAL DEVICE will aid in gathering operational information and adoption
during operation of a
to a changing threat landscape.
A MDM should commence development of the SECURITY CASE at the outset of the
system/software development lifecycle (SDLC).
Using this document, a SECURITY CASE will provide a traceability matrix between identified
security RISKs and relating SECURITY CONTROLS and SECURITY CAPABILITIES.
SECURITY CASE can form part of a broader ASSURANCE case for a MEDICAL DEVICE addressing
A
other system critical properties such as safety, reliability, usability etc.
A SECURITY CASE can be developed by MDMs to demonstrate the security ASSURANCE of a
MEDICAL DEVICE to HDOs.
The SECURITY CASE may act as a support document to the Manufacture Disclosure Statement
(MDS ) which also utilizes IEC TR 80001-2-2 SECURITY CAPABILITIES.
MEDICAL DEVICE, the SECURITY CASE is useful for
In the event of an incident concerning a
analysis and also to provide information/feedback to HDOs.
– 14 – IEC TR 80001-2-9:2017 © IEC 2017
5.2.3 Healthcare delivery organizations (HDO)
ASSURANCE cases can be applied to any level of an IT-network which can support the entire
HDO IT-network addressing any network component e.g. the radiology network, network
communication components, MEDICAL DEVICES, accessories and even components of devices.
HDOs can use the SECURITY CASE, as outlined in this document, to form part of a broader
ASSURANCE case addressing additional critical properties such as safety, reliability,
maintainability etc. Similarly, a SECURITY CASE for one MEDICAL DEVICE on an IT-network can
MEDICAL DEVICES IT-network SECURITY CASE.
form part of a larger
However, a CLAIM “The object xyz is secure” will not make sense in every case, e.g. on a
device level, the achievement of required security ASSURANCE may depend on whether the
device is protected by malware protection in the network infrastructure or users are for
instance restricted access by organizational policies. In other words, acceptable security for a
MEDICAL DEVICE IT-network requires the combined effort of the HDO, MDM and other
stakeholders.
Security is not limited to technical measures and may also require administrative measures
e.g. access controls at the users site or field monitoring and patch processes at MDMs site.
SECURITY CASES with their layered approach are a means to cope with such complex
situations. In general, it is a best practice to start on a level that a HDO has chosen as its
object to apply RISK MANAGEMENT to. This might be part of a medical IT-network and so the
CLAIM might be “This part of the medical IT-network is secure”. This CLAIM will then be
supported by a set of ARGUMENTS which will eventually lead to a CLAIM for a single MEDICAL
DEVICE that is part of the medical IT-network. However, this CLAIM for a specific MEDICAL
DEVICE is not necessarily “the MEDICAL DEVICE xyz is secure” but instead the CLAIM may be for
a specific (set of) property (properties) of the MEDICAL DEVICE. Typical properties of a MEDICAL
DEVICE that relate to security are given in IEC TR 80001-2-2.
HDO’s should use this document for one or more of the following:
a) evaluate a SECURITY CASE to determine the extent of achievement of the IEC TR 80001-2-2
SECURITY CAPABILITIES for a particular MEDICAL DEVICE; or
b) develop a complete SECURITY CASE for a MEDICAL DEVICE on an IT-network, as per Clause
5; or
c) further develop a received MDM SECURITY CASE to include additional specific
threats/vulnerabilities related to the environment and also EVIDENCE of any operational or
administrative controls implemented in the operational environment.
The information contained in a SECURITY CASE will support HDO decision makers in
determining the following:
a) establishing suitability of a MEDICAL DEVICE for a specific environment;
b) identifying use-environment security RISKs which may require RISK treatment (based on
information provided by a MDM SECURITY CASE);
c) knowledge and understanding of design choices taken by MDM;
d) knowledge of understanding of actions required by HDO to maintain a MEDICAL DEVICE as
per the documented intended use;
e) improved knowledge and understanding of network RISK MANAGEMENT requirements based
on MDMs information.
In the event of an incident concerning a MEDICAL DEVICE, the SECURITY CASE is useful for
analysis of such incidents and also for the purpose of information sharing / feedback to
MDMs.
IEC TR 80001-2-9:2017 © IEC 2017 – 15 –
5.2.4 Other stakeholders
Stakeholders (involved in conformity assessment, certification, regulation, acquisition or audit)
can evaluate the SECURITY CASE to determine the extent of achievement of the top-level CLAIM
(establishment of the SECURITY CAPABILITIES) by the MEDICAL DEVICE and whether this
achievement is demonstrated within the allowable uncertainty or RISK and any related
consequences. The results regarding the top-level CLAIM and its support along with related
uncertainties and consequences constitute a basis for rationally managing RISK, achieving
CONFIDENCE, and aiding in decision making.
grounds for appropriate
6 General guidelines
6.1 General
The following guidelines apply when developing and interpreting a SECURITY CASE:
4)
a) The components of a SECURITY CASE should be unambiguous, identifiable, and
accessible.
b) Each component should be uniquely identified and should be able to have its origin
identified, its history ascertained, and its integrity assured.
c) Detailed supporting artifacts, which have been developed elsewhere, should be identified
5)
in the “context ” component and should be accessible.
d) For each component, the component's contents, the information related to it, and the other
components with which it has relationships should be identifiable and accessible.
e) For each component, its description and required components, e.g. EVIDENCE for CLAIMS
and related information such as test case results, should be identifiable and accessible.
6)
f) Where a particular SECURITY CAPABILITY is deemed necessary , a CLAIM relating to the
establishment of that SECURITY CAPABILITY should be developed.
g) For each SECURITY CAPABILITY, a SECURITY PATTERN (as outlined in Clause 7) which
comprises of a number of specific components should be utilized.
6.2 Overview of the SECURITY CASE framework
The following includes recommendations for the use of this document:
a) All 19 SECURITY CAPABILITIES should be considered for inclusion in the SECURITY CASE
giving consideration to the ‘user needs’, intended use, operational environment,
interfaces, identified RISKS functionality etc.
b) Where a SECURITY CAPABILITY is not required (due to any of the considerations in a)),
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...