HIMSS_Internet2 Healthcare Workgroup Federated Identity Management Business Case Toolkit by cheris32

VIEWS: 301 PAGES: 35

									HIMSS/Internet2 Healthcare Workgroup Federated Identity Management Business Case Toolkit July 2007

Copyright 2007 by the Healthcare Information and Management Systems Society (HIMSS).

1

Table of Contents
Purpose............................................................................................................................... 5 Source................................................................................................................................. 5 Introduction....................................................................................................................... 5 Intended Audience .......................................................................................................... 6 Business Case Writer .................................................................................................. 6 Healthcare Executive .................................................................................................. 7 Security Architect ....................................................................................................... 7 HIPAA Compliance Officer ....................................................................................... 8 Organization of the Federated Identity Business Case Approach .................................. 8 Defining the Business Problem ........................................................................................ 8 Example Problem Statements ......................................................................................... 9 As-is Assessment................................................................................................................ 9 Common Organizational Pain Points............................................................................ 10 Common Business Trends in Identity Management..................................................... 11 Regulatory Compliance ............................................................................................ 11 User Diversity ........................................................................................................... 11 Constant Change ....................................................................................................... 11 Scalability ................................................................................................................. 11 Faster Provisioning ................................................................................................... 11 Common Solution Frameworks..................................................................................... 12 Basics of Federated Identity.......................................................................................... 13 Solution Set................................................................................................................... 14 Enterprise Directory Services ................................................................................... 14 Access Management and Control ............................................................................. 15 Enrollment, Identity Proofing and Vetting ............................................................... 15 Single Sign-On.......................................................................................................... 15 Enterprise Public Key Infrastructure (PKI) .............................................................. 16 Trust Model............................................................................................................... 16 Physical Federated Identity Requirements................................................................ 17 External Federated Identity Requirements................................................................ 17 Federated Identity Standards..................................................................................... 18 Strengths of Federated Identity..................................................................................... 19 Access Control .......................................................................................................... 19 Regulatory and Legal................................................................................................ 20 Privacy ...................................................................................................................... 22 Personalization.......................................................................................................... 22 Sharing of Domain Attributes................................................................................... 23 Provisioning .............................................................................................................. 23 Audit and Reporting.................................................................................................. 23 Identity Mapping Services ........................................................................................ 23 Weaknesses of Federated Identity ................................................................................ 23 Privacy Conflicts....................................................................................................... 24 Information Tracing .................................................................................................. 24 Concentrated Points of Failure.................................................................................. 24 Copyright 2007 by the Healthcare Information and Management Systems Society (HIMSS).

2

Architecture............................................................................................................... 24 Cross Enterprise and Inter-organizational Federation Issues.................................... 24 Structuring the Business Case to Perceived Threats ................................................... 24 Federated Identity Considerations ................................................................................ 25 Availability ............................................................................................................... 25 Hardened Servers and Services................................................................................. 25 Design for Failure ..................................................................................................... 25 Incident Response ..................................................................................................... 25 Usability.................................................................................................................... 26 Assurance.................................................................................................................. 26 Benefits of Federated Identity........................................................................................ 26 Mapping the Solution ..................................................................................................... 28 Business Case Writing Approach .................................................................................. 29 Final Checklist of Business Case.................................................................................. 29 Delivery Checklist ........................................................................................................ 30 References........................................................................................................................ 32 Credits.............................................................................................................................. 33

Copyright 2007 by the Healthcare Information and Management Systems Society (HIMSS).

3

Table of Figures
Figure 1: Complexity of Identity Management .................................................................. 7 Figure 2: Organizational Pain Points for Identity Management ....................................... 10 Figure 3: Basic Identity Management Solution Framework............................................. 12 Figure 4: Detailed Federated Identity Framework............................................................ 13 Figure 5: Basics of Federated Identity .............................................................................. 14 Figure 6: Provisioning Process ......................................................................................... 15 Figure 7: Single Sign-On Process ..................................................................................... 16 Figure 8: Policy Development Workflow......................................................................... 17 Figure 9: Federated Identity Standards ............................................................................. 18 Figure 10: caBIG Federated Identity ................................................................................ 20 Figure 11: HIPAA Requirements and Federated Identity................................................. 21 Figure 12: Federated Identity Architecture Stack............................................................. 27 Figure 13: Tangible Benefits of Federated Identity.......................................................... 27 Figure 14: Non-Tangible Benefits of Federated Identity.................................................. 28 Figure 15: Federated Identity Implementation Roadmap ................................................. 28 Figure 16: Final Touch Points to Review in the Business Case ....................................... 29 Figure 17: Final Business Case Deliverables.................................................................... 30

Copyright 2007 by the Healthcare Information and Management Systems Society (HIMSS).

4

Purpose
The HIMSS Federated Identity Management Business Case Toolkit serves as a resource for individuals and entities interested in writing a business case for the use of federated identity in healthcare. Federation identity bridges segregated silos of identity systems to provide healthcare organizations with an ability to secure their cross-boundary interactions. The toolkit provides structure and guided content for stakeholders who need or desire to present a business case for the use of federated identity and access management tools within the healthcare space. Achieving information sharing objectives requires that healthcare partners establish widescale electronic trust among the caretakers of critical information and those who need and are authorized to use that information. Personal protected health information (PHI) is sensitive, and inappropriate sharing of PHI is just as dangerous as lack of sharing. Federated identity allows a user’s roles, rights, and privileges to be communicated securely throughout the healthcare community and, in particular, to those who require this information in order to provide effective care to their patient community. This guide evaluates federated identity from the healthcare perspective, outlines some of the strengths and weaknesses of federated identity, and proposes a set of structured parts that form the foundation of a good business case for a federated identity solution in healthcare.

Source
This document is a publication of the HIMSS/Internet2 Healthcare Identity and Access Management Work Group, whose mission is to examine, review and facilitate the understanding and practical application of Identity and Access Management as a means to address issues of privacy, security, and secure controlled access to protected resources across all the health domains in advanced and traditional networked environments. Nothing in this toolkit should be construed to represent that HIMSS or this Work Group is warranting the success of any particular identity and access management business case, or warranting that the organization’s experience in building federated identity management solutions will be sufficient. This toolkit is also not intended to serve as a comprehensive reference guide for all subjects related to federated identity.

