Your SlideShare is downloading. ×
Next Generation Standards Based RHIO Security Infrastructure
Next Generation Standards Based RHIO Security Infrastructure
Next Generation Standards Based RHIO Security Infrastructure
Next Generation Standards Based RHIO Security Infrastructure
Next Generation Standards Based RHIO Security Infrastructure
Next Generation Standards Based RHIO Security Infrastructure
Next Generation Standards Based RHIO Security Infrastructure
Next Generation Standards Based RHIO Security Infrastructure
Next Generation Standards Based RHIO Security Infrastructure
Next Generation Standards Based RHIO Security Infrastructure
Next Generation Standards Based RHIO Security Infrastructure
Next Generation Standards Based RHIO Security Infrastructure
Next Generation Standards Based RHIO Security Infrastructure
Next Generation Standards Based RHIO Security Infrastructure
Next Generation Standards Based RHIO Security Infrastructure
Next Generation Standards Based RHIO Security Infrastructure
Next Generation Standards Based RHIO Security Infrastructure
Next Generation Standards Based RHIO Security Infrastructure
Next Generation Standards Based RHIO Security Infrastructure
Next Generation Standards Based RHIO Security Infrastructure
Next Generation Standards Based RHIO Security Infrastructure
Next Generation Standards Based RHIO Security Infrastructure
Next Generation Standards Based RHIO Security Infrastructure
Next Generation Standards Based RHIO Security Infrastructure
Next Generation Standards Based RHIO Security Infrastructure
Next Generation Standards Based RHIO Security Infrastructure
Next Generation Standards Based RHIO Security Infrastructure
Next Generation Standards Based RHIO Security Infrastructure
Next Generation Standards Based RHIO Security Infrastructure
Next Generation Standards Based RHIO Security Infrastructure
Next Generation Standards Based RHIO Security Infrastructure
Next Generation Standards Based RHIO Security Infrastructure
Next Generation Standards Based RHIO Security Infrastructure
Next Generation Standards Based RHIO Security Infrastructure
Next Generation Standards Based RHIO Security Infrastructure
Next Generation Standards Based RHIO Security Infrastructure
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Next Generation Standards Based RHIO Security Infrastructure

