1、DRAFT FOR DEVELOPMENT Health informatics - Security for Healthcare communication - Part 1: Concepts and terminology ICs 01.040.35; 36.240.80 NO COPYING WITIIouT BSI PERMISSION EXCEPT AS PERMITTED BY COPYRIGHT LAW DD ENV 1360 35.040; 35.240.80 English version Health informatics - Security for healthc
2、are communication - Part 1 : Concepts and terminology This European Prestandard (ENV) was approved by CEN on 29 July 1999 as a prospective standard for provisional application. The period of validity of this ENV is limited initially to three years. Ater two years the members of CEN will be requested
3、 to submit their comments, particularly on the question whether the ENV can be converted into a European Standard. CEN members are required to announce the existence of this ENV in the same way as for an EN and to make the ENV available promptly at national level in an appropriate form. It is permis
4、sible to keep conflicting national standards in force (in parallel to the ENV) until the final decision about the possible conversion of the ENV into an EN is reached. CEN members are the national standards bodies of Austria, Belgium, Czech Republic, Denmark, Finland, France, Germany, Greece, Icelan
5、d, Ireland, Italy, Luxembourg, Netherlands, Norway, Portugal, Spain, Sweden, Switzerland and United Kingdom. EUROPEAN COMMITTEE FOR STANDARDIZATION COMITE EUROPEEN DE NORMALISATION EUROPISCHES KOMITEE FR NORMUNG Central Secretariat: rue de Stassar, 36 8-1050 Brussels Q 2000 CEN All rights of exploit
6、ation in any form and by any means reserved worldwide for CEN national Members. Ref. No. ENV 13608-1 2000 E - STD.BSI DD ENV L3608-L-ENGL 2000 D Lb24hh9 0858821 034 Page 2 ENV 13608-1:2000 Contents Foreword “ 3 Introductio. . 3 1 Scope . 6 2 Normative references . 7 3 Definitions . 8 4 Symbols and A
7、bbreviations 16 5 6 Healthcare Communication Protection Profile Concepts . 17 Architecture of the Policy Bridging Model (PBM) . 26 Annex A (informative): Communication Protection Profile examples and refinements . 34 Annex B (informative): SEC-COM Part 2 Secure Healthcare Data Objects u . 40 Annex C
8、 (informative): SEC-COM Part 3: Secure Data Channels 42 Annex D (informative): ISO/OSI 7498-2 Information processing systems . Open Systems Interconnection . Basic Reference Model . Part2: Security Architecture 44 Annex E (informative): ITU/CCT X.435 Message Handling System: Electronic Data Intercha
9、nge Messaging System (Recommendation X.435) and IT/CCITT F.435 Message Handling Services: Electronic Data Interchange Message Service (Recommendation F.435) . 46 Annex F (informative): IS0 9735 EDIFACT Application levei syntax nes Electronic data interchange for administration. commerce and trpo rt:
10、 . 49 Annex G (informative) ENV 12924:1997: Medical Informatics . Security Categohtion and Protection for Healthcare Information Sys terns . , 51 Annex H (informative): Distribution Rules (CENTC25yWGl N98-32 PTOB) 53 Annex I (informative): HL7 . (, 55 Annex J (informative): CORBA . 57 Annex K (infor
11、mative): Common Criteria 59 Annex L (informative): Introduction to cryptography . “ 61 Bibliography “ STD=BSI DD ENV 13608-1-ENGL 2000 I 1624669 0858822 T70 Page 3 ENV 13608-1:2000 Foreword This European Prestandard has been prepared by Technical Committee CENfC 251 “Health informatics“, the secreta
12、riat of which is held by SIS. According to the CENKENELEC Internal Regulations, the national standards organizations of the following countries are bound to announce this European Prestandard: Austria, Belgium, Czech Republic, Denmark, Finland, France, Germany, Greece, Iceland, Ireland, Italy, Luxem
13、bourg, Netherlands, Norway, Portugal, Spain, Sweden, Switzerland and the United Kingdom. This multipart standard consists of the following parts, under the general title Security for Healthcare Communication (SEC- COM): - - - Part 1: Concepts and Terminology Part 2: Secure Data Objects Part 3: Secur
14、e Data Channels This standard is designed to meet the demands of the Technical Report CEN/TC25l/N98-110 Health Informatics - Framework for security protection of health care communication. This standard was drafted using the conventions of the ISODEC directive Part 3. All annexes are informative. In
15、troduction This SEC-COM standard series 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 -
16、reflects a user-requirements driven approach that provides a methodology for the analysis of the relation between 1) user needs and 2) a technological solution. It begins with a standardised way of expressing user needs, continues through technology-oriented successive refinements of the correspondi
17、ng 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 two important usages are: 1. 2. as a common tool for breaking down user needs into technological solutions, through a pro
18、cess/journey of close collaboration between users and security experts, and through using this common method in the standardization process, establishing a link between a defined set of user needs and a technological standard, a link that carries an a priori assurance on the effectiveness of the tec
19、hnological 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 own, but merely want to benejit from an established link between a set of user needs that helshe can recognise, an
20、d the existence of an implementation standard. Readers without a background in communications security are referred to Annex L. The 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 sp
21、ecification of a Communication Protection Profile (CPP), according to CENfC25 1/N98-110. It is of paramount importance for the understanding of this methodology to recognise that it comprises a journey from user needs to detailed technological specifications, and that several distinct perspectives a
22、nd 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 auditabil
23、ity for the user need context, because the more commonly used notion of accountability is perceived to have a more limited and technical constitution. Diferent user views will imply different patterns of use of the matrix. For standardization purposes (to constitute a valid CPP), the matrix must be
24、filled out in detail (however only in those parts that are applicable for a selection of STD-BSI DD ENV L3bOB-L-ENGL 2000 Lb24bb9 0856823 907 W Page 4 user needs). This process provides some level of assurance that the actual technological solution i an deetive representation of the user needs defin
25、ed in the actual CPP. The method itself does not specify in detail how each specific cell of the matrix shall appear. However, Annexes B-J provide examples that may be viewed as guidelines. ENV 13608-1:2OOO Part 1 offers a set of different views orjourneys through the successive refinement from user
26、 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
27、existing, commercial technologies. Hence, the CPP concept must not be understood as a forced (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 an reasonubl
28、ejljilmeru 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 minimum levei of
29、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. Part 2 or 3 of this Prestandard). The user will then be assur
30、ed that the standardization aubber stamp implicitly gives him some assurance that a product meeting the implementation standard effectively meets his user needs. Alternatively, if such a standard is not found, hdshe can use the method in cooperation with security experts, to constitute a basis from
31、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. Figure 1 - The Security Poiicy Bridging phases Parts 2 and 3 are examples o
32、f 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 contexts, however with a wide installed bke in healthcare and with a large potentiai for fue use. Both of them are
33、based on commercial technologies with an existing product portfolio. The actuai level of assurance achieved is not comparable to what can be achieved through a sdty evaluation process, cfr Annex K. * ultimately with the potential of constituting a basis for bridging hisiher communications dty policy
34、 with those of communication counterparts. 1 STD*BSI DD ENV lI3bOB-lI-ENGL 2000 = Lb24669 0858824 843 Page 5 The method prescribed by Part lis 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, WW
35、W-based systems etc. ENV 13608-1:2000 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 0 Annexes D to J indicate what a selection of other security standards actually can currently offer in regard of the
36、.In Annex K, the relation between the assurance gained through the method, and the assurance gained in a 0 Annex L gives some tutorial on the introduction to cryptography used for communication security. security concepts, with a refined proposal for the auditability property, SEC-COM method, securi
37、ty evaluation based on Common Criteria, is discussed, The CPP approach based on Pari 1 can however have wider implications than described so far. However without normative implications in this standard, it is emphasised that the CPP approach may also facilitate (end-systems) securis, policy bridging
38、, which requires a “standardised“ description of the embodiment of the site security policy. In the simplest case, the Pari 1 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 (communicat
39、ion) security policy down to a more technical level constitutes the basis for a more automatic and precise decision process (semiformal). Such a process thus consists of three different steps (also illustrated in the figure below): i. The first step is the Terminology Linking one, ensuring that any
40、communicating entity will be able to use and understand a common security policy language, ii. 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 entitys communication security polic
41、y, iii. 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 - Th
42、e Security Policy Bridging steps STDmBSI DD ENV 13608-L-ENGL 2000 Lb24bbel 0858825 78T Page 6 FiNV 13608-1:2000 Health informatics - Security for heaithcare communication - Part 1: Concepts and terminology 1 Scope This European Prestandard specifies a methodology for defining, expressing and selecti
43、ng 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 implementatio
44、n specification that can be utilised to meet these security needs. Security aspects contained within the communication protection profile include integrity, configientiality, and availability, and also auditability. This methodology shall thus serve the purpose of being a tool for: A. the end-user i
45、n collaboration with security experts, while seeking effective solutions for relevant and powerful heaithcare 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. Page
46、7 ENV 13608-1:2000 2 Normative references This European Prestandard incorporates by dated or undated reference, provisions from other publications. These normative references are cited at the appropriate places in the text and the publications are listed hereafter. For dated references, subsequent a
47、mendments to, or revisions of any of these publications apply to this European Prestandard only when incorporated in it by amendment or revision. For undated references, the latest edition of the publication referred to applies. ISO/IEC 2382-8 IS0 7498-2 IS0 9594-8 IS0 10181-1 IS0 8824-11995 IS0 973
48、5-4 IS0 9735-5 IS0 9735-6 IS0 9735-7 ITU/CCI?T X.435 ITU/CCIT F.435 PKCS#7 Information technology - Vocabulary - Part 8: Security (1998) Information processing systems - Open Systems Interconnection - Basic Reference Model - Part 2: Security Architecture Information technology - Open Systems Interco
49、nnection - The Directory: Authentication framework Information technology - Open Systems Interconnection - Security frameworks for open systems: Overview Information Technology - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.l). - Part 1: Specification of the basic notation Electronic data interchange for administration, commerce and transport (EDIFACT) - Application level syntax rules Part 4 Syntax and service report message for batch ED1 (Message type - COmL) Electronic data interchange for administration, commerce and t