Introduction
Every business case begins with an introductory section, which provides information to the target audience concerning the purpose of the material they are about to read, the methodology or approach taken, and conclusions reached. For federated identity management business cases, the introduction should focus on the specific target audience for the federated identity solution. The toolkit focuses both on stakeholders for this toolkit and stakeholders for federated identity.

Copyright 2007 by the Healthcare Information and Management Systems Society (HIMSS).

5

Intended Audience The primary audience for a federated identity business case document is any stakeholder who is interested in developing a federated identity solution within their healthcare organization. The toolkit is intended to address the potential questions and needs of the following stakeholders within both the process of procuring a federated identity solution, and those stakeholders who may use that solution, or who may be considering the implementation of a federated identity solution within their organization. Business Case Writer The business case writer, who in many cases represents the overall investment planner within the capital planning process, must know exactly what federated identity benefits to focus on specific to the healthcare organization which may require the solution or some subset of it. Identity federation, which represents another term for federated identity, bridges segregated silos of identity systems to provide healthcare organizations with an ability to secure their cross-boundary interactions—removing friction, improving productivity, efficiency and competitive differentiation. Identity Federation enables: 1. A way to more tightly integrate user access to remote resources—across the Internet 2. A method for creating a better end-user experience through Web single sign-on and dynamic new account provisioning. 3. A means for reducing cost and time required to integrate new applications. 4. A means of removing costly and non-scalable proprietary or home-grown Single Sign-On Authentication method for reducing friction in online interactions. 5. A method of securing and auditing transactions. Much has been made of the “multi-protocol” landscape of federation, and many initiatives begin by getting bogged down in the quagmire of solving the multi-protocol problem. The most important note for the business case writer is to specifically focus on a use case related to federated identity. The writer should develop “business-oriented” security use cases to represent healthcare processes. Many early adopters of federation technology underestimated the need for legal considerations in externally facing use cases. If an initiative involves a domain that is external to a healthcare organization, the business case should have technology and use case evaluations with similar business framework and liability discussions.

Copyright 2007 by the Healthcare Information and Management Systems Society (HIMSS).

6

Healthcare Executive The primary purpose in outlining a strong business case for healthcare executives is to ensure that the appropriate return on investment is recognized for federated identity projects. Not all federated identity use cases or scenarios are ideal for the healthcare space. As outlined below in Figure 1, there is a varying degree of complexity to each federated identity use case.
Figure 1: Complexity of Identity Management

A federated identity management system can safeguard a healthcare consumer’s digital identity against identity theft without jeopardizing usability advantages for organizations. Additionally, a federated identity management system can provide mechanisms to secure the identity from inadvertent disclosure or usage within the overall identity federation. As gaining access to distributed resources becomes increasingly vital, the ability to manage identity effectively (between boundaries) becomes a critical requirement for healthcare organizations. However, it is important to not oversell the risks of increased access that federated identity affords. These weaknesses, as well as additional security considerations specific to healthcare executives, are highlighted later in the toolkit document. Security Architect By outlining various federated identity solution frameworks that have been used by previous healthcare institutions, security architects are able to work with IT investment planners, enterprise architects, and vendors to craft a solution that best meets the needs of a particular healthcare organization, while at the same time ensuring that the solution meets the needs of the identified target community (patients). Fundamentally, federated identity management should be architected as loosely coupled. Relying parties should not need prior knowledge of the internal details of each other’s IT systems, or pair-wise mappings to manage or use identity information. Instead, identity federation standards should define rules that bind autonomous identity domains to a

Copyright 2007 by the Healthcare Information and Management Systems Society

7

common method of exchanging identity information with one another. This is an important piece of the overall federated identity business case. HIPAA Compliance Officer, Privacy & Security Officers and Others One of the strengths of federated identity can also be its weakness; the ability to aggregate security data across a wide range of potential domains increases data sharing capability but also increases the possible threat of patient data being compromised. When developing any potential federated identity business case in healthcare, it is extremely important to focus on the importance of patient rights and to ensure that any proposed business case (and derived business requirements) meets the mandates and regulations of the Health Insurance Portability and Accountability Act (HIPAA). Organization of the Federated Identity Business Case Approach This document is structured around several main areas relevant to building a federated identity business case. These are: 1. 2. 3. 4. 5. 6. The Business Problem As-is Assessment Common Solution Frameworks SWOT Analysis of Federated Identity Business Case Writing Approach Completed Business Case Deliverables

Defining the Business Problem
Healthcare entities need and are seeking to have more interconnected relationships with their partners and patients. Boundaries that traditionally defined the perimeter or trust of the healthcare enterprise are shifting and becoming more porous. As healthcare institutions increasingly move to expose their business processes and data to external third party organizations, the security concerns of ensuring that clients for that data, such as personal health records (PHRs) and electronic health records (EHRs), are properly authenticated and authorized is becoming a greater concern. The business context of identity management can be used to focus on the three critical business problems currently inherent in identity management within organizations, and how federated identity fixes these issues. • Identity management costs can be lowered because companies are no longer in the business of managing users or identities that are not under their control, including the delegate administrator identities currently managed by many first-generation federation attempts. Businesses need to manage access to data but do not have to manage accounts and user account data. User experience can be improved because users can navigate easily between Web sites while maintaining a global login identity. Inter-enterprise application integration within federations benefit from the end-toend security and trust capabilities.

• •

Copyright 2007 by the Healthcare Information and Management Systems Society

8

Example Problem Statements The following represent example problem statements that form the genesis of how the business case is developed for federated identity. To establish context as it applies to federated identity, this section defines authentication and authorization scenarios that serve as an evaluation baseline for applicable federated identity solutions: • A Regional Health Information Organization (RHIO) needs to integrate credentials from participating healthcare organizations, each with unique validation and credentialing policies. A RHIO requires a flexible and scalable distributed authorization mechanism to accommodate different authorization policies from participating healthcare organizations. Public information is available to all users of a health information exchange (HIE) and private information requires appropriate access control. A research facility assigns users roles based upon a hierarchical organizational structure. A university hospital needs to know who has read and write privileges on a weekly basis. A hospital manager from Organization A has read and write privileges. Organization A managers can delegate read and write privileges to Organization B members. Qualified users can only use an EHR at certain times of the day (normal business hours).