299

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
299
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Next Generation Standards Based RHIO Security Infrastructure
      • MS-HUG Tech Forum
      • HiMSS 2006
  • 2. Agenda
    • Statement of the Problem
    • Solution Defined – Intro to Web Service Enhancements (WSE )
      • The WS-* specifications
      • WSE defined
      • WSE’s implementation of WS-*
      • Where does WSE Fit in the MS stack
    • Solution Implementation: Case Study using WSE
      • Goals & Requirements Defined
      • Overall Architecture
      • Security Concerns & Design Process
      • Communication Use Case scenarios
    • Q&A
  • 3.
    • Saint Francis Heart Hospital
    • New Cardiac Care Acute Care Facility - 2004
    • All Digital
      • External paper scanned
      • Internal : bedside EMR
      • CPOE, Med Management
      • PACS for images, Bedside devices integrated
    • Comprehensive rollout (OR, ICU, ED, Gen Floors)
    • Inpatient solution from Vendor A (GE Healthcare)
    • Cardiology Of Tulsa
    • 30 Year old established cardiology group with 20 cardiologists
    • All Digital
      • Physician H&P
      • Nurse/Tech Notes
      • Dx Studies
    • Comprehensive rollout within ambulatory Care
    • Ambulatory Care solution from Vendor B (NexGen)
  • 4.
    • Saint Francis Heart Hospital
    • New Cardiac Care Acute Care Facility - 2004
    • All Digital
      • External paper scanned
      • Internal : bedside EMR
      • CPOE, Med Management
      • PACS for images, Bedside devices integrated
    • Comprehensive rollout (OR, ICU, ED, Gen Floors)
    • Inpatient solution from Vendor A (GE Healthcare)
    • Cardiology Of Tulsa
    • 30 Year old established cardiology group with 20 cardiologists
    • All Digital
      • Physician H&P
      • Nurse/Tech Notes
      • Dx Studies
    • Comprehensive rollout within ambulatory Care
    • Ambulatory Care solution from Vendor B (NexGen)
    • Two Digital Islands with Humans Serving as Bridge
      • >50% of admissions at SFHH come from COT
      • Ambulatory EMR printouts scanned into Inpatient EMR for every patient !
      • No data continuity
      • Human intervention for each encounter
      • Expensive and error prone
    • We needed a LHIO (local health information org)
  • 5.
    • Saint Francis Heart Hospital
    • New Cardiac Care Acute Care Facility - 2004
    • All Digital
      • External paper scanned
      • Internal : bedside EMR
      • CPOE, Med Management
      • PACS for images, Bedside devices integrated
    • Comprehensive rollout (OR, ICU, ED, Gen Floors)
    • Inpatient solution from Vendor A (GE Healthcare)
    • Cardiology Of Tulsa
    • 30 Year old established cardiology group with 20 cardiologists
    • All Digital
      • Physician H&P
      • Nurse/Tech Notes
      • Dx Studies
    • Comprehensive rollout within ambulatory Care
    • Ambulatory Care solution from Vendor B (NexGen)
    • Our LHIO had all the trappings of a RHIO except the organizational, structural, political obstacles to getting started.
      • No common patient identifier
      • No common technology platform
      • No common lexicon/dictionary
    • Still had to contend with all privacy, confidentiality issues
      • Distinct legal entities
      • Need to know basis for information sharing – JIT (just in time)
    • Wanted to insure that technology infrastructure used in our LHIO scaled to the region
      • Federated architecture
      • Sophisticated algorithm for patient matching
      • Security/authentication infrastructure
      • Use the web for communication infrastructure
  • 6. Agenda
    • Statement of the Problem
    • Solution Defined – Intro to Web Service Enhancements (WSE )
      • The WS-* specifications
      • WSE defined
      • WSE’s implementation of WS-*
      • Where does WSE Fit in the MS stack
    • Solution Implementation: Case Study using WSE
      • Goals & Requirements Defined
      • Overall Architecture
      • Security Concerns & Design Process
      • Communication Use Case scenarios
    • Q&A
  • 7. Evolution of Distributed Systems
    • Web Services
    • Open, Industry-Wide Standards
    • Service-Oriented
    • Designed for Hostile Networks
    • Standardized Xml Wire Protocols
    • Web-Services with WS-* protocol stack is the gold standard
    • Component Architectures
    • Closed/Proprietary Standards
    • Object-Oriented
    • Ill-Suited for Hostile Networks (i.e., Internet)
    • Standardized Binary Wire Protocols
    • Examples
      • DCOM
      • .NET Remoting
      • CORBA
      • Java RMI
    • Socket Messaging
    • Ad-hoc application-level protocols
    • Message-Oriented
    • Usually required private networks
    • Custom Wire Protocols
    • Examples
      • HL7
    TIME
  • 8. The WS-* Specifications
    • Defined
      • A collection of standards that provide for secure, transacted, distributed messaging by extending the Simple Object Access Protocol (SOAP)
    • Why they’re needed
      • It’s a standard way for servers running different operating systems to communicate with one another between institutions over potentially hostile networks (like the internet)
    • Development
      • The standards body OASIS coordinates specification releases
      • Maturity
        • First revisions released in 2002-2003
        • Second revisions in 2004-2005
    • Participants
    Microsoft Nokia Nortel Oracle RSA Security Sarvega SeeBeyond Sun Microsystems Systinet TIBCO Software US Navy Verisign (and more) Actional Adobe Systems AmberPoint Argonne National Laboratory BEA Systems BMC Software Computer Associates ContentGuard Cybertrust Cyclone Commerce Datapower EMC Forum Systems Fujitsu GeoTrust Hewlett-Packard Hitachi IBM Lockheed Martin
  • 9. WS-* Specifications http://msdn.microsoft.com/webservices/webservices/understanding/specs/ XML Xml Namespaces Infoset Messaging SOAP WS-Addressing MTOM Security WS-Security WS-SecurityPolicy WS-SecureConversation WS-Security-Kerberos WS-Trust WS-Federation Reliable Messaging WS- Reliable Messaging WS-RM Policy Transactions WS- Coordination WS-Atomic Transaction WS-Business Activity Metadata XML Schema WSDL WS-Policy WS-Policy Assertions WS-Policy Attachment
  • 10. WSE Defined
    • Microsoft Web Service Enhancements
      • A secure, distributed messaging framework that implements a subset of the WS-* standards
      • Extends existing web service .Net libraries (System.Web.Services)
    • MS has boiled down very broad and inclusive WS-* standards into more concrete implementation choices
  • 11. WSE 3.0 Coverage of WS-* XML Xml Namespaces Infoset Messaging SOAP WS-Addressing MTOM Security WS-Security WS-SecurityPolicy WS-SecureConversation WS-Security-Kerberos WS-Trust WS-Federation Reliable Messaging WS- Reliable Messaging WS-RM Policy Transactions WS- Coordination WS-Atomic Transaction WS-Business Activity Metadata XML Schema WSDL WS-Policy WS-Policy Assertions WS-Policy Attachment WSE 3.0 .Net Framework Will be in Indigo
  • 12. WSE’s Place in the MS Stack
    • Development
      • Designed for .NET
        • C#
        • VB.Net
        • Managed C++
    • Hosting Environment
      • Use IIS
      • Self-host (using the Windows service controller, for example)
    • Installation
      • WSE Runtime must be installed on each dev/test/production box
    • Future Releases
      • MS says WSE 3.0 is the final version
      • Longhorn will natively include WSE functionality in the Windows Communication Framework (WCF)
  • 13. Interoperability
    • Primary MS Partners for WS-* are IBM and BEA
      • Java will have enterprise-grade, commercial WS-* implementations that will interoperate with WSE/Indigo
        • IBM WebSphere
        • BEA WebLogic
      • Axis is the premiere open-source Web Services provider over Apache
        • Does not support WS-Security et al, yet. Work still ongoing in this area
  • 14. Agenda
    • Statement of the Problem
    • Solution Defined – Intro to Web Service Enhancements (WSE )
      • The WS-* specifications
      • WSE defined
      • WSE’s implementation of WS-*
      • Where does WSE Fit in the MS stack
    • Solution Implementation: Case Study using WSE
      • Goals & Requirements Defined
      • Overall Architecture
      • Security Concerns & Design Process
      • Communication Use Case scenarios
    • Q&A
  • 15. System Goals
    • The architecture should enable RHIOs to seamlessly share information
    • Support heterogeneous environments, many CDRs / EMRs from many vendors
    • Design as a Service Oriented Architecture (SOA) to logically and physically simplify the design
  • 16. System Requirements
    • Clinical data must pass directly from the sending institution to the receiving institution; no middle men
    • Aggregated demographic information must be one-way hashed to limit the index’s value to potential attackers
    • Individual institutions must have the last say regarding data transfer and maintain a local audit
    • It must be easy to add new sites to the network
    • Patients must be able to opt out
    • The system must scale up and down
    • Must operate securely over the internet
  • 17. Top-level Architecture Blinded Record Index (BRI) … … Site B Adapter Site C Adapter Site A Adapter
  • 18. Security Checklist
    • Identity verification
    • Data confidentiality
    • Data origin
    • Message integrity
    • Protect against malformed or malicious messages
    • Shield exceptions from revealing sensitive implementation details
    • Replay protection
    • Generate audit logs
  • 19. Design Process
    • Define trust boundaries
    • Model threats
    • Design security solution
      • Identify an authentication mechanism
      • Implement security policies
      • Additional security measures
    • Verify threat coverage
  • 20. Security Implementation Choices
    • Authentication
      • Direct
        • Windows Authentication
        • Active Directory
        • Custom password file
      • Brokered
        • Kerberos
        • X.509 Public Key Infrastructure (PKI)
        • Security Token Service (STS)
    • Transmission Security
      • Message Level
        • Shared secret
        • Asymmetric encryption
      • Transport Level
        • SSL
        • VPN
          • IPSec
          • PPtP
  • 21. Direct Authentication
    • Benefits
      • Simple
      • Compatible: It’s easy to leverage an existing password store
        • Windows Auth
        • Active Directory
        • Custom password files
    • Liabilities
      • No sessions: proof-of-possession must be sent each time which requires password caching
      • Home-cooked password files must be carefully secured
      • Direct trust: every actor must directly trust the others
      • Scales poorly: May result in many password files, each needing to be updated when a new user is added
  • 22. Kerberos Authentication
    • Benefits
      • Sessions: client need only authenticate once to interact with services many times
      • Single password file
      • Allows for impersonation / delegation
    • Liabilities
      • KDC may be a single point of failure
      • Requires Active Directory
      • Centralized nature makes it inappropriate for many cross-organization scenarios
      • Clocks must be synchronized
  • 23. X.509 Authentication
    • Benefits
      • Supports sessions
      • Broadly accepted: suitable for cross-organization authentication
      • There’s no password file to maintain; certificates are signed once to establish trust
      • May need a CA such as Windows Certificate Services
    • Liabilities
      • Higher one-time setup cost makes it suitable for architectures with relatively fewer actors
      • Must maintain a revocation list: certificate lifetime is a concern
      • Clients must be careful to protect their private key
      • Can be computationally expensive
  • 24. Security Token Service (STS)
    • Benefits
      • Can support cross-organization authentication
      • Most flexible option allows for heterogeneous environments including X.509, Kerberos and custom auth
      • Can enable web service federation
    • Liabilities
      • More work to implement
      • Requires a more thorough understanding of security implications
      • Requires the use of a separate encryption/signing mechanism
  • 25. Top-level Architecture Revised Blinded Record Index (BRI) … … Security Token Service (STS) Site B Adapter Site C Adapter Site A Adapter
  • 26. Communication Scenarios
    • Site sending data to BRI
    Blinded Record Index (BRI) Security Token Service (STS) 1 2 3 Site A requests a security token and signs the message STS verifies the signature and issues the security token Site A sends a message to BRI signed with Site A’s cert and encrypted with BRI’s. 1 2 3 Site A Adapter Site B Adapter
  • 27. Communication Scenarios Blinded Record Index (BRI) Security Token Service (STS) 1 2 3 1 2 3 BRI requests a security token and signs the message STS verifies the signature and issues the security token BRI sends a message to Site A signed with BRI’s cert and encrypted with Site A’s. Site receiving data from BRI Site A Adapter Site B Adapter
  • 28. Communication Scenarios Blinded Record Index (BRI) Security Token Service (STS) 1 2 3 1 2 3 Site A requests a security token and signs the message STS verifies the signature and issues the security token Site A sends a message to Site B signed with A’s cert and encrypted with B’s. Sites requesting data from each other Site A Adapter Site B Adapter
  • 29. Communication Scenarios Security Token Service (STS) 3 1 1 2 3 Administrator provides new site information STS generates a key pair and signs a certificate for the new site Administrator securely transfers the private key and certificate to the new site Administrator New site coming online Microsoft Certificate Services 2
  • 30. Security Checklist
    • Identity verification
    • Data confidentiality
    • Data origin
    • Message integrity
    • Protect against malformed or malicious messages
    • Shield exceptions from revealing sensitive implementation details
    • Replay protection
    • Generate audit logs
     X.509 Signing & Encryption  WSE & .Net Framework  WSE custom assertion  Custom implementation          Not addressed
  • 31. Adapter Architecture Host System Adapter Internal Network Local Data Service Clinical Data Service Data Transfer Service Index Service Perimeter Service Router Audit DB Local Index
  • 32. Communication Scenarios Internal Network External Communication Perimeter Service Router Audit DB 1 2 Data Transfer Service Index Service 1 BRI has sends index information to the Adapter 2 The Service Router authenticates the request and forwards it
  • 33. Communication Scenarios Service-to-Service Communication 1 Send message signed by service account with Windows Authentication Internal Network Local Data Service Clinical Data Service Data Transfer Service Index Service Local Index 1
  • 34. Security Checklist
    • Identity verification
    • Data confidentiality
    • Data origin
    • Message integrity
    • Protect against malformed or malicious messages
    • Shield exceptions from revealing sensitive implementation details
    • Replay protection
    • Generate audit logs
     X.509 Signing & Encryption  WSE & .Net Framework  WSE custom assertion  Custom implementation      Not addressed    
  • 35. In Summary
    • RHIOs require
      • High security
      • Solid interoperability
    • WSE 3.0 offers
      • Powerful libraries to enable complex RHIO scenarios
      • Security features that are flexible and configurable
      • Interoperability that is key to guaranteeing the long term viability of the solution
  • 36. Agenda
    • Statement of the Problem
    • Solution Defined – Intro to Web Service Enhancements (WSE )
      • The WS-* specifications
      • WSE defined
      • WSE’s implementation of WS-*
      • Where does WSE Fit in the MS stack
    • Solution Implementation: Case Study using WSE
      • Goals & Requirements Defined
      • Overall Architecture
      • Security Concerns & Design Process
      • Communication Use Case scenarios
    • Q&A

×