oSIST prEN 13608-1:2006
Health informatics - Security for healthcare communication - Part 1: Concepts and terminology
Health informatics - Security for healthcare communication - Part 1: Concepts and terminology
Medizinische Informatik - Sicherheit für die Kommunikation im Gesundheitswesen - Teil 1: Konzepte und Terminologie
Informatique de Santé - Sécurité des communications dans le domaine de la santé - Partie 1: Concepts et Terminologie
Zdravstvena informatika – Varnost komuniciranja v zdravstvenem varstvu – 1. del: Koncepti in izrazje
General Information
Relations
Standards Content (Sample)
SLOVENSKI STANDARD
oSIST prEN 13608-1:2006
01-februar-2006
Zdravstvena informatika – Varnost komuniciranja v zdravstvenem varstvu – 1. del:
Koncepti in izrazje
Health informatics - Security for healthcare communication - Part 1: Concepts and
terminology
Medizinische Informatik - Sicherheit für die Kommunikation im Gesundheitswesen - Teil
1: Konzepte und Terminologie
Informatique de Santé - Sécurité des communications dans le domaine de la santé -
Partie 1: Concepts et Terminologie
Ta slovenski standard je istoveten z: prEN 13608-1
ICS:
01.040.35 Informacijska tehnologija. Information technology.
Pisarniški stroji (Slovarji) Office machines
(Vocabularies)
35.240.80 Uporabniške rešitve IT v IT applications in health care
zdravstveni tehniki technology
oSIST prEN 13608-1:2006 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
---------------------- Page: 1 ----------------------
oSIST prEN 13608-1:2006
---------------------- Page: 2 ----------------------
oSIST prEN 13608-1:2006
EUROPEAN STANDARD
DRAFT
prEN 13608-1
NORME EUROPÉENNE
EUROPÄISCHE NORM
November 2005
ICS Will supersede ENV 13608-1:2000
English Version
Health informatics - Security for healthcare communication - Part
1: Concepts and terminology
Informatique de Santé - Sécurité des communications dans Gesundheitsinformatik - Sicherheit für Kommunikation im
le domaine de la santé - Partie 1: Concepts et Terminologie Gesundheitswesen - Teil 1: Konzepte und Terminologie
This draft European Standard is submitted to CEN members for enquiry. It has been drawn up by the Technical Committee CEN/TC 251.
If this draft becomes a European Standard, CEN members are bound to comply with the CEN/CENELEC Internal Regulations which
stipulate the conditions for giving this European Standard the status of a national standard without any alteration.
This draft European Standard was established by CEN in three official versions (English, French, German). A version in any other language
made by translation under the responsibility of a CEN member into its own language and notified to the Management Centre has the same
status as the official versions.
CEN members are the national standards bodies of Austria, Belgium, Cyprus, Czech Republic, Denmark, Estonia, Finland, France,
Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Slovakia,
Slovenia, Spain, Sweden, Switzerland and United Kingdom.
Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to
provide supporting documentation.
Warning : This document is not a European Standard. It is distributed for review and comments. It is subject to change without notice and
shall not be referred to as a European Standard.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
Management Centre: rue de Stassart, 36 B-1050 Brussels
© 2005 CEN All rights of exploitation in any form and by any means reserved Ref. No. prEN 13608-1:2005: E
worldwide for CEN national Members.
---------------------- Page: 3 ----------------------
oSIST prEN 13608-1:2006
prEN 13608-1:2005 (E)
Contents Page
Foreword.4
Introduction .5
1 Scope.9
2 Normative references.9
3 Terms and definitions .10
4 Symbols and abbreviations .18
4.1 Abbreviations.18
4.2 Symbols.19
5 Healthcare Communication Protection Profile Concepts .19
5.1 The Responsibility phase (Phase I) .21
5.1.1 Global security needs .24
5.1.2 Conceptual security needs .24
5.1.3 Contextual security needs .25
5.1.4 Healthcare communication responsibility in terms of proof construction and verification.28
5.2 The Technology phase (Phase II).30
5.2.1 The needs and requirements level for security solution expression.30
5.2.2 The functionality level for security solution specification .30
5.2.3 The function level for security solution refinement.30
5.2.4 The mechanism level for security solution design .31
5.2.5 The protocol level for security solution implementation .31
5.2.6 The service level for security solution invocation .31
5.2.7 The procedure level for security solution verification.31
5.3 The Standardization phase (Phase III).32
6 Architecture of the Policy Bridging Model (PBM) .32
6.1.1 Responsibility in the Policy Bridging Model: proof and obligations .34
6.1.2 Technologies in the Policy Bridging Model: different levels of solutions.37
Annex A (informative) Communication Protection Profile examples and refinements .42
A.1 Refinement of the “auditability” definition .42
A.2 Examples of CPPs .44
Annex B (informative) prEN 13608 Part 2: Secure Healthcare Data Objects.48
B.1 Scope of prEN 13608 Part 2: Secure Healthcare Data Objects .48
B.2 Description of prEN 13608 Part 2: Secure Healthcare Data Objects .48
B.3 Technological solutions covered by standard .49
B.4 Conclusions.50
Annex C (informative) prEN 13608 Part 3: Secure Data Channels .51
C.1 Scope of prEN 13608 Part 3: Secure Data Channels.51
C.2 Description of prEN 13608 Part 3: Secure Data Channels .51
C.3 Technological solutions covered by standard .52
C.4 Conclusions.53
Annex D (informative) ISO/OSI 7498-2 Information processing systems – Open Systems
Interconnection – Basic Reference Model – Part 2: Security Architecture .54
D.1 Scope of ISO 7498-2 .54
D.2 Technological solutions covered by standard ISO 7498-2.54
D.3 Technological solutions covered by this standard.54
D.4 Conclusions.56
2
---------------------- Page: 4 ----------------------
oSIST prEN 13608-1:2006
prEN 13608-1:2005 (E)
Annex E (informative) ITU/CCITT X.435 Message Handling Systems: Electronic Data Interchange
Messaging System (Recommendation X.435) and ITU/CCITT F.435 Message Handling
Services: Electronic Data Interchange Message Service (Recommendation F.435) .57
E.1 Scope.57
E.2 Technological solutions covered by standard.57
E.3 Technological solutions covered by this standard .58
E.4 Conclusions.60
Annex F (informative) ISO 9735 EDIFACT Application level syntax rules Electronic data
interchange for administration, commerce and transport:.61
F.1 Scope.61
F.2 Technological solutions covered by standard.61
F.3 Technological solutions covered by this standard .61
F.4 Conclusions.62
Annex G (informative) ENV 12924:1997: Medical Informatics – Security Categorisation and
Protection for Healthcare Information Systems.63
G.1 Scope of the Security Categorisation standard .63
G.2 Technological solutions covered by the Security Categorisation standard.63
G.3 Technological solutions covered by this standard .64
G.4 Conclusions.65
Annex H (informative) Distribution Rules (CENTC251/WG1 N98-32 PT028) .66
H.1 Scope of Distribution Rules .66
H.2 Technological solutions covered by standard.66
H.3 Technological solutions covered by this standard .67
H.4 Conclusions.68
Annex I (informative) HL7.69
I.1 Scope of HL7.69
I.2 Technological solutions covered by standard.69
I.3 Conclusions.71
Annex J (informative) CORBA .72
J.1 Scope of CORBA .72
J.2 Technological solutions covered by standard.72
J.3 Technological solutions covered by this standard .73
J.4 Conclusions.74
Annex K (informative) Common Criteria.75
K.1 Scope and background.75
K.2 Common Criteria concepts and structures .75
K.3 Common Criteria vs. the SCT approach .76
K.4 Conclusions.76
Annex L (informative) Introduction to cryptography.77
L.1 Scope.77
L.2 Algorithms.77
L.3 Certification.78
L.4 Planned re-keying for encryption keys .79
L.5 Emergency re-keying.79
L.6 Signature Key life times.79
L.7 Comparing Cryptographic key sizes .80
L.8 Protecting private keys.80
L.9 Signature attacks.81
L.10 Security issues with small RSA public exponents .81
L.11 RSA key generation issues .82
L.12 Random Number Generation.82
Bibliography.83
3
---------------------- Page: 5 ----------------------
oSIST prEN 13608-1:2006
prEN 13608-1:2005 (E)
Foreword
This document (prEN 13608-1:2005) has been prepared by Technical Committee CEN/TC 251 “Health
informatics”, the secretariat of which is held by SIS.
This document is currently submitted to the CEN Enquiry.
This document will supersede ENV 13608-1:2000.
EN 13608 consists of the following parts, under the general title Health informatics — Security for Healthcare
Communication (SEC-COM):
Part 1: Concepts and Terminology
Part 2: Secure Data Objects
Part 3: Secure Data Channels
This standard is designed to meet the demands of the Technical Report CEN/TC251/N98-110 Health
Informatics — Framework for security protection of health care communication.
This standard is drafted using the conventions of the ISO/IEC Directive Part 3.
All annexes are informative.
4
---------------------- Page: 6 ----------------------
oSIST prEN 13608-1:2006
prEN 13608-1:2005 (E)
Introduction
This multipart standard (prEN 13608) on Security for healthcare communication can be applied to a wide
range of communication protocols and information system applications relevant to healthcare, though they are
neither complete nor exhaustive in that respect.
Part 1 – Concepts and Terminology – reflects a user-requirements driven approach and a methodology for the
analysis of the relation between 1) user needs and 2) a technological solution. At the core of this methodology
is the Policy Bridging Model (PBM) constituting the policy bridging process. The essential concepts of the
PBM are defined in chapter 5, and the more detailed process defined in chapter 6. The methodology begins
with a standardised way of expressing user needs, continues through technology-oriented successive
refinements of the corresponding required security solutions and ends with a standard-oriented map of the
corresponding recommended security solutions. Such a method can be utilised in many ways, out of which
the two most important usages are:
1) as a general, stand-alone tool for breaking down user needs into technological solutions, through a
process/journey of close collaboration between users and security experts, and
2) through using this common (normative) method in the standardization process, establishing a link
between a defined set of user needs and a technological standard. Such a link carries an a priori
assurance on the effectiveness of the technological standards in terms of complying with the user
needs. Such an a priori assurance will be of special value for the user that do not want to exercise
the method in detail on his/her own, but merely want to benefit from an established, and in that sense
normative, link between a set of user needs that he/she can recognise, and the existence of an
implementation standard.
The PBM and its methodology is organised by means of a matrix, and the path through this matrix from the
user needs to a technological solution may be viewed as the standard for the specification of a
Communication Protection Profile (CPP), according to CEN/TC251/N98-110.
1) 1)
prEN 13608-2 and prEN 13608-3 are examples of clause 2 mentioned above. prEN13608 as a whole is
designed for further extensions (prEN 13608-x) based on the same scheme.
It is of paramount importance for the understanding of this methodology of prEN 13608-1, to recognise that it
comprises a journey from user needs to detailed technological specifications, and that several distinct
perspectives and contexts are undertaken along this journey. In particular, it is important to recognise that
commonly used (already existing, e.g. ISO) standards are comparable to only a subset of the total number of
contexts defined by the method. E.g. it has been necessary to introduce the concept of auditability for the user
need context, because the more commonly used notion of accountability is perceived to have a more limited
and technical constitution.
Different user views will imply different patterns of use of the matrix. For standardization purposes (to
constitute a valid CPP), the matrix must be filled out in detail (however only in those parts that are applicable
for a selection of user needs). This process provides some level of assurance that the actual technological
solution is an effective representation of the user needs defined in the actual CPP. The method itself does not
specify in detail how each specific cell of the matrix shall appear. Annexes B-J provide examples that may be
viewed as guidelines, of which Annexes B and C has a special role because of their correspondence with the
already existing prEN 13608-2 and prEN 13608-3.
1) To be published.
5
---------------------- Page: 7 ----------------------
oSIST prEN 13608-1:2006
prEN 13608-1:2005 (E)
Thus, this Part 1 offers a set of different views or journeys through the successive refinement from user need
to technological solution. The security journey on the most detailed level is a combination of :
1) top-down approach, by allowing for a systematic translation from a common policy expression, down
to technological choices and options;
2) bottom-up approach, by being focused on utilisation of existing, commercial technologies.
Hence, the CPP concept must not be understood as a purely deductive (one-way) development from user
needs to technological solution, but merely as a (standardised) statement that gives evidential indication that a
specific technological standard, is an effective and reasonable fulfilment of a specific set of user needs.
Hence, the normative function of Part 1 can be summarised as:
1) standardising the way of expressing a communication security policy;
2) standardising the steps of successive refinements down to the technology level, in order to provide a
2)
minimum level of assurance .
The benefit for a end-user is that he can look for a CPP that matches his demand for:
a) a matching set of user needs;
b) a technological context (e.g. EDI);
and successively identifies:
c) a named implementation standard (e.g. Annexes B and C that corresponds with prEN 13608-2 and
prEN 13608-3, respectively).
In the latter case, the standardisation process offers the user a degree of assurance that a product meeting
the implementation standard effectively meets the user needs described in the Part 1 annex. Alternatively, if
such a standard is not found, he/she can use the method in cooperation with security experts, to constitute a
basis from which can be identified the needs and their effective solutions.
Figure 1 below depicts how the matrix is used methodologically to constitute relations between user needs,
technological contexts and implementation standards.
2) The actual level of assurance achieved is not comparable to what can be achieved through a security evaluation
process, cfr Annex K.
6
---------------------- Page: 8 ----------------------
oSIST prEN 13608-1:2006
prEN 13608-1:2005 (E)
Figure 1 — The Security Policy Bridging phases
Parts 2 and 3 are examples of implementation standards that have a CPP counterpart, as they both are
described in terms of Part 1 requirements (in Annex B and C). Both are based on rather simplistic
technological solutions, however with a wide installed base in healthcare and with a large potential for future
use. Both of them are based on commercial technologies with an existing product portfolio.
The method prescribed by Part 1 is however open in the sense that other pairs of CPP-standard can be
developed in the future – e.g. based on other technological concepts such as middleware, WWW-based
systems etc. These will successively be named pr EN 13608-4 and so on, and will be complemented by new
annexes in prEN 13608-1.
In order to provide external coherence:
Annex A provides some examples and illustrations of the usage of this SEC-COM part 1 in terms of
general security concepts, with a refined proposal for the auditability property;
Annexes D to J indicate what a selection of other security standards actually can currently offer in regard
of the SEC-COM method;
In Annex K, the relation between the assurance gained through the method, and the assurance gained in
a security evaluation based on Common Criteria, is discussed.
Possible future extensions of scope for 13608
Communicating parties (sender and receiver) using a common prEN 13608-X standard will implicitly be using
the same communication security police. The CPP approach defined by prEN 13608-1 can however in the
future be given an even wider implication. The CPP approach may also facilitate a more dynamic security
policy bridging between sender and receiver, that is, a policy bridging that may be negotiated before actual
communication between the parties. Such a negotiation will require a "standardised" description of the
embodiment of the site (communication) security policy. In the simplest case, the prEN 13608-1 (chapter 5)
way of expressing a (communication) security policy may be a (informal) basis for deciding whether to
communicate or not. Moreover, the systematic refinement of a (communication) security policy down to a
7
---------------------- Page: 9 ----------------------
oSIST prEN 13608-1:2006
prEN 13608-1:2005 (E)
more technical level constitutes the basis for a more automatic and precise decision process (semiformal).
Such a (possible) process may thus consist of three different steps, based on the PBM (as illustrated in
Figure 2 below):
a) the first step is the Terminology Linking one, ensuring that any communicating entity will be able to use
and understand a common security policy language,
b) the second step is the Policy Matching one, ensuring that any communicating entity will be able to
compare and match his own communication security policy with any peer entity’s communication security
policy,
c) the third step is the Policy Negotiation one, ensuring that any communicating entity will be able to adapt
his own communication security policy in order to be able to adopt a common communication security
policy (common in that it is shared by his communication peer entities).
Figure 2 — The Security Policy Bridging steps
8
---------------------- Page: 10 ----------------------
oSIST prEN 13608-1:2006
prEN 13608-1:2005 (E)
1 Scope
This European standard specifies a methodology for defining, expressing and selecting a communication
protection profile (CPP) specification, and thus provides:
1) a standard way of expressing healthcare user security needs in relation to communication;
2) a standard method of successive refinement of policy statements, hereby helping to identify
standardised security implementation specification that can be utilised to meet these security needs.
Security aspects contained within the communication protection profile include integrity, confidentiality, and
availability, and also auditability.
This methodology shall thus serve the purpose of being a tool for:
A. the end-user in collaboration with security experts, while seeking effective solutions for relevant and
powerful healthcare communication security needs;
B. the standardization process in which trustworthy links between 1) actual selections of such user
needs and 2) technological standards, are established.
2 Normative references
The following referenced documents are indispensable for the application 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 2382-8, Information technology — Vocabulary — Part 8: Security.
ISO 7498-2, Information processing systems — Open Systems Interconnection — Basic Reference Model —
Part 2: Security Architecture.
ISO 9594-8, Information technology — Open Systems Interconnection — The Directory: Authentication
framework.
ISO 10181-1, Information technology — Open Systems Interconnection — Security frameworks for open
systems: Overview.
ISO 8824-1:1995, Information Technology — Abstract syntax notation one (ASN.1) — Part 1: Specification of
basic notation.
ISO 9735-4, Electronic data interchange for administration, commerce and transport (EDIFACT) —
Application level syntax rules (Syntax version number : 4) — Part 4: Syntax and service report message for
batch EDI (message type CONTRL).
ISO 9735-5, Electronic data interchange for administration, commerce and transport (EDIFACT) —
Application level syntax rules (Syntax version number : 4) — Part 5: Security rules for batch EDI (authenticity,
integrity and non-repudiation of origin).
ISO 9735-6, Electronic data interchange for administration, commerce and transport (EDIFACT) —
Application level syntax rules (Syntax version number : 4) — Part 6: Secure authentication and
acknowledgement message (message type AUTACK).
ISO 9735-7, Electronic data interchange for administration, commerce and transport (EDIFACT) —
Application level syntax rules (syntax version number 4) — Pa
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.