•

• • • •

•

As-is Assessment
The initial assessment of the baseline identity management environment is critical to formulating a compelling business case for federated identity. The following business drivers for federated identity technologies are promoting early adopter deployment: • • • • • Improved user experience Simplified administration and cost savings Risk transfer or regulatory compliance Opportunities for competitive advantage Improved service

Each of these drivers requires specific as-is assessment of where an organization currently is before focus is turned to implementing federated identity management. The as-is assessment takes into account what the current status of the organization is in terms of aligning its current systems to its identity management business drivers. This allows Copyright 2007 by the Healthcare Information and Management Systems Society 9

the business case to be structured to best provide a solution that highlights specific drivers and strategic goals. Common Organizational Pain Points This list of potential pain points shown in Figure 2 below provides some insight into the factors that will impact the federated identity business case. A complete business case for federated identity solutions within the healthcare space needs to address each area in sufficient detail to demonstrate recognition of the importance and relevance of each of these pain points. Below is a list that seeks to identify common issues experienced in many healthcare institutions, which can drive organizations to consider federated identity as a possible solution.
Figure 2: Organizational Pain Points for Identity Management

Pain Point Inefficient multiple logins with different usernames and passwords. Increased maintenance requirements individual security concerns. Support requirements for stronger levels of authentication. Lack of common strategy regarding directories used by disparately located business units. Administration of multiple users becoming harder to manage. Timely manual processes for security administration of applications. Password resets for user accounts across applications, which generate a large part of help desk volume. Access request process of user accounts is inefficient and inconsistent between business units. Role-based access controls are not commonly used in applications across the organization. User information not always up-to-date. Decentralized security, and inconsistent policies and baseline leading to greater concern for risk exposure.

Copyright 2007 by the Healthcare Information and Management Systems Society

10

Common Business Trends in Identity Management Regulatory Compliance Due to legislative initiatives such as Sarbanes-Oxley, Gramm-Leach-Bliley, HIPAA, the European Union (EU) Directive on Data Protection, and others, information security is now a nonnegotiable mandate carrying stiff fines and even prison terms for noncompliance. Protecting the privacy of patients as well as their sensitive personal information requires strict, process-driven management of IT application access to ensure that only those who have “need-to know” access rights get to the information. Also as important is being able to report and audit access privileges and activity as needed. Many healthcare enterprises are trying to become compliant with manual and less efficient processes in order to ensure control. User Diversity Health IT systems are being accessed by more and different types of users who require varying levels of access to different applications. They can belong to large practices, or they could be providers with unique access requirements. They could be stakeholders requiring long-term access to data, or they could be auditors or compliance officers needing access to data for an audit. The temptation in any security solution business case is to apply a one-size-fits-all rule and group users into two or three broad categories, giving virtual carte blanche access to all but a few employees. It is fast, simple, inexpensive — and highly insecure. Federated identity inherently tries to solve this issue. Constant Change Healthcare provider relationships change constantly. Providers receive new patients and also require different access privileges. Providers may require access to multiple locations. A health data partner relationship may end and a new relationship may have been established with a different insurer. This dynamic environment creates a steady stream of access privilege and basic identity data changes that must be administered. Scalability Change in the healthcare industry can take place on a larger scale as well. New business models require healthcare providers to different patients on a constant basis, and require additional identity management needs to protect patient data as it is accessed by a number of different providers from different locations. These events can require provisioning thousands of users. Faster Provisioning Healthcare enterprises today typically have fragmented and manual processes for managing the full user lifecycle process, greatly increasing the time it takes to get users up and running productively, to change their access privileges as their roles change, and to instantly and securely revoke their accounts when their relationship with a practice ends.

Copyright 2007 by the Healthcare Information and Management Systems Society

11

Common Solution Frameworks
Figure 3 below highlights a common approach to building a solution for identity management.
Figure 3: Basic Identity Management Solution Framework

Business Events/Triggers

User Provisioning

Authoritative Source

Identity Repository Access Management

Federated identity is generally based on one of three models: point-to-point (one healthcare organization to another), hub and spoke (healthcare organizations sharing information through a common entity) and network (all organizations sharing identity within the federation through a common network). Figure 4 highlights how federated identity differs from basic identity management solutions.

Copyright 2007 by the Healthcare Information and Management Systems Society

12

Figure 4: Detailed Federated Identity Framework

Basics of Federated Identity Most federated identity environments use a standardized XML credential as the key part of federated identity to be used by members and partners of the healthcare community. Using an XML credential allows information to be shared in a new way—with reduced management burden and improved security and on a broader scale. It represents a strategic change and dramatic improvement in the way healthcare organizations establish the electronic trust needed to share information. At the highest level of concept within the federated identity model (shown in Figure 5), there are three vital components that must interact between users of multiple health IT systems:
• • •

Identity Provider (IDP) Service Provider (SP) User Credential Assertions (Metadata)

Copyright 2007 by the Healthcare Information and Management Systems Society

13

Figure 5: Basics of Federated Identity

Within a federation, organizations play one or both of two roles; identity provider and/or service provider. The identity provider is the authoritative entity responsible for authenticating an end user and asserting an identity for that user in a trusted fashion to trusted partners. The identity provider is responsible for account creation, provisioning, password management, and general account management. This may be achieved with existing locally accepted security mechanisms and tools. Federation partners who offer services or share resources are known as service providers. The service provider relies on the identity provider to assert information about a user via an electronic user credential, leaving the service provider to manage access control and dissemination based on a trusted set of user credential assertions. As mentioned above, an organization that is a service provider can also be an identity provider. Solution Set In general, the federated identity management business case revolves around the following core components which, when assembled, form the basis for a federated identity solution. Enterprise Directory Services Enterprise directory services provides for consolidation, synchronization and aggregation of shared identity information for retrieval and user authentication. They are also called provisioning services. As shown in Figure 6, provisioning services are used within a federated environment for both a priori and run-time provisioning solutions. Provisioning services are leveraged to federate local identity management systems across federation business partners and to provide federated management of identity data, including transactional and profile attributes. This is a critical piece of the overall federated identity solution set.

