BS DD ENV 13608-1-2000 Health informatics - Security for healthcare communication - Concepts and terminology《医疗保健信息学 保健通信的安全性 概念和术语》.pdf

1、| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DRAFT FOR DEVELOPMENT DD ENV 13608-1:2000

2、ICS 01.040.35; 35.240.80 NO COPYING WITHOUT BSI PERMISSION EXCEPT AS PERMITTED BY COPYRIGHT LAW Health informatics Security for Healthcare communication Part 1: Concepts and terminologyThis Draft for Development, having been prepared under the direction of the DISC Board, was published under the aut

3、hority of the Standards Committee and comes into effect on 15 August 2000 BSI 08-2000 ISBN 0 580 35484 9 DD ENV 13608-1:2000 Amendments issued since publication Amd. No. Date Comments National foreword This Draft for Development is the English language version of ENV 13608-1:2000. This publication i

4、s not to be regarded as a British Standard. It is being issued in the Draft for Develoment series of publications and is of a provisional nature due to the limited duration of the European Prestandard. It should be applied on this provisional basis, so that information and experience of its practica

5、l application may be obtained. Comments arising from the use of this Draft for Development are requested so that UK experience can be reported to the European organization responsible for its conversion into a European Standard. A review of this publication will be initiated 2 years after its public

6、ation by the European organization so that a decision can be taken on its status at the end of its 2 years after its publication by the European organization so that a decision can be taken on its status at the end of its three-year life. The commencement of the review period will be notified by an

7、announcement in Update Standards. According to the replies recieved by the end of the review period, the resonsible BSI Committee will decide whether to support the conversion into a European Standard, to extend the life of the pestandard or to withdraw it. Comments should be sent in writing to the

8、Secretary of BSI Technical Committee IST/35, Health Informatics, at 389 Chiswick High Road, London W4 4AL, giving the document reference and clause number and proposing, where possible, an appropriate revision of the text. A list of organizations represented on this committee can be obtained on requ

9、est to its secretary. Cross-references The British Standards which implement international or European publications referred to in this document may be found in the BSI Standards Catalogue under the section entitled “International Standards Correspondence Index”, or by using the “Find” facility of t

10、he BSI Standards Electronic Catalogue. Summary of pages This document comprises a front cover, an inside front cover, the ENV title page, pages 2 to 67 and a back cover. The BSI copyright notice displayed in this document indicates when the document was last issued.EUROPEANPRESTANDARD PRNORMEEUROPEN

11、NE EUROPISCHEVORNORM ENV136081 May2000 ICS01.040.35;35.040;35.240.80 Englishversion HealthinformaticsSecurityforhealthcarecommunicationPart 1:Conceptsandterminology ThisEuropeanPrestandard(ENV)wasapprovedbyCENon29July1999asaprospectivestandardforprovisionalapplication. TheperiodofvalidityofthisENVis

12、limitedinitiallytothreeyears.AftertwoyearsthemembersofCENwillberequestedto submittheir comments,particularlyonthequestionwhethertheENVcanbeconvertedintoaEuropeanStandard. CENmembersarerequiredtoannouncetheexistenceofthisENVinthesamewayasforanENandtomaketheENVavailablepromp tly atnationallevelinanapp

13、ropriateform.Itispermissibletokeepconflictingnationalstandardsinforce(inparalleltothe ENV)untilthefinal decisionaboutthepossibleconversionoftheENVintoanENisreached. CENmembersarethenationalstandardsbodiesofAustria,Belgium,CzechRepublic,Denmark,Finland,France,Germany,Greece, Iceland,Ireland,Italy,Lux

14、embourg,Netherlands,Norway,Portugal,Spain,Sweden,SwitzerlandandUnitedKingdom. EUROPEANCOMMITTEEFORSTANDARDIZATION COMITEUROPENDENORMALISATION EUROPISCHESKOMITEEFRNORMUNG CentralSecretariat:ruedeStassart,36B1050Brussels 2000CEN Allrightsofexploitationinanyformandbyanymeansreserved worldwideforCENnati

15、onalMembers. Ref.No.ENV136081:2000EPage2 ENV136081:2000 Contents Foreword 3 Introduction3 1 Scope .6 2 Normativereferences .7 3 Definitions.8 4 SymbolsandAbbreviations . .16 5 HealthcareCommunicationProtectionProfileConcepts 17 6 ArchitectureofthePolicyBridgingModel(PBM) . 26 AnnexA(informative):Com

16、municationProtectionProfileexamplesandrefinements.34 AnnexB(informative):SECCOMPart2SecureHealthcareDataObjects .40 AnnexC(informative):SECCOMPart3:SecureDataChannels 42 AnnexD(informative):ISO/OSI74982InformationprocessingsystemsOpenSystemsInterconnection BasicReferenceModelPart2:SecurityArchitectu

17、re. .44 AnnexE(informative):ITU/CCITTX.435MessageHandlingSystems:ElectronicDataInterchange MessagingSystem(RecommendationX.435)andITU/CCITTF.435MessageHandlingServices:Electronic DataInterchangeMessageService(RecommendationF.435) .46 AnnexF(informative):ISO9735EDIFACTApplicationlevelsyntaxrulesElect

