1 / 40

IHE Security

IHE Security. IHE Europe 2006 - Changing the Way Healthcare Connects IHE Presentation at the World of Health IT show, October 2006 G. Claeys IHE Europe Agfa Healthcare / CTO Office. Courtesy of C. Sacchavini, J. Moehrke. Overview. Security needs IHE ATNA IHE DSG IHE BPPC

antoinettec
Télécharger la présentation

IHE Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IHE Security IHE Europe 2006 - Changing the Way Healthcare Connects IHE Presentation at the World of Health IT show, October 2006 G. Claeys IHE Europe Agfa Healthcare / CTO Office Courtesy of C. Sacchavini, J. Moehrke

  2. Overview • Security needs • IHE ATNA • IHE DSG • IHE BPPC • Practical example : XDS Security

  3. Scope • Defines basic security features for a system in a healthcare enterprise in order to guarantee : • Only authorized persons have access to PHI (Protected Health Information) • Protect PHI against alteration, destruction and loss • Comply existing Privacy & Security regulations

  4. Security Mechanism • Authentication (user and device) • Authorization • Accountability (audit trails) • Confidentiality • Integrity ATNA, EUA/XUA ATNA ATNA ATNA, DSG

  5. Audit Trail and Node Authentication G. Claeys, Agfa Healthcare (geert.claeys@agfa.com)

  6. Local authentication of user • Strong authentication of remote node (digital certificates) • Audit trail that logs privacy&security related operations Secured System Secure network Central Audit TrailRepository IHE ATNA- Architecture Secured System Secure network System B System A

  7. IHE ATNA – Actor and Transactions All existing IHE actors need to be grouped with a Secure Node actor. Audit Record Repository Time Server Maintain Time Record Audit Event Secure Node Authenticate Node “Any” IHE actor Secure Node

  8. Secure Node • Local user authentication • Only needed at “client” node • Authentication mechanism • User name and password (minimum) • Biometrics, smart card • Secure nodes maintain list of authorized users : local or central (using EUA) • Security policy of hospital defines the relation between user and user id

  9. Secure Node (cont.) • Mutual device authentication • Establish a trust relationship between 2 network nodes • Strong authentication by exchanging X.509 certificates • Actor must be able to configure certificate list of trusted nodes. • TCP/IP Transport Layer Security Protocol (TLS) • Used with DICOM/HL7/HTTP messages • Secure handshake protocol during Association establishment: • Encryption : • Intra-muros (default): no encryption • Extra-muros : AES128

  10. Secure node – additional effort • Instrument all applications to detect auditable events and generate audit messages. • Ensure that all communications connections are protected (system hardening). • Establish a local security mechanism to protect all local resources • Establish configuration mechanisms for: • Time synchronization • Certificate management • Network configuration

  11. Certificate Management • Certificates can be signed by device (self-signing) or via a CA (e.g. hospital) • Use self-signed certificates for testing interoperability • Connectathon has a CA • Support at least direct comparison of certificates • Import certificate of each trusted peer device • Compare each received certificate with list of trusted certificate • Certificate management white paper • from NEMA’s Security&Privacy committee • www.nema.org/prod/med/security

  12. Auditing System • Auditing system consists of • List of events that generate audit messages • Audit message format • Transport mechanism • Designed for surveillance rather than forensic use.

  13. Audit Events • Audit triggers are defined for every operation that access PHI (create, delete, modify, import/export) • IHE TF describes the supported Audit Trigger per Actor • Audit triggers are grouped on transaction/ study level to minimize overhead

  14. Audit Message Format • XML encoded message • IHE Radiology Provisional format • for backward compatibility with radiology • ATNA format • Preferred format • Joint effort of IETF/DICOM/HL7/ASTM • XML schema (rfc3881) : www.xml.org/xml/schema/7f0d86bd/healthcare-security-audit.xsd • XSLT transformation is provided to convert “Provisional scheme” to “ATNA” scheme

  15. Audit Transport Mechanism • Reliable Syslog – cooked mode • RFC 3195 • Connection oriented • Support certificate based authentication, encryption • But limited industry support • BSD Syslog protocol (RFC 3164) • Preferred transport mechanism for the time being

  16. Document Digital Signature(DSG)

  17. Purpose • document integrity • non-repudiation • accountability.

  18. Document Digital Signaturescope • A Digital Signature is a separate XDS document • Supports • single / multiple signatures • nested signatures • Standard : XAdES (W3C) + X.509 certificates • Vendor must provide signature mechanism for XDS Submissions

  19. Document Digital SignatureOut of scope • Certificate management and PKI concepts • Focus begins with signing, not encryption • Partial Document Signature

  20. Combined to: Signed Document Original Document Equal HASH function Asymmetric algorithm Private Key used for signing Document Digital SignatureThe Signing Ceremony

  21. Document Digital SinatureVerification Original Document Message HASH EAdfj78oXWq HASH function Signed Document Equal Public Key of Signer Asymmetric Algorithm EAdfj78oXWq Signature Original HASH (Signer generated)

  22. Document Digital SigantureXML Digital Signature Tools • Apache XML Security project has both Java and C++ implementations of XML Digital Signature (open source) http://xml.apache.org/security/ • JSR 105: Java XML Digital Signature API with reference implementations-- final release by Sun and IBM June 24, 2005. http://jcp.org/aboutJava/communityprocess/final/jsr105/index.html

  23. Document Digital SignatureCommercial Toolkits (not comprehensive list) • http://jce.iaik.tugraz.at/products/052_XSECT/index.php • http://www.infomosaic.net/SecureXMLDetailInfo.htm • http://www.betrusted.com/products/keytools/xml/index.asp • http://www.phaos.com/products/category/xml.html • http://www.verisign.com/products-services/security-services/pki/xml-trust-services/index.html

  24. Document Digital SignatureXDS Sample Code <Signature Id="signatureOID" xmlns=http://www.w3.org/2000/09/xmldsig# xmlns:xad=”xmlns="http://uri.etsi.org/01903/v1.1.1#"”> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments”/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <Reference URI="#IHEManifest" Type="http://www.w3.org/2000/09/xmldsig#Manifest"> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>base64ManifestDigestValue</DigestValue> </Reference> </SignedInfo> <SignatureValue>base64SignatureValue</SignatureValue> <KeyInfo> <X509Data> <X509Certificate>base64X509certificate<X509Certificate> </X509Data> </KeyInfo>

  25. Document Digital SignatureXDS Sample Code <Object> <xad:QualifyingProperties> <xad:SignedProperties> <xad:SignedSIgnatureProperties> <xad:SigningTime> yyyymmddhhmmss</SigningTime> <xad:SigningCertificate> <xad:Cert> <!-- identifier of signing certificate --> <xad:CertDigest> <xad:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <xad:DigestValue>base64 digest value</DigestValue> </CertDigest> <xad:IssuerSerial> <xad:X509IssuerName>X.509 distinguished name of certificate</X509IssuerName> <xad:X509SerialNumber>certificate serial number</X509SerialNumber> </IssuerSerial> </Cert>

  26. Document Digital SignatureXDS Sample Code <xad:Cert> <!-- identifier of signing certificate’s parent --> <xad:CertDigest> <xad:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <xad:DigestValue>base64 digest value</DigestValue> </CertDigest> <xad:IssuerSerial> <xad:X509IssuerName>X.509 distinguished name of parent’s certificate</X509IssuerName> <xad:X509SerialNumber>certificate serial number </X509SerialNumber> </IssuerSerial> </Cert> </SigningCertificate> <xad:SignaturePolicyIdentifier>id</SignaturePolicyIdentifier> </SignedSIgnatureProperties> </SignedProperties> </QualifyingProperties>

  27. Document Digital SignatureXDS Sample Code <SignatureProperties> <SignatureProperty Id="purposeOfSignature" target=”signatureOID” > code</SignatureProperty> </SignatureProperties> <Manifest Id="IHEManifest"> <Reference URI=”ihexds:registry:xxxx-xxxx….”> <!-- document A--> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>base64DigestValue</DigestValue> </Reference> <Reference URI=”ihexds:registry:xxxx-xxxx….”> <!—XML document B--> <Transforms> <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>base64DigestValue</DigestValue> </Reference> <Reference URI=”ihexds:registry:xxxx-xxxx….”> <!--DICOM document (or object) C--> <Transforms> <Transform Algorithm="urn:oid:1.2.840.10008.1.2.1"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>base64DigestValue</DigestValue> </DigestMethod </Reference> </Manifest> </Object> </Signature>

  28. Basic Patient Privacy Consents IHE Vendors Workshop 2006 IHE IT Infrastructure Education John Moehrke

  29. Basic Patient Privacy Consents • Small number of pre-coordinated Affinity Domain Privacy Consent • Patient can choose which ones to agree to • Data is classified as published under the authority of a specific Privacy Consent • Data is used in conformance with original Privacy Consent • Applicable for XD* transport mechanism

  30. Capturing the Patient Consent act • One of the Affinity Domain Consent policies are used • CDA document captures the act of signing • Effective time (Start and Sunset) • XDS-SD – Capture of wet signature from paper • DSIG – Digital Signature (Patient, Guardian, Clerk, System) • XDS Metadata • templateId – BPPC document • eventCodeList – the list of the identifiers of the AF policies • confidentialityCode – could mark this document as sensitive

  31. Marking all XDS Documents • Use XDS Metadata – confidentialityCode • List of appropriate consents • Consents enumerated at Affinity Domain (OID) • Rules are programmed into each system participating in Affinity Domain XDS • Registry rejects non-conformant confidentialityCodes Now have a well formed vocabulary

  32. Using documents • XDS Query • *** Consumer requests specific values • Result includes confidentiality codes • XDS Consumer • Knows the user, patient, setting, intention, urgency, etc. • Enforces Access Controls (RBAC) according to confidentiality codes • No access given to documents marked with unknown confidentiality codes

  33. Example : XDS and Security

  34. XDS Security Use-Cases • Supported Today • Prevent Indiscriminate attacks (worms) • Normal Patient that accepts XDS participation • Patient asks for Accounting of Disclosures • Protect against malicious neighbor doctor • Patient that retracts consent to publish • Provider Privacy • Malicious Data Mining • Not directly supported with IHE technology (applications can provide this functionality in their feature e.g. Portals) • Access to Emergency data set  all XDS open, or no access • VIP  Don’t publish, or use special domain • Domestic violence patient  Don’t publish any • Daughter with sensitive tests  Don’t publish, or use special domain • Sensitive topics  Don’t publish, or use special domain • Legal Guardian (cooperative)  Local enforcement • Care Giver (assists w/ care)  Local enforcement

  35. Current XDS Security Profiles • Affinity Domain Policy (singular) • All ‘actors’ that participate must agree to enforce these policies • XDS • Patient Centric Queries  Queries result in ONE patient exposed • ATNA • Confidentiality, Integrity, Accountability • Accountability distributed • Access controls at point of care (sensitive to context) • Digital Signature Content Profile (DSIG) • Enhanced locally by • EUA • PWP • Basic Patient Privacy Consent (BPPC)

  36. IHE Security Profiles - WIP • XUA Cross Enterprise Authentication • Federated identity management • SAML 2.0 • Wait for maturity • Access Control Mechanism • RBAC

  37. XDS Security model Registry Repository A Repository B PIX Service EHR- Workstation Browser EHR System PHR Portal PDQ Service XDS Consumer ATNA Service Identity Svc User Authentication User Interface Business Logic Policy Enforcement RBAC Svc

  38. EHR System Physician Office XDS Document Repository XDSDocument Repository ATNA Audit record repository CT Time server ATNA Audit record repository XDS Affinity Domain (NHIN sub-network) XDS Security Transactions PMS ED Application XDS Document Registry PACS Query Document Register Document EHR System PACS Retrieve Document Provide & Register Docs Maintain Time Lab Info. System Maintain Time Teaching Hospital Maintain Time Community Clinic

  39. EHR System Physician Office XDS Document Repository XDSDocument Repository ATNA Audit record repository CT Time server ATNA Audit record repository ATNA Audit record repository XDS Affinity Domain (NHIN sub-network) XDS Security Transactions Teaching Hospital State run RHIO PMS ED Application XDS Document Registry PACS Query Document Register Document EHR System PACS Retrieve Document Provide & Register Docs Maintain Time Lab Info. System Maintain Time Maintain Time Community Clinic

  40. Thank you

More Related