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