18、ronicdatainterchangefor administration,commerceandtransport: .49 AnnexG(informative)ENV12924:1997:MedicalInformaticsSecurityCategorisationandProtectionfor HealthcareInformationSystems . .51 AnnexH(informative):DistributionRules(CENTC251/WG1N9832PT028) 53 AnnexI(informative):HL7 . .55 AnnexJ(informat

19、ive):CORBA. 57 AnnexK(informative):CommonCriteria. .59 AnnexL(informative):Introductiontocryptography .61 Bibliography.66Page3 ENV136081:2000 Foreword ThisEuropeanPrestandardhasbeenpreparedbyTechnicalCommitteeCEN/TC251“Healthinformatics“,the secretariatofwhichisheldbySIS. AccordingtotheCEN/CENELECIn

20、ternalRegulations,thenationalstandardsorganizationsofthefollowing countriesareboundtoannouncethisEuropeanPrestandard:Austria,Belgium,CzechRepublic,Denmark,Finland, France,Germany,Greece,Iceland,Ireland,Italy,Luxembourg,Netherlands,Norway,Portugal,Spain,Sweden, SwitzerlandandtheUnitedKingdom. Thismul

21、tipartstandardconsistsofthefollowingparts,underthegeneraltitle SecurityforHealthcare Communication(SECCOM): Part1:ConceptsandTerminology Part2:SecureDataObjects Part3:SecureDataChannels ThisstandardisdesignedtomeetthedemandsoftheTechnicalReportCEN/TC251/N98110HealthInformatics Frameworkforsecuritypr

22、otectionofhealthcarecommunication . ThisstandardwasdraftedusingtheconventionsoftheISO/IECdirectivePart3. Allannexesareinformative. Introduction ThisSECCOMstandardseriesonSecurityforhealthcarecommunicationcanbeappliedtoawiderangeof communicationprotocolsandinformationsystemapplicationsrelevanttohealt

23、hcare,thoughtheyareneither completenorexhaustiveinthatrespect. Part1ConceptsandTerminologyreflectsauserrequirementsdrivenapproachthatprovidesamethodology fortheanalysisoftherelationbetween1)userneedsand2)atechnologicalsolution.Itbeginswithastandardised wayofexpressinguserneeds,continuesthroughtechno

24、logyorientedsuccessiverefinementsofthecorresponding requiredsecuritysolutionsandendswithastandardorientedmapofthecorrespondingrecommendedsecurity solutions.Suchamethodcanbeutilisedinmanyways,outofwhichtwoimportantusagesare: 1. asacommontoolforbreakingdownuserneedsintotechnologicalsolutions,throughap

25、rocess/journeyof closecollaborationbetweenusersandsecurityexperts,and 2. throughusingthiscommonmethodinthestandardizationprocess,establishingalinkbetweenadefinedsetof userneedsandatechnologicalstandard,alinkthatcarriesan aprioriassuranceontheeffectivenessofthe technologicalstandardsintermsofcomplyin

26、gwiththeuserneeds.Suchan aprioriassurancewillbeof specialvaluefortheuserthatdonotwanttoexercisethemethodindetailonhisown,butmerelywantto benefitfromanestablishedlink betweenasetofuserneedsthathe/shecanrecognise,andtheexistenceofan implementationstandard. Readerswithoutabackgroundincommunicationssecu

27、rityarereferredtoAnnexL. Themethodologyisorganisedbymeansofamatrix,andthepaththroughthismatrixfromtheuserneedstoa technologicalsolutionmaybeviewedasthestandardforthespecificationofaCommunicationProtectionProfile (CPP),accordingtoCEN/TC251/N98110. Itisofparamountimportancefortheunderstandingofthismet

28、hodologytorecognisethatitcomprisesajourney fromuserneedstodetailedtechnologicalspecifications,andthatseveraldistinctperspectivesandcontextsare undertakenalongthisjourney.Inparticular,itisimportanttorecognisethatcommonlyused(alreadyexisting,e.g. ISO)standardsarecomparabletoonlyasubsetofthetotalnumber

29、ofcontextsdefinedbythemethod.E.g.ithas beennecessarytointroducetheconceptof auditabilityforthe userneedcontext ,becausethemorecommonlyused notionof accountabilityisperceivedtohaveamore limitedand technicalconstitution . Differentuserviewswillimplydifferentpatternsofuseofthematrix.Forstandardizationp

30、urposes(toconstitutea validCPP),thematrixmustbefilledoutindetail(howeveronlyinthosepartsthatareapplicableforaselectionofPage4 ENV136081:2000 userneeds).Thisprocessprovidessomelevelof assurancethattheactualtechnologicalsolutionisan effective representationoftheuserneedsdefinedintheactualCPP.Themethod