Copyright 2007 by the Healthcare Information and Management Systems Society

14

Figure 6: Provisioning Process

Access Management and Control Access management and control provides standards and policies for accessing facilities and information systems. The access can be either physical or virtual, whether done through a biometric smart card or through an enterprise single sign-on. There are two more specific requirements that are necessary to ensure access control within healthcare federated identities: 1. Authorization based on combinations of identity attributes held by healthcare entities 2. Rules and permissions relating to resources standardized across healthcare organizations Enrollment, Identity Proofing and Vetting This requirement outlines the processes for validating and verifying an individual’s identity for the purpose of establishing credentials, such as log-in identifications and identity cards. Identity federations can accept different credential types including username/password, X.509 certificate, non-X.509 certificates, SAFE hardware token, and smart cards. Participating healthcare organizations can leverage their existing credential infrastructure as their credential to access the identity federation. The credential infrastructure can be an organization’s Certificate Authority, directory services (LDAP), or a 3rd party credential service the organization uses. Single Sign-On Federated single sign-on is the process by which a user authenticates to a federation business partner (such as an identity provider) and has the provider assert a relevant identity (and attributes) to any/all required (and trusted business partner) service providers as part of the user's online federation experience. Figure 7 below outlines how federated single sign-on works.

Copyright 2007 by the Healthcare Information and Management Systems Society

15

Figure 7: Single Sign-On Process

Enterprise Public Key Infrastructure (PKI) PKI outlines the standards for use of secure mechanisms (cryptography) to verify established identities, support digital signatures and encrypt sensitive data. PKI is increasingly being adopted as a relevant industry standard for creating a digital signature environment, which allows for non-repudiation of content and the sharing of information with third parties to authenticate users and entities. Federated identity is different from PKI. On one hand, PKI provides key management services that protect authentication assertions or other messages used in federating identity. And federated identity assertions can be used to bridge authentication between those domains that support PKI and those that do not, or between domains with noninteroperable PKIs. But on the other hand, federated identity does not require that every user and every application support PKI, or that a tightly integrated PKI enabled trust fabric exist worldwide. Trust Model The trust relationship addresses two issues: 1. On what terms should a healthcare domain establish federations with other healthcare partners? 2. How should healthcare domains ensure compliance with federation agreements? Because healthcare organizations share many similar characteristics (HIPAA, FDA 21 CFR Part 11, similar IRB compliance, etc.), healthcare organizations benefit from deploying a central federated identity trust and governance model for applying compliance policies across shared domains. To realize the identity federation, a trust agreement must be created to define proper assurance levels and risks associated with each allowed credential

Copyright 2007 by the Healthcare Information and Management Systems Society

16

Physical Federated Identity Requirements Most of the requirements outlined so far are virtual in nature, and involve the transfer or exchange of logical or conceptual identity. Physical identity presents its own set of additional requirements in regards implementing a potential design and solution. Identity card production, personalization and issuance: This requirement outlines the standards for creating, delivering and activating an individual’s unique identity card. A healthcare organization may have specific, specialized requirements to create and personalize a physical federated identity, especially due to facility requirements that can be quite disparate. Specification for a personal identity verification (PIV) card: This requirement provides the physical and logical layout for the components of the PIV card (e.g., magnetic strip, smart chip, photograph). Many healthcare organizations may choose to select a method that best aligns to the sensitivity of the data within the organization. If the business case requires it, this requirement specifically focuses on physical security controls related to healthcare facility access. External Federated Identity Requirements Policy development: Policy is critically important in developing an overall identity federation business case. Each organization’s set of policies is made up of many layers of policies. These policies work together in a hierarchic way to interlock and serve the needs of the healthcare organization. Figure 8 highlights the policy flow within a healthcare organization. Policy development is critical to ensuring that federated identity management succeeds, as policy requirements can be more complex and specific when federated identity is used.
Figure 8: Policy Development Workflow

Copyright 2007 by the Healthcare Information and Management Systems Society

17

Policies and procedures: An example of specific policies is listed below. Each of these policies and procedures must be considered as part of the overall business case: 1. Policies for who has access to what type of documents in the healthcare organization. 2. Policies for who is allowed to publish documents within the identity federation. 3. Policies on the acceptable types of documents that can be shared between healthcare entities. 4. Policies on user provisioning and de-provisioning within healthcare entities. 5. Policies on emergency operations. 6. Policies on authentication methods that are acceptable. 7. Policies on backup and recovery planning. 8. Policies on acceptable third party access within the federation. 9. Policies on secondary use of the information by healthcare organizations, and whether this has been consented to. 10. Policies for length of time that information will be maintained within a healthcare information exchange (if this entity is part of the federation). Business agreements and policies to support technology: A successful security implementation requires policies in many layers. For example, policies (e.g., HIPAA, 21 CFR Part 11 compliance, trust agreements), the enabling standards, guidelines, procedures (e.g., identity proofing), and data standards (e.g., authorization attributes) should be developed along with the federated identity solution. All these are not within the initial scope of a business case, but can become much more relevant and important as federated identity management moves forward. Security requirements specific to HIPAA are highlighted later as a strength of federated identity management. Federated Identity Standards Figure 9 highlights each of the standards inherent in a federated identity solution. This is not intended to be all-encompassing, nor is it intended to be used as anything other than a reference when considering the business case for federated identity (with regard to what standards exist and how they may be used).
Figure 9: Federated Identity Standards

Standard Name
SSL/TSL

Description
Secure Sockets Layer (SSL, standardized as Transport Layer Security, TSL) provides session-level security through the use of encryption. Security Assertions Markup Language (SAML) is a specification designed to provide cross-vendor single-sign-on interoperability. SAML has two major components: It describes SAML assertions used to transfer information within a single sign-on protocol and SAML bindings and profiles for a single sign-on protocol.

SAML

Copyright 2007 by the Healthcare Information and Management Systems Society

