0 tech day vi reston, virginia 19 april 2006 ieee computer society identity federation in cancer...
TRANSCRIPT
1Tech Day VI
Reston, Virginia19 April 2006
IEEE Computer Society
Identity Federation in Cancer Biomedical Informatics Grid (caBIGTM)A Federated Identity Management Case Study
Tim Weil – CISSP, CISAKen Lin - CISSP
Booz Allen HamiltonIdentity Management Architect
2
Tech Day VI
Agenda
The Evolution of the Cancer Research and the Grid Infrastructure
Grid Security Architecture and Federated Identity Management (FIM)
FIM Use Cases and Architecture
Technology Evaluation and Recommendations
Summary
3Tech Day VI
Cancer Biomedical Informatics Grid builds the framework for sharing biomedical research information
The deciphering of the human genome offers insight into the development of numerous therapies, predictors, and markers for cancer
Annotated human biospecimens with detailed clinical information offers an unprecedented opportunity for the robust identification and accurate quantitation of molecular signatures of cancer, thereby accelerating the development and implementation of new cancer markers and therapies
The lack of common infrastructure has prevented life science research institutions from being able to mine and analyze disparate data sources
The inability to share technologies and data developed by different cancer research institutions can severely hamper the research process
The NCI Center for Bioinformatics (NCICB) created the project cancer Biomedical Informatics Grid (caBIGTM) and built the caGrid 0.5 prototype to satisfy simple data integration and sharing use cases
4Tech Day VI
Grid is a Service Oriented Architecture (SOA) implementation to enable cross-organizational collaboration
5Tech Day VI
NCI Mission Statement
6Tech Day VI
7Tech Day VI
This effort focuses on the authentication and authorization of the Identity and Access Management Operating Model
FocusedStandardization
Integration
INFORMATION SHARING/PROTECTION
Protect Intellectual Property
Protect Intellectual Property
Protect Privacy Data
Protect Privacy Data
Protect Sensitive
Data
Protect Sensitive
Data
Phy
sica
l
Ent
ity
Man
agem
ent
Cre
dent
ial
Man
agem
ent
Sto
rage
Aut
hent
icat
ion
Aut
horiz
atio
n
Ris
k M
anag
emen
t
Cer
tific
atio
n an
d A
ccre
dita
tion
Ver
ifica
tion
Tra
inin
g an
d A
war
enes
s
Gov
erna
nce
and
Ove
rsig
ht
CORE IdAM SUPPORTING
DATA STANDARDS LAYER Electronic Data Identity
CAPSTONE POLICIES
ENABLING IdAM
STANDARS AND
GUIDELINES
ENABLING PROCEDURES
AND MECHANISMS
DATA STANDARDS
BUSINESS DRIVERS
DirectoryServer
UserWorkstation
Domain NameSystem Server
PKI CA
UserWorkstation
SONETMux
ATMSwitch
Router
DirectoryServer
UserWorkstation
Domain NameSystem Server
DirectoryServer
DirectoryServer
UserWorkstation
UserWorkstation
Domain NameSystem ServerDomain NameSystem Server
PKI CA
UserWorkstation
PKI CAPKI CA
UserWorkstation
UserWorkstation
SONETMux
ATMSwitch
Router
SONETMux
ATMSwitch
Router
DirectoryServer
UserWorkstation
Domain NameSystem Server
PKI CA
UserWorkstation
SONETMux
ATMSwitch
Router
DirectoryServer
UserWorkstation
Domain NameSystem Server
DirectoryServer
DirectoryServer
UserWorkstation
UserWorkstation
Domain NameSystem ServerDomain NameSystem Server
PKI CA
UserWorkstation
PKI CAPKI CA
UserWorkstation
UserWorkstation
SONETMux
ATMSwitch
Router
SONETMux
ATMSwitch
Router
DirectoryServer
UserWorkstation
Domain NameSystem Server
PKI CA
UserWorkstation
SONETMux
ATMSwitch
Router
DirectoryServer
UserWorkstation
Domain NameSystem Server
DirectoryServer
DirectoryServer
UserWorkstation
UserWorkstation
Domain NameSystem ServerDomain NameSystem Server
PKI CA
UserWorkstation
PKI CAPKI CA
UserWorkstation
UserWorkstation
SONETMux
ATMSwitch
Router
SONETMux
ATMSwitch
Router
DirectoryServer
UserWorkstation
Domain NameSystem Server
PKI CA
UserWorkstation
SONETMux
ATMSwitch
Router
DirectoryServer
UserWorkstation
Domain NameSystem Server
DirectoryServer
DirectoryServer
UserWorkstation
UserWorkstation
Domain NameSystem ServerDomain NameSystem Server
PKI CA
UserWorkstation
PKI CAPKI CA
UserWorkstation
UserWorkstation
SONETMux
ATMSwitch
Router
SONETMux
ATMSwitch
Router
TECHNICAL & SECURITY ARCHITECTUREMedium
Low
High
MaturityMaturity
AssuranceAssurance
8Tech Day VI
Identity and Access Management Operating Model (Authentication & Authorization)
Protect Privacy
Data
Protect Privacy
Data
Protect Intellectual
Property
Protect Intellectual
Property
Protect Sensitive
Data
Protect Sensitive
Data
INFORMATION SHARING/PROTECTION
BUSINESS DRIVERS CAPSTONE POLICIES
• Capstone policies provide overall guidance for managing compliance risk within the enterprise IT information sharing program.
• Derived from multi-jurisdictional regulations and standards including HSPD-12, FIPS 201, eAuthentication, HIPAA, and FDA 21 CFR Part 11,
• These policies reflect measures established through the best practices suggested by the various regulatory bodies.
9Tech Day VI
Identity and Access Management Operating Model (Authentication & Authorization)
Phy
sica
l
Ent
ity
Man
agem
ent
Cre
dent
ial
Man
agem
ent
Sto
rage
Aut
hent
icat
ion
Aut
horiz
atio
n
Ris
k M
anag
emen
t
Cer
tific
atio
nan
d A
ccre
dita
tion
Ver
ifica
tion
Tra
inin
g an
d A
war
enes
s
Gov
erna
nce
and
Ove
rsig
ht
CORE IdAM
SUPPORTING
At the IT security layer, the IdAM Standards and Guidelines drive interoperability and serve as the operational baseline for inserting the capstone policies. Typical standard and guideline categories that apply include: Directory Services (LDAP), Public Key Infrastructure (PKI), Trust Domains (Federation), and Access Control Models (RBAC and ABAC).
Enabling IdAM Standards and GuidelinesBUSINESS DRIVERS
10Tech Day VI
Identity and Access Management Operating Model (Authentication & Authorization)
IdAM Enabling Procedures and Mechanisms are determined by the maturity of the organization, level of assurance and sensitivity of the data.
•Procedures - Key procedures must be identified to support the enterprise IT IdAM operating model. The procedures contain levels of maturity ranging from Low to High consistent with the needs of system information sharing efforts. Enterprise IT should have flexibility in implementing appropriate levels of maturity consistent with the complexity of their efforts.
•Mechanisms – The key mechanisms that must be identified to support the operating model and procedures which contain levels of maturity ranging from Low to High consistent with the needs of the enterprise IT information sharing efforts.
Enabling Procedures and MechanismsBUSINESS DRIVERS
11Tech Day VI
Identity and Access Management Operating Model (Authentication & Authorization)
Focused
Standardization
Integration
DirectoryServer
UserWorkstation
Domain NameSystem Server
PKI CA
UserWorkstation
SONETMux
ATMSwitch
Router
DirectoryServer
UserWorkstation
Domain NameSystem Server
DirectoryServer
DirectoryServer
UserWorkstation
UserWorkstation
Domain NameSystem ServerDomain NameSystem Server
PKI CA
UserWorkstation
PKI CAPKI CA
UserWorkstation
UserWorkstation
SONETMux
ATMSwitch
Router
SONETMux
ATMSwitch
Router
DirectoryServer
UserWorkstation
Domain NameSystem Server
PKI CA
UserWorkstation
SONETMux
ATMSwitch
Router
DirectoryServer
UserWorkstation
Domain NameSystem Server
DirectoryServer
DirectoryServer
UserWorkstation
UserWorkstation
Domain NameSystem ServerDomain NameSystem Server
PKI CA
UserWorkstation
PKI CAPKI CA
UserWorkstation
UserWorkstation
SONETMux
ATMSwitch
Router
SONETMux
ATMSwitch
Router
DirectoryServer
UserWorkstation
Domain NameSystem Server
PKI CA
UserWorkstation
SONETMux
ATMSwitch
Router
DirectoryServer
UserWorkstation
Domain NameSystem Server
DirectoryServer
DirectoryServer
UserWorkstation
UserWorkstation
Domain NameSystem ServerDomain NameSystem Server
PKI CA
UserWorkstation
PKI CAPKI CA
UserWorkstation
UserWorkstation
SONETMux
ATMSwitch
Router
SONETMux
ATMSwitch
Router
DirectoryServer
UserWorkstation
Domain NameSystem Server
PKI CA
UserWorkstation
SONETMux
ATMSwitch
Router
DirectoryServer
UserWorkstation
Domain NameSystem Server
DirectoryServer
DirectoryServer
UserWorkstation
UserWorkstation
Domain NameSystem ServerDomain NameSystem Server
PKI CA
UserWorkstation
PKI CAPKI CA
UserWorkstation
UserWorkstation
SONETMux
ATMSwitch
Router
SONETMux
ATMSwitch
Router
MaturityMaturity
TECHNICAL & SECURITY ARCHITECTURE
Medium
Low
High
AssuranceAssurance
Enabling Procedures and MechanismsBUSINESS DRIVERS
12Tech Day VI
Identity and Access Management Operating Model (Authentication & Authorization)
Identity DATA STANDARDS LAYER Electronic Data
Data Standards for Identity ManagementBUSINESS DRIVERS
The IdAM Data Standards layer represents Identity and Electronic Data which may be modeled as business transaction data (SOAP messages), metadata (XML Schemas), or metalanguages (Data Dictionaries, Logical Data Model). Enterprise IT should leverage the data standards for identity management such as federated identity standards (i.e. SAML, Shibboleth, WS-*) and cryptography standards (i.e. PKIX - X.509 )
13Tech Day VI
This effort focuses on the authentication and authorization of the Identity and Access Management Operating Model
FocusedStandardization
Integration
INFORMATION SHARING/PROTECTION
Protect Intellectual Property
Protect Intellectual Property
Protect Privacy Data
Protect Privacy Data
Protect Sensitive
Data
Protect Sensitive
Data
Phy
sica
l
Ent
ity
Man
agem
ent
Cre
dent
ial
Man
agem
ent
Sto
rage
Aut
hent
icat
ion
Aut
horiz
atio
n
Ris
k M
anag
emen
t
Cer
tific
atio
n an
d A
ccre
dita
tion
Ver
ifica
tion
Tra
inin
g an
d A
war
enes
s
Gov
erna
nce
and
Ove
rsig
ht
CORE IdAM SUPPORTING
DATA STANDARDS LAYER Electronic Data Identity
CAPSTONE POLICIES
ENABLING IdAM
STANDARS AND
GUIDELINES
ENABLING PROCEDURES
AND MECHANISMS
DATA STANDARDS
BUSINESS DRIVERS
DirectoryServer
UserWorkstation
Domain NameSystem Server
PKI CA
UserWorkstation
SONETMux
ATMSwitch
Router
DirectoryServer
UserWorkstation
Domain NameSystem Server
DirectoryServer
DirectoryServer
UserWorkstation
UserWorkstation
Domain NameSystem ServerDomain NameSystem Server
PKI CA
UserWorkstation
PKI CAPKI CA
UserWorkstation
UserWorkstation
SONETMux
ATMSwitch
Router
SONETMux
ATMSwitch
Router
DirectoryServer
UserWorkstation
Domain NameSystem Server
PKI CA
UserWorkstation
SONETMux
ATMSwitch
Router
DirectoryServer
UserWorkstation
Domain NameSystem Server
DirectoryServer
DirectoryServer
UserWorkstation
UserWorkstation
Domain NameSystem ServerDomain NameSystem Server
PKI CA
UserWorkstation
PKI CAPKI CA
UserWorkstation
UserWorkstation
SONETMux
ATMSwitch
Router
SONETMux
ATMSwitch
Router
DirectoryServer
UserWorkstation
Domain NameSystem Server
PKI CA
UserWorkstation
SONETMux
ATMSwitch
Router
DirectoryServer
UserWorkstation
Domain NameSystem Server
DirectoryServer
DirectoryServer
UserWorkstation
UserWorkstation
Domain NameSystem ServerDomain NameSystem Server
PKI CA
UserWorkstation
PKI CAPKI CA
UserWorkstation
UserWorkstation
SONETMux
ATMSwitch
Router
SONETMux
ATMSwitch
Router
DirectoryServer
UserWorkstation
Domain NameSystem Server
PKI CA
UserWorkstation
SONETMux
ATMSwitch
Router
DirectoryServer
UserWorkstation
Domain NameSystem Server
DirectoryServer
DirectoryServer
UserWorkstation
UserWorkstation
Domain NameSystem ServerDomain NameSystem Server
PKI CA
UserWorkstation
PKI CAPKI CA
UserWorkstation
UserWorkstation
SONETMux
ATMSwitch
Router
SONETMux
ATMSwitch
Router
TECHNICAL & SECURITY ARCHITECTURE
MediumLow
High
MaturityMaturity
AssuranceAssurance
14Tech Day VI
Identity and Access Management – Evolutionary Model
IdAM Requirements
Develop the IdAM capability requirements and assurance levels to support business capabilities
Maturity Assessment
Assess the maturity level of an organization’s IdAM capability
Establish an organizational wide trusted identity and identity proofing process
Trusted Identity
Integrated Provisioning
Provision entity attributes from various authoritative sources to the trusted identity
Enterprise Portal
Simplified Sign On, credential based authentication, centralized privilege management
Federated Identity
Cross enterprise information sharing with trusted identity and access policies
Bus
ines
s V
alue
Focused Capabilities
Standardization
Cost and Complexity
Integration
15Tech Day VI
caGrid 0.5 Identity and Access Management (IdAM) Architecture
GUMS
Ohio State
User A
User B
User C
User D
Usernam
e/P
assword
Secure Communication
Single Sign On
Delegation
…..
Proxy Cert
Proxy Cert
caBIG
NCI
GUMS
Proxy Cert
Proxy Cert
Usernam
e/P
assword
Use
rnam
e/P
assw
ord
Proxy Cer
Use
rnam
e/P
assw
ord
Proxy Cert
GUMS: Grid User Management Service
16Tech Day VI
Federated Authentication Scenarios
Non-caGrid Certificate. John Smith wants to use the X.509 certificate obtained from a 3rd party Certification Authority to access caBIG services
caGrid-Certificate. John Smith uses caGrid X.509 certificate to access caBIG services
No Certificate. John Smith wants to use the Email username and password to access caBIG services
Implications
– caGrid needs to accept credentials of different assurance levels
– Assurance levels are defined by 1) the identity proofing process, AND 2) the credential itself
– In the identity federation environment, the architecture needs to accommodate existing credentials rather than creating new credentials
– Credential management will fall on the organization who issues the credential
17Tech Day VI
Federated Authentication Architecture leveraging the EAuthentication architecture
caBIG
Federated Authentication Architecture
Georgetown NCI
UPMCFox Chase Certification
AuthorityFox Chase Certificate
Grid Certificate
Georgetown LDAP
UPMC Hardware Token
Certification AuthorityService
Identity Federation Service (IFS)
Identity Federation Service (IFS)
Username and password
Authentication Assertion
Authentication Authority Registry
Certification Authority
18Tech Day VI
Assertion Based Scenario (Users without X.509 certificates)
Assertion Based Authentication
Georgetown User
Identity Federation Service (IFS)
Credential Service Provider (Georgetown LDAP)
8. The IFS generates a X.509 certificate for the user
1. Request Access to caBIG
4. Redirect Users to Georgetown LDAP
5. Submit Username and Password
7. Georgetown LDAP generates an authentication assertion
6. Georgetown LDAP authenticates the user
caBIG
Authentication Authority Registry
2. Where is Georgetown’s Authentication Authority?
3. URL of Georgetown’s Authentication Authority
9. The IFS generates proxy certificates for the user
19Tech Day VI
Certificate Based Scenario (Users with X.509 certificates)
Certificate Based Authentication
Fox Chase User
Identity Federation Service (IFS)
6. The IFS generates a X.509 certificate for the user
1. Request Access to caBIG with a Fox Chase certificate
4. Is this certificate still valid (Not expired)?
5. Yes, the certificate is valid
caBIG
Authentication Authority Registry
2. Where is Fox Chase’s Authentication Authority?
3. URL of Fox Chase’s Authentication Authority
7. The IFS generates proxy certificates for the user
Credential Service Provider (Fox Chase Validation Service)
20Tech Day VI
Federated Authorization Scenarios
Mary Smith owns the Protein Database System (PDBS) at Rutgers University.
– caBIG Users Access Policy. caBIG users must be Medical Doctors with 10 years of experience approved to be qualified PDBS users
– Local Access Policy. caBIG qualified users can only use PDBS from 10:00am to 11:00am EST everyday. Other timeslots are reserved for Rutgers users.
Joan Taylor owns the Cell Attachment Analytical Service (CAAS) at University of Pittsburgh. The CAAS is used in the Hope research project with participants from different organizations in caBIG.
– Privilege Delegation and Group Membership. Only Hope project manager from caBIG have read and write privileges to the CAAS. The Hope project manager can delegate read and write privileges to Hope project members.
– Provisioning/Auditing. The IRB at University of Pittsburgh needs to know who has read and write privileges to CAAS on the weekly basis.
21Tech Day VI
Federated Authorization Architecture using the attribute based authorization
Fox ChaseClinical Trial
Management System
Federated Authorization Architecture
Georgetown User
PEP: Policy Enforcement Point
PDP: Policy Decision Point
ADS: Attribute Discovery Service
10:30 am ESTGeorgetownEntity Attribute
Authority
Hope Project Membership
UPMCProject Attribute
Authority
PDP/ADS
PDP/ADS
PDP/ADS
PEPMedical Doctor
10 years of Experience
Hope Project Member Privileges
Attribute Authority Registry Fox Chase
Time Server
Hope Project Owner
caBIG
22Tech Day VI
An illustrative example of federated identity management
AuthenticationService
ValidationService
Attribute DiscoveryService
AuthorizationService
Credential ServiceProvider
Credential Service Provider
Credential ServiceProvider
Userid/passwordX.509 CertsSmartcards
Tokens
Users
Varying assurance level credentials
Userid/passwordX.509 CertsSmartcards
Tokens
GRID Service
…
NCICB Fox Chase
…
User
Project
Attribute
Org.
…
…
Virtual Organization
23Tech Day VI
The following open source technologies were evaluated based on the notional architecture
Technology Version Purpose
Globus Grid Security Infrastructure (GSI) 4.0.1Provide service delegation, single-sign-on, and PDP chaining for grid infrastructure
Shibboleth/GridShib1.3 / Beta
Providing attribute authority services with Web based authentication
Pulling authorization attributes from the Shibboleth attribute authority service to grid services
SAML (OpenSAML) 1.xProvide authentication, authorization decisions and attribute assertions
Grid User Management Service 0.5 User account management tool
caGrid Authorization Management Service
0.5 User attributes management tool
Grouper 0.5.6 Enterprise group management tool
Signet 0.5 Enterprise privilege management tool
SAFE 2.0 FDA 21 CFR Part 11 compliance credential
Common Security Module (CSM) 3.0.1 NCI security library for developers
24Tech Day VI
Illustrative mapping of authentication technologies
caBIG
Federated Authentication Architecture
Georgetown NCI
UPMCFox Chase Certification
AuthorityFox Chase Certificate
Grid Certificate
Georgetown LDAP
UPMC Hardware Token
Certification AuthorityService
Identity Federation Service (IFS)
Identity Federation Service (IFS)
Username and password
Authentication Assertion
SAML
SAFE Credential
GSI Proxy Certificate
GridLogon / GUMS
GridLogon / GUMS
Authentication Authority Registry
Certification Authority
25Tech Day VI
Illustrative mapping of authorization technologies
Fox ChaseClinical Trial
Management System
Federated Authorization Architecture
Georgetown User
PEP: Policy Enforcement Point
PDP: Policy Decision Point
ADS: Attribute Discovery Service
10:30 am ESTGeorgetown
Entity AttributeAuthority
Hope Project Membership
UPMCProject Attribute
Authority
PDP/ADS
PDP/ADS
PDP/ADS
PEPMedical Doctor
10 years of Experience
Hope Project Member Privileges
Attribute Authority Registry Fox Chase
Time Server
Hope Project Owner
caBIG
GridShib(SAML)
Shibboleth Attribute Authority
Service
GSI PDP Chaining
Grouper/Signet CSMCAMS
26Tech Day VI
The evaluation shows many technologies are still in early development stages
Technology Status of Current Release
Globus GSI Proxy Certificate 4.0 is available
Globus GridLogon/MyProxy Cannot generate end entity certificates (EECs) in our testing release. Importing a SAFE credential will violate the non-repudiation requirement in the SAFE Standard. Does not support assertion based authentication method.
Globus GSI PDP Chaining 4.0 is available
Shibboleth Attribute Authority Service 1.3 is available
GridShib Beta. “Pull” mode is ready at the current release.
SAML 1.1 is available
GUMS 0.5 is available. Already runs as a caBIG service. Does not support assertion based authentication method. Cannot accept SAFE credentials.
CAMS 0.5 is available. Already runs as a caBIG service. Integrates with caBIG data standards. Does not support SAML attribute assertion.
Grouper & Signet 0.5.6 Pre-Beta, does not have a grid service interface
CSM 3.0.1 works with LDAP and relational database as the back end. Cannot work with certificate back end currently.
SAFE 2.0 is available
27Tech Day VI
Identity and Access Management – Evolutionary Model
IdAM Requirements
Develop the IdAM capability requirements and assurance levels to support business capabilities
Maturity Assessment
Assess the maturity level of an organization’s IdAM capability
Establish an organizational wide trusted identity and identity proofing process
Trusted Identity
Integrated Provisioning
Provision entity attributes from various authoritative sources to the trusted identity
Enterprise Portal
Simplified Sign On, credential based authentication, centralized privilege management
Federated Identity
Cross enterprise information sharing with trusted identity and access policies
Bus
ines
s V
alue
Focused Capabilities
Standardization
Cost and Complexity
Integration
28Tech Day VI
Identity and Access Management (IdAM Framework)
Credentialing
Entity Management
Assurance Level
Business Events
Human Resource
Business Partner
CRM
Identity Proofing
Authoritative Sources
Storage
Trusted Identity
Provisioning
Attribute
Attribute
Attribute
Attribute
Attribute
Attribute
Attribute
Attribute
Attribute
Authentication
Credential
Authorization
Attribute
Attribute
Attribute
Attributes
29Tech Day VI
Architecture and Technology Recommendations
Develop “business-oriented” security use and abuse cases. caBIG™ should develop “business-oriented” security use cases to represent community processes. The technical focus of the current security use cases (iteration 2) does not represent the actual security requirements from the caBIG™ community. Since identity federation relies more on process than technology, this white paper defines a set of federated authentication and authorization scenarios as a basis to develop the notional architecture. The caBIG™ community should conduct further scenario definition and refinement to promote a more comprehensive federation architecture.
Vet the Federated Identity Management (FIM) requirements and the notional architecture. The FIM requirements and the notional architecture are straw man efforts that the caBIG™ community should vet extensively to validate that all security use cases are satisfied before the production implementation. The proposed notional architecture focuses solely on authentication and authorization. Other core identity and access management (IdAM) and supporting services will evolve as the “business-oriented” security use cases are developed.
Proof-of-concept (POC) implementation. Due to the complexity of the evaluated technologies, a POC implementation of the notional architecture would provide greater clarity into the accuracy of the security use case development and how the notional architecture best applies. The POC should be built on top of the caBIG™ 0.5 release, however, many implementation requirements need to be evaluated.
Consider the maturity of technologies. Very few technologies in the evaluation list have been deployed in a large scale of production environment. Many evaluated technologies have very limited development resources that would impact the quality and the capability of production support once the software is released.
30Tech Day VI
Policy and Regulatory Environment Recommendations
Develop caBIG™ Governance Policies. A successful security implementation requires policies in many layers. For example, the capstone 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 IdAM mechanism.
Facilitate Cross-Cutting Policy Development. A successful security implementation requires policies in many layers. For example, the capstone 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 IdAM mechanism.
Identify the minimum security requirements from the regulatory mandates. Security and privacy requirements from regulatory mandates are the minimum security requirements caBIG needs to comply. Although HIPAA and 21 CFR Part 11 were reviewed in this whitepaper, it’s strictly from the identity federation point of view. A comprehensive review should be conducted to capture all security and privacy requirements. It is likely those requirements will impact many workspaces and working groups in caBIG.
Consider separating regulated and non-regulated environments. Ensure a non-grid application to comply with regulatory requirements takes significant efforts and cost. Mixing regulatory and non-regulatory applications will elevate the required security controls, which is not necessary for many non-regulatory applications. caBIG should consider the design option of separating the technical architecture layer of regulated and non-regulated environments and enabling the data sharing at the semantic layer.
31Tech Day VI
Process and Execution Recommendations
Create an “Independent and Integrated” cross-cutting security working group.
– Domain workspaces are disconnected from security implementation
– No consolidated (from domain workspaces) security requirements
– Inconsistent security messages from different domain workspaces
– Lack of resource for security architecture to bridge the caBIG™ security principles an implementation
Develop a security engineering process.
– The security engineering process (SEP) will specify roles and responsibilities, identify process steps, and define inputs and deliverables. The security working group (if created) should use the SEP to ensure security is integrated into domain workspaces, security architecture is defined and vetted, and implementation is aligned.
32Tech Day VI
Security Engineering Process
()
33Tech Day VI
Security Engineering Process (cont)
()
34Tech Day VI
The real challenges of cross-institutional data sharing is political and cultural not technical
The Institutional Review Board (IRB) is the ultimate authority for defining security and privacy compliance policies. To share sensitive medical information among institutions would require IRBs’ approval and an individual trust agreement needs to be established (n^2 problem)
Currently, two data sharing mechanisms among institutions:
– Public data, no access control is required
– Sensitive data, access control is required
The concept of assurance level does not exist in the current practices of healthcare industry
Healthcare SOA security problems are complex as epitomized by
– Infrastructure Gaps: Some institutions are using Excel sharing data while some are using biomedical informatics systems
– Scientific vs. Engineering Mindset: Enthusiastic about technologies, needs to understand the importance of having an integrated engineering process
– Regulatory Compliance: IRBs are very conservative in crafting data sharing policies. Large scale agreement is difficult
35Tech Day VI
Thank you for joining us!
For BAH Identity and Access Management Identity Federation
Kenneth LinSenior Consultant
Booz | Allen | Hamilton
Tel (703) [email protected]
Kenneth LinSenior Consultant
Booz | Allen | Hamilton
Tel (703) [email protected]
36Tech Day VI
37Tech Day VI
Example Security Architecture – SAFE
From caBIG™ security whitepaper