31、itselfdoesnotspecifyindetailhoweach specificcellofthematrixshallappear.However,AnnexesBJprovideexamplesthatmaybeviewedas guidelines. Part1offersasetofdifferent viewsor journeysthroughthesuccessiverefinementfromuserneedtotechnological solution.Thesecurityjourneyonthemostdetailedlevelisa combinationof

32、: 1. topdownapproach,byallowingforasystematictranslationfromacommonpolicyexpression,downto technologicalchoicesandoptions; 2. bottomupapproach,bybeingfocusedonutilisationofexisting,commercialtechnologies. Hence,theCPPconceptmustnotbeunderstoodasaforced(oneway)development fromuserneedsto technologica

33、lsolution,butmerelyasa(standardised)statementthatgivesevidentialindicationthataspecific technologicalstandard,isan effectiveandreasonablefulfilment ofaspecificsetofuserneeds. Hence,thenormativefunctionofPart1canbesummarisedas: 1. standardisingthewayofexpressingacommunicationsecuritypolicy; 2. standa

34、rdisingthestepsofsuccessiverefinementsdowntothetechnologylevel,inordertoprovideaminimum levelofassurance 1 . ThebenefitforaenduseristhathecanlookforaCPPthatmatcheshisdemandfor: a. amatchingsetofuserneeds; b. atechnologicalcontext(e.g.EDI); andsuccessivelyidentifies: c. anamedimplementationstandard(e

35、.g.Part2or3ofthisPrestandard). Theuserwillthenbeassuredthatthestandardizationrubberstampimplicitlygiveshimsomeassurancethata productmeetingtheimplementationstandardeffectivelymeetshisuserneeds.Alternatively,ifsuchastandardis notfound,he/shecanusethemethodincooperationwithsecurityexperts,toconstitute

36、abasisfromwhichcanbe identifiedtheneedsandtheireffectivesolutions 2 . Figure1belowdepictshowthematrixisusedmethodologicallytoconstituterelationsbetweenuserneeds, technologicalcontextsandimplementationstandards. Informal CPP Responsibilityphase Technologyphase Standardisationphase WHY? WHATFOR? HOW?

37、WHAT? Figure1TheSecurityPolicyBridgingphases Parts2and3areexamplesofimplementationstandardsthathaveaCPPcounterpart,astheybotharedescribedin termsofPart1requirements(inAnnexBandC).Botharebasedonrathersimplistictechnologicalcontexts, howeverwithawideinstalledbaseinhealthcareandwithalargepotentialforfu

38、tureuse.Bothofthemarebased oncommercialtechnologieswithanexistingproductportfolio. 1 Theactuallevelofassuranceachievedisnotcomparabletowhatcanbeachievedthroughasecurityevaluationprocess,cfr AnnexK. 2 ultimatelywiththepotentialofconstitutingabasisforbridginghis/hercommunicationssecuritypolicywiththos

39、eof communicationcounterparts.Page5 ENV136081:2000 ThemethodprescribedbyPart1ishoweveropeninthesensethatotherpairsofCPPstandardcanbedevelopedin thefuturee.g.basedonothertechnologicalconceptssuchasmiddleware,WWWbasedsystemsetc. Inordertoprovideexternalcoherence: AnnexAprovidessomeexamplesandillustrat

40、ionsoftheusageofthisSECCOMpart1intermsofgeneral securityconcepts,witharefinedproposalfortheauditabilityproperty, AnnexesDtoJindicatewhataselectionof othersecuritystandardsactuallycancurrentlyofferinregardofthe SECCOMmethod, InAnnexK,therelationbetweentheassurancegainedthroughthemethod,andtheassuranc

41、egainedina securityevaluationbasedonCommonCriteria,isdiscussed, AnnexLgivessometutorialontheintroductiontocryptographyusedforcommunicationsecurity. TheCPPapproachbasedonPart1canhoweverhavewiderimplicationsthandescribedsofar.Howeverwithout normativeimplicationsinthisstandard,itisemphasisedthattheCPPa

42、pproachmayalsofacilitate(endsystems) securitypolicybridging ,whichrequiresa“standardised“descriptionoftheembodimentofthesitesecuritypolicy. Inthesimplestcase,thePart1wayofexpressinga(communication)securitypolicymaybea(informal)basisfor decidingwhethertocommunicateornot.Moreover,thesystematicrefineme

43、ntofa(communication)security policydowntoamoretechnicallevelconstitutesthebasisforamoreautomaticandprecisedecisionprocess (semiformal).Suchaprocessthusconsistsofthreedifferentsteps(alsoillustratedinthefigurebelow): i. Thefirststepisthe TerminologyLinkingone ,ensuringthatanycommunicatingentitywillbea

44、bletouse andunderstanda commonsecuritypolicylanguage, ii. ThesecondstepisthePolicyMatchingone,ensuringthatanycommunicatingentitywillbeableto compareandmatchhisowncommunicationsecuritypolicywithanypeerentityscommunicationsecurity policy, iii. Thethirdstepisthe PolicyNegotiationone ,ensuringthatanycommunicatingentitywillbeabletoadapt hisowncommuni