18

Standard Name
Shibboleth

Description
Shibboleth is related to SAML but is specific to the highereducation sector. Shibboleth uses some of the SAML protocols but includes additional features specific to the higher-education community. Shibboleth introduces the notion of Where are You From? processing, allowing a service provider to implement both push-based and pull-based SSO protocols. The Liberty Identity Framework, ID-FF, describes federation functionality that goes beyond single sign-on. WS-Federation describes how to use the existing Web services security building blocks to provide federation functionality, including trust, single sign-on (and single signoff), and attribute management across a federation. WSFederation is really a family of three specifications: WSFederation, WS-Federation Passive Client, and WSFederation Active Client. The Web Services Trust Language (WS-Trust) uses the secure messaging mechanisms of WS-Security to define additional primitives and extensions for the issuance, exchange and validation of security tokens. WS-Trust also enables the issuance and dissemination of credentials within different trust domains. While WS-Security itself is not a federation or single sign-on specification, it does define the binding of Web services security tokens. This binding is leveraged within the WSFederation profile. WS-Provisioning describes the APIs and schemas necessary to facilitate interoperability between provisioning systems and to allow software vendors to provide provisioning facilities in a consistent way. The specification addresses many of the problems faced by provisioning vendors in their use of existing protocols, commonly based on directory concepts, and confronts the challenges involved in provisioning Web services described using WSDL and XML Schema.

Liberty Alliance WS-Federation

WS-Trust

WS-Security

WS-Provisioning

Strengths of Federated Identity Some of the perceived strengths of federated identity to highlight in a business case include: Access Control Identity is a foundation-level component for many access control mechanisms. Identity information about a digital subject is bound to a principal. Access control mechanisms consume identity data from the principal to make and enforce access control decisions. Weaknesses in identity systems affect the overall viability of access control, security, and privacy mechanisms.

Copyright 2007 by the Healthcare Information and Management Systems Society

19

One of the important strengths of federated identity management within a business case is that federated identity solutions provide more robust access control than regular identity management solutions. In addition, federated identity solutions are especially effective in providing access to larger network grids, which is increasingly the norm with both RHIOs and with the larger National Health Information Network. Figure 10 below outlines the caBIG grid and how federated identity incorporates multiple access control points to provide more robust access.
Figure 10: caBIG Federated Identity

Regulatory and Legal Increasingly legislation and regulation recognize the value of identity data. Countries and industries have specific points that must be addressed to ensure that identity is protected. For applications that have an international user base, there are additional regulatory and legal concerns that may span legal boundaries. Federated identity helps tremendously in meeting regulatory and legal requirements specific to security. Figure 11 outlines requirements specific to HIPAA that federated identify management can support or organization in achieving overall HIPAA compliance. Copyright 2007 by the Healthcare Information and Management Systems Society 20

Figure 11: HIPAA Requirements and Federated Identity

HIPAA Requirement Implement procedures for personnel authorization and/or supervision. Establish termination procedures. Implement policies and procedures for authorizing access. Implement policies and procedures for access establishment and modification. Assign all PHI users a unique identifier. Develop access control policy. Implement access control procedures using selected hardware and software. Review and update user access profile periodically. Establish an emergency access procedure. Provide automatic logoff and encryption and decryption. Terminate access if it is no longer required. Determine activities that will be tracked or audited. Develop and deploy information system activity review/audit policy and appropriate standard operating procedures. Implement the audit/system activity review process. Identify all users who have been authorized to access PHI. Develop the integrity policy, requirements, and implementation procedures. Implement an (electronic) mechanism to authenticate PHI. Establish a monitoring process to assess how the implemented process Is working. Determine authentication applicability to systems/applications. Implement authentication to systems/applications. Develop and implement transmission security policy and procedures. Implement integrity controls. Implement encryption. Ensure that all participants that use PHI

Does Federated Identity Help Meet This Requirement? Yes Yes Outside scope but supportable Outside scope but supportable Yes Outside scope but supportable Yes Yes Yes Yes Yes No Outside scope but supportable

No Yes Outside scope but supportable Yes Yes Yes Yes Outside scope but supportable Yes Yes No 21

Copyright 2007 by the Healthcare Information and Management Systems Society

HIPAA Requirement provide adequate protection to PHI. Ensure that all participants that use PHI report security incidents. Ensure that access to PHI is terminated if the PHI has been breached by the sharing parties. Create and deploy HIPAA security rule compliance policies and procedures. Update documentation of HIPAA security rule compliance policy and procedures. Draft, maintain and update HIPAA Security Rule Documentation (policies, procedures, actions, activities, assessments, or security controls). Maintain the HIPAA Security Rule documentation for at least six years after it is last in force. Assure that documentation is available to those responsible for implementation. Update documentation as required.

Does Federated Identity Help Meet This Requirement? No Yes

Outside scope but supportable Outside scope but supportable Outside scope but supportable

Outside scope but supportable

Outside scope but supportable Outside scope but supportable

Privacy Privacy concerns relate to identity information that is linked at some level to an individual. They center on what personal data is disclosed and may manifest themselves in the system design through privacy legislation, liability, and/or psychological acceptability and success of the solution. Systems may implement privacy mechanisms using pseudonyms or anonymous mechanisms. There is an inherent tension between security and privacy that plays out most directly in the identity space. The tension revolves around the extent to which the user and the relying party have control and visibility of personal data. To be effective, the identity architecture must resolve these concerns in a manner that is congruent with each party’s requirements. Federated identity helps to resolve many of these concerns, and provide mechanisms to address those concerns that are not immediately resolvable (environment-specific areas of healthcare, for example). Personalization Information relating to consumers or patients is used by a wide array of applications from health portals (e.g., health web sites, insurance programs, customer relationship management services, personalization engines, and health content management servers) to enhance the customer and patient experiences and provide convenience and targeted services on behalf of businesses and consumers. Personal data, stored by organizations, may also be shared and correlated for a variety of reasons including data mining and Copyright 2007 by the Healthcare Information and Management Systems Society 22

targeted marketing. These uses of personal data may directly conflict with goals for pseudonymous protection of data subject information. Federated identity supports larger access control over this tremendous amount of data personalization. Sharing of Domain Attributes Information relating to patients may be used in a system for attribution purposes, including provisioning, credentialing, and data and function views based on keys. The health-specific attributes that are related to the patient may be mapped to the identity and used in the domain without the knowledge of the end user, depending on the policies in the domain. The actual brokering of access control functions may be delegated to or impersonated by other system servers and services, as is the case in some distributed system architectures where individual user accounts are impersonated by application servers. Federated identity solutions prevent this from occurring, by centralizing functions through the use of trust models. Provisioning Provisioning services are responsible for managing identity information and assigning rights and privileges in one or more domains. Provisioning services are typically roleand/or rule-based and may have sophisticated workflow, logging, and audit logging capabilities. Provisioning is easier and more robust in federated identity management. Audit and reporting Systems can be used to record, track, and trace identity information throughout systems. Audit logs and usage reports may be used for regulatory, compliance, and security purposes, and depending on implementation they may create privacy issues for individuals. Anonymizing and pseudonymizing sanitizers may be used to allow for system reporting and monitoring without disclosing identity information. Auditing and reporting is robust under federated identity management. Identity Mapping Services In distributed systems, identities are communicated and transformed in a variety of ways. Identity mapping services allow relationships when identity information, such as attributes, is mapped onto other principals. Federated identity strongly supports this identity mapping, increasing the range and scope of identity sharing. When federation occurs, the relying parties need to map user identities into local identities to grant user privileges. Mapping user identities is a complex issue depending mainly on an organization’s policies and regulatory compliance. Weaknesses of Federated Identity Federated identity weaknesses need to be highlighted and mitigated as part of analyzing and writing the business case to requirements. Some of the perceived weaknesses of federated identity to highlight in a business case include the following:

Copyright 2007 by the Healthcare Information and Management Systems Society

23

Privacy Conflicts The convenient portability properties that federation provides can conflict with privacy goals. In some cases the federation protocols set up a panoptic situation that reduces privacy in a multiparty federation. The larger the federation, the more privacy can be compromised. Information Tracing Depending on implementation, personal information can be correlated and traced across domains through logs and other mechanisms. Federation, as its name implies, relies on mutually agreed upon static groups and is not suited to ad hoc groups that want to rely on the same identity data. Concentrated Points of Failure Federation servers create failure points as targets of denial of service and disruption of availability attacks. As with all identity services, federation design decisions need to deal with the balance of security, privacy, and usability. Architecture Identity comprises a number of architectural concerns. Each concern’s elements and constraints can result in architectural tradeoffs against other identity architecture concerns. Project teams map out the constraints and rationale for the identity elements in their system, conducting architectural tradeoff analysis regarding how identity is generated, represented, consumed, and transformed. Cross Enterprise and Inter-organizational Federation Issues There are inherent issues to implementation of an identity federation that go beyond simple technical issues. Inherent weaknesses exist in any deployment of a solution that crosses multiple enterprises or touches on potential organizational conflicts. It is important as part of the business case to analyze the potential effects of implementing a large-scale cross-enterprise solution.

Structuring the Business Case to Perceived Threats
Any time previously segregated elements of an individual’s identity or personal attributes are combined, privacy is threatened. The classic example is one where a healthcare insurance company or potential employer might discover that a person researched AIDS or cancer online, and exploit that knowledge—without permission—to the detriment of the individual. The general rule with federated management and privacy is that the more information about an individual that is available in one place, the greater the risk to that individual’s privacy. It is important to consider all potential areas of consideration within the healthcare space regarding an identity business case, whether federated or not federated. This section highlights some of those additional considerations that security architects, security officers, and healthcare executives may consider.

Copyright 2007 by the Healthcare Information and Management Systems Society

24

Federated Identity Considerations Availability Identity services provide an interface to information about subjects stored in the identity stores within a system. They also can provide a single point of failure that attackers may target to bring application systems down, without the need for the attackers to target the application itself. In fact, since identity services and stores are often reused in organizations serving identity information to multiple applications, an attacker who executes a denial-of-service or other availability attack against identity services and stores can have a large adverse impact on the availability of the system. Failover, replication, dynamic binding, decentralization, and clustering techniques can be used to combat availability threats. All are normally included as part of federated identity products. Hardened Servers and Services Due to the criticality of the data that identity servers host and the access they vouch for in the system, identity servers should be hardened to the highest level of surety that is practical. The goal of identity servers is to provide and verify identity information for applications, not to run Web servers, database servers, and so on. Standard server hardening techniques that limit privileges and services available only to those strictly necessary apply in this instance. Hardening special-purpose identity servers such as directory services servers is a relatively more straightforward task than hardening identity servers that are general purpose tools in the organization and may contain both identity and personal health information. Federated identity makes server and service hardening easier because there are a limited number of attack points to choose from. Design for Failure As a high-priority target for attackers, identity servers and services are likely to be the recipient of the most sophisticated attacks possible. Host integrity monitoring, network and host-based intrusion detection systems, network security monitoring, and secure exception management practices enable more robust detection when protection mechanisms fail. All of these are incorporated into most federated identity products and solutions. Incident Response Many attacks against identity, particularly identity theft, rely in large part on the victim being ignorant that theft has occurred for some period of time. The damage an attacker can cause can be partially mitigated by effective, rapid, and targeted response to identity data theft. An effective program includes clear communication lines and response patterns, along with a set of guidelines that the victimized users can implement to deal with the aftermath of an identity theft. For federated environments, it is especially important to have touch points that a victim can contact if their identity is compromised in another part of the overall identity federation.

Copyright 2007 by the Healthcare Information and Management Systems Society

25

Usability At runtime, the end point for identity data is frequently a user’s computer. Therefore, securing identity often comes back to a battle between usability and security. The work done protecting an identity across dozens of nodes can be defeated by attackers targeting the desktop layer. Robust identity systems must ensure that the usability of identity is factored in so users understand their roles and responsibilities in using their identity in the system. Federated identity has increased robustness because it can be managed from remote locations to control the desktop layer, even against a user’s will. Assurance Identity information is used as a basis for access control decisions and audit purposes. Identity services must be designed so that the confidentiality, integrity, and accountability mechanisms relating to identity information provide assurance that the system will meet its overall specification including protection and detection mechanisms that rely on identity information. Federated identity management provides a high level of assurance.

Benefits of Federated Identity
Federated identity management offers a number of important benefits. The most easily appreciated benefit is the lower user administration costs realized by reducing user management redundancies and the number of help desk calls related to identity. A federated identity management model can allow a healthcare organization to quickly and securely create new relationships with other organizations. A strong emphasis on regulatory compliance has created another compelling driver for federated identity management. Substantial partner/supplier networks and decentralized operations models can add risk for healthcare entities, especially when managing compliance. Figure 12 highlights the overall federated identity technology stack and how the completed information technology investment will look.

Copyright 2007 by the Healthcare Information and Management Systems Society

26

Figure 12: Federated Identity Architecture Stack

Figures 13 and 14 also highlight both the tangible and intangible benefits of implementing federated identity in the healthcare space.
Figure 13: Tangible Benefits of Federated Identity

Tangible Benefits Reducing help desk calls for password resets. Reducing the number of admin staff needed to create/ manage accounts. Reducing the number of user licenses Waiting time for new users to get access to accounts. Automating process of removing people once they leave. Single infrastructure to manage and secure.

Results to Business Owner More efficient use of help desk resources More efficient use of help desk resources Cost savings Increased productivity Increased security Cost savings

Copyright 2007 by the Healthcare Information and Management Systems Society

27

Figure 14: Non-Tangible Benefits of Federated Identity

Non-Tangible Benefits Improved control over secure access to resources. Security audit findings reduced. User experience improved. Centralised administration for audit and control mechanisms. Single view of users and mappings to resources. Number of unused accounts reduced.

Results to Business Owner Easier measurement of performance More efficient use of compliance resources Increased productivity More efficient use of compliance resources More efficient use of compliance resources Increased productivity

Mapping the Solution
The business case for federated identity should clearly denote a roadmap to achieving the overall solution identified. It should incorporate major milestones, and performance measures for those milestones outlined in this document, so that a reviewer can understand the overall iterative process toward building a federated identity solution. Figure 15 outlines a potential roadmap for federated identity solutions in healthcare.
Figure 15: Federated Identity Implementation Roadmap

Copyright 2007 by the Healthcare Information and Management Systems Society

28

Business Case Writing Approach
This section summarizes the finalized set of activities to conduct as part of the formulation of the business case for federated identity. It includes a listing of considerations to evaluate as part of reviewing the completed business case and a set of delivery products to be packaged as part of the business case. Final Checklist of Business Case The checklist shown in Figure 16 outlines some of the considerations that should be made when reviewing the completed business case. These considerations are by no means allencompassing but focus on specific known issues that need to be highlighted and covered within the framework of a federated identity solution.
Figure 16: Final Touch Points to Review in the Business Case

Touch Point Legal

Policy and Regulatory

Risk Analysis

Risk Management

Return on Investment

Business Enablement and Other Benefits

Analysis of Touch Point How the proposal fits within the governance and legal and contractual framework and culture of the organization, as well as the obligations, and terms & conditions of the proposal. The regulatory implications and anticipated impact on the organization of the proposal from a compliance perspective The identification, evaluation, and assessment of risk, and the plan for remediation, mitigation, etc., of those risks. The fit of the proposal within, and impact on, the organization’s programmatic approach to assessing overall risk and providing a risk analysis and mitigation approach that provides balance across the organization. Focusing on the hard-dollar returns expected from implementation of the proposal, including “cost of funds” treatments such as net present value, as well as the expected subjective benefits. New applications, services, etc., that can be made available with the implementation of the proposal, that would not otherwise be feasible. 29

Copyright 2007 by the Healthcare Information and Management Systems Society

Touch Point Strategic Technological Positioning Benefits

Analysis of Touch Point How the implementation of the proposal will best position the organization to achieve it strategic and tactical goals.

Delivery Checklist The business case document, in itself, represents only one document in the overall case to be made for federated identity. In order to address the myriad levels of concern that potential new security solutions can create, it is imperative to build a business case that focuses not just on the business case for federated identity, but captures the specific health-related business requirements unique to the healthcare industry. In addition, a business case should reflect an analysis of both the possible architecture and the possible implementation timeline. Figure 17 highlights some of the specific deliverables of the overall business case process.

Figure 17: Final Business Case Deliverables

Deliverable Project Scope

As-Is Assessment

Business Requirements and Case

Architecture Blueprint

Implementation Plan

Description Summary of the project scope and activities completed. Assessment and inventory of existing products or plans. Business goals/requirements that drive the need for federated identity management solutions. Architecture for the federated identity management solution, including the process, technology, and data implications and high level design specific to the needs of the healthcare business problem. Implementation plan breaking down components of the

Mapping to Toolkit Business Problem

As-Is Assessment

All components of the toolkit

Strengths and Weaknesses

Mapping the Solution

Copyright 2007 by the Healthcare Information and Management Systems Society

30

Deliverable

Description solution into manageable implementation phases, deliver the highest benefits with the easiest integration.

Mapping to Toolkit

The inclusion of an organization name, product or service in this publication should not be construed as a HIMSS endorsement of such organization, product or service, nor is the failure to include an organization name, product or service to be construed as disapproval. The views expressed in this white paper are those of the authors and do not necessarily reflect the views of HIMSS.

Copyright 2007 by the Healthcare Information and Management Systems Society

31

References
SAML 2.0: Convergence Point for Browser based Federation, May 18, 2005, Burton Group. Federating a Distributed World: Asserting Next-Generation Identity Standards, Version: 1.0, Apr 15,, 2005 Burton Group. Liberty Alliance Tutorial, Liberty Alliance Project. Liberty Alliance: Meeting Early Adopter Requirements, Jan 26, 2004, Burton Group. OMB-04-04. Technical Approach for the Authentication Service, the US Government’s EAuthentication. NIST Special Publication 800-63. Electronic Authentication Guideline. NIST Special Publication 800-66. An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule. caBIG Architecture Briefing on Grouper, Signet, and GridShib. Tom Barton, U of Chicago, Keith Hazelton, U of Wisconsin. Managed Authorization Services: Implementing Roles, Rules, and Policies, Version: 1.0, Dec 14, 2004, Burton Group. caBIG Security Technology Evaluation White Paper. January 2006, Booz Allen Hamilton. Burton Group Report on e-Authentication Initiative. August 2004, Burton Group.

Copyright 2007 by the Healthcare Information and Management Systems Society

32

Credits
Eric Pupo has special acknowledgment and appreciation extended for his time, leadership and content contribution in the development of this white paper. Members of the HIMSS Internet2 Work Group, which spearheaded this white paper, as follows:
Soloman I. Appavu, CHPS, CPHIMS, FHIMSS Certification Commission for Healthcare Information Technology Tel: 312-315-1975 Email: soloman277@cs.com Ron Bowron Novell Tel: 214.755.8067 Email: rbowron@novell.com Chris Bidleman Dir. Healthcare Solutions Novell Tel: 714.305.5281 Email: chris.bidleman@novell.com Brad Chilton Division Information Officer, CTO Information Technology & Solutions University Hospitals Health System Tel: 216.983.1950 Email: Brad.Chilton@uhhs.com Barry Dickman Project Lead, Health Mission Area The MITRE Corporation Tel: 703.983.3705 Email: bdickman@mitre.org Lydia Duckworth, CHSSP The MITRE Corporation Tel: 301-429-2241 Email: lduckworth@mitre.org Brian Evans Vice President, Professional Services CynergisTek, Inc Tel: 614.203.3416 Email: brian.evans@cynergistek.com Jill C. Hanses Regional Sales Manager US Biometrics Tel: 866-922-8202 x126 Email: jhanses@usbiometrics.com Paul Jolly, PhD Senior Associate Vice President AAMC Tel: 202 828 0257 voice Email: pjolly@aamc.org

John Christiansen Christiansen IT Law Tel: 206.301.9412 Email: john@christiansenlaw.net

Andreas Dieckow Principal Product Manager Strategic Planning InterSystems Corporation Email: Andreas.Dieckow@intersystems.com Todd Enneking VP Engineering Cleo Communications Tel: 815.282.7655 Email: tenneking@cleo.com Godwin Odia Area Health Information Management Consultant Indian Health Service Tel: 605.226.7237 Email: godwin.odia@na.ihs.gov Keith Hazelton Email: hazelton@doit.wisc.edu

Copyright 2007 by the Healthcare Information and Management Systems Society

33

Jeffery Kerber Email: jkerber3501@kerber-family.net

Joseph A. Konopka IST Director Business Systems and Technologies Phone: (732)743-3341 E-mail: konopkja@umdnj.edu

Steve Kotyk MPI Sales Executive 2513 Branch Oaks Lane Flower Mound, TX 75028 Tel: 972-691-4215 office Email: skotyk@quadramed.com Glen Marshall Standards & Regulations Manager Siemens Tel: 610.219.3938 Email: glen.f.marshall@siemens.com David Miller IT Architect, Technology Services Siemens Tel: 610.219.9845 Email: david.h.miller@siemens.com Steve Olshansky Internet2 Email: steveo@internet2.edu

Kirke Lawton Information Architect Director, Enterprise Data Association of American Medical Colleges Tel: 202-828-0974 Email: klawton@aamc.org Michael McGill (Chair) Internet2 Email: mmcgill@internet2.edu

RL “Bob” Morgan Email: rlmorgan@washington.edu

Pete Palmer Wells Fargo Tel: 612-667-9655 Email: Pete.Palmer@wellsfargo.com Tracy Peabody, RHIA MPI Services Delivery Manager QuadraMed Corporation Tel: 813-205-5428 (cell) Email: TPeabody@quadramed.com Jeff Purslow BPM, Enabling Technologies Danbury Health Systems 84 Locust Danbury, CT 06810 Tel: 203-739-6411 Email: Jeff.Purslow@danhosp.org Christina Stephan University of Minnesota and Liberty Alliance Tel: 913 685 3726 Email: steph220@umn.edu David Szabo Nutter, McClennen & Fish, LLP Tel: 617.439.2642 Email: DSzabo@nutter.com

Morgan Passiment Email: mpassiment@aamc.org

Erik Pupo Vangent Tel: 571-334-8017 cell Email: erik.pupo@vangent.com

Dwight Raum Director Enterprise Services The Johns Hopkins University 5801 Smith Avenue, Baltimore, MD 21209 Tel: 410.735.7358 Email: draum@jhmi.edu Letha E. Stewart, MA, RHIA Software Delivery Manager QuadraMed - MPI Solutions Tel: 817-306-9759 (office) Email: LEStewart@QuadraMed.com

Copyright 2007 by the Healthcare Information and Management Systems Society

34

Joseph R. Thear, Jr. Vice President of Product Management QuadraMed Tel: 703-742-5351 Email: JThear@Quadramed.com Brad Young Chief Technology Officer and Information Security Officer Charleston Area Medical Center Health System Tel: 304.388.7901 Email: brad.young@camc.org Pam Matthews, FHIMSS HIMSS Senior Director, Business Information Systems Tel: 706-838-0583 Cell: 706-258-8905 pmatthews@himss.org Luke Middleton Coordinator, Business Information Systems HIMSS Tel: 703-837-9824 Fax: 703-299-1501 lmiddleton@himss.org

Vicki Wheatley, MS VP, Strategic Services QuadraMed Tel: 972-378-9114 (office) Email: VWheatley@QuadraMed.com Pat Wise, RN, MSN, MA, Colonel, USA Ret'd Vice President, Healthcare Information Systems HIMSS Tel: 706-650-1482 Cell: 706-829-2654 pwise@himss.org Lisa A. Gallagher, BSEE, CISM HIMSS Senior Director, Privacy & Security Tel: (703) 837-9816 Email: lgallagher@himss.org

Mike Kroll Coordinator, Informatics HIMSS Tel: 312-915-9280 Fax: 312-915-9511 mkroll@himss.org

Copyright 2007 by the Healthcare Information and Management Systems Society

35


								
To top