Next Generation Standards Based RHIO Security Infrastructure

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
• WSEs 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
• QA

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 HP
• 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 HP
• 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
• gt50 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 HP
• 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
• WSEs 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
• QA

7
Evolution of Distributed Systems
TIME

• 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

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 theyre needed
• Its 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

9
WS- Specifications
http//msdn.microsoft.com/webservices/webservices/
understanding/specs/
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 intomore concrete implementation
  choices

11
WSE 3.0 Coverage of WS-
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
Messaging SOAP WS-Addressing MTOM
XML Xml Namespaces Infoset
WSE 3.0
.Net Framework
Will be in Indigo
12
WSEs 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
  inthe 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
• WSEs 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
• QA

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 indexs 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)


18
Security Checklist

• Identity verification
• Data confidentiality
• Data origin
• Message integrity
• Protect against malformedor 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

• 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

• Benefits
• Simple
• Compatible Its easy to leverage an existing
  password store
• Windows Auth
• Active Directory
• Custom password files

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

• 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

• Benefits
• Supports sessions
• Broadly accepted suitable for cross-organization
  authentication
• Theres no password file to maintain
  certificates are signed once to establish trust
• May need a CA such as Windows Certificate
  Services

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)


26
Communication Scenarios

• Site sending data to BRI

1
Site A requests a security token and signs the
message
Blinded Record Index (BRI)
Security Token Service (STS)
2
STS verifies the signature and issues the
security token
3
Site A sends a message to BRI signed with Site
As cert and encrypted with BRIs.
2
3
1
27
Communication Scenarios
Site receiving data from BRI
1
BRI requests a security token and signs the
message
1
Blinded Record Index (BRI)
Security Token Service (STS)
2
STS verifies the signature and issues the
security token
2
3
BRI sends a message to Site A signed with BRIs
cert and encrypted with Site As.
3
28
Communication Scenarios
Sites requesting data from each other
1
Site A requests a security token and signs the
message
Blinded Record Index (BRI)
Security Token Service (STS)
2
STS verifies the signature and issues the
security token
3
Site A sends a message to Site B signed with As
cert and encrypted with Bs.
2
1
3
29
Communication Scenarios
New site coming online
1
Administrator provides new site information
Security Token Service (STS)
2
STS generates a key pair and signs a certificate
for the new site
3
Administrator securely transfers the private key
and certificate to the new site
1
3
Administrator
30
Security Checklist
?
?

• Identity verification
• Data confidentiality
• Data origin
• Message integrity
• Protect against malformedor 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
Adapter
Internal Network
Perimeter Service Router
Index Service
Local Data Service
Host System
Clinical Data Service
Local Index
Data Transfer Service
Audit DB
32
Communication Scenarios
External Communication
Internal Network
Perimeter Service Router
1
BRI has sends index information to the Adapter
2
Index Service
2
The Service Router authenticates the request and
forwards it
1
Data Transfer Service
Audit DB
33
Communication Scenarios
Service-to-Service Communication
1
Send message signed by service account
with Windows Authentication
Internal Network
Index Service
Local Data Service
1
Clinical Data Service
Local Index
Data Transfer Service
34
Security Checklist
?
?

• Identity verification
• Data confidentiality
• Data origin
• Message integrity
• Protect against malformedor 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 toguaranteeing the
  long termviability of the solution

36
Agenda

• Statement of the Problem
• Solution Defined Intro to Web Service
  Enhancements (WSE)
• The WS- specifications
• WSE defined
• WSEs 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
• QA