Next Generation Standards Based RHIO Security Infrastructure

Next Generation Standards Based RHIO Security

InfrastructureMS-HUG Tech Forum

HiMSS 2006

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

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)




devices integrated








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)




devices integrated








• 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



– WSE defined




• Q&A

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

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

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

Microsoft

Nokia

Nortel

Oracle

RSA Security

Sarvega

SeeBeyond

Sun Microsystems

Systinet

TIBCO Software

US Navy

Verisign

(and more)

• Participants

WS-* Specifications

XMLXml Namespaces Infoset

MessagingSOAP 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-PolicyAttachment

http://msdn.microsoft.com/webservices/webservices/understanding/specs/

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

WSE 3.0 Coverage of WS-*

XMLXml Namespaces Infoset

MessagingSOAP 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-PolicyAttachment

WSE 3.0 .Net Framework Will be in Indigo

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)

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



– WSE defined




• Q&A

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

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

Top-level Architecture

Blinded Record Index (BRI)

Site B

Adapter

Site C

Adapter

Site A

Adapter

… …

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

Design Process

• Define trust boundaries• Model threats• Design security solution

– Identify an authentication mechanism– Implement security policies– Additional security measures

• Verify threat coverage

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

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

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

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

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

Top-level Architecture Revised


Site B

Adapter

Site C

Adapter

Site A

Adapter

… …

Security Token Service (STS)

Communication ScenariosSite sending data to BRI


Site A

Adapter


Site B

Adapter

1

2

3

Site A requests a security tokenand signs the message

STS verifies the signatureand issues the security token

Site A sends a message to BRIsigned with Site A’s cert andencrypted with BRI’s.

12

3

Communication Scenarios


Site A

Adapter

Site B

Adapter


1

2

3

1

2

3

BRI requests a security tokenand signs the message


BRI sends a message to Site Asigned with BRI’s cert andencrypted with Site A’s.

Site receiving data from BRI



Site A

Adapter

Site B

Adapter


12

3

1

2

3

Site A requests a security tokenand signs the message


Site A sends a message to Site Bsigned with A’s cert and encryptedwith B’s.

Sites requesting data from each other



3

MicrosoftCertificateServices

2

1

1

2

3

Administrator provides newsite information

STS generates a key pair andsigns a certificate for the new site

Administrator securely transfersthe private key and certificate tothe new site

Administrator

New site coming online

Security Checklist




X.509 Signing & Encryption

WSE & .Net Framework

WSE custom assertion

Custom implementation

Not addressed

HostSystem

Adapter

Internal Network

Adapter Architecture

LocalDataService Clinical

DataServiceData

TransferService

IndexService

Perimeter Service Router

Audit DB

LocalIndex

Internal Network

Communication ScenariosExternal Communication

Perimeter Service Router

Audit DB

1

2

DataTransferService

IndexService

1 BRI has sends index informationto the Adapter

2 The Service Router authenticatesthe request and forwards it

Communication ScenariosService-to-Service Communication

1 Send message signed byservice account withWindows AuthenticationInternal Network

LocalDataService Clinical

DataServiceData

TransferService

IndexService

LocalIndex

1

Security Checklist




X.509 Signing & Encryption

WSE & .Net Framework

WSE custom assertion

Custom implementation

Not addressed

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 termviability of the solution



– WSE defined




• Q&A

Documents

Next Generation Standards Based RHIO Security Infrastructure