# Presentation: 557871

## Development of caBIGTM Security Program 

**Presentation to Cooperative Groups Teleconference**
**April 27, 2006**
**Frank J. Manion, M.S.**

## Overview

- The Federation concept
- Review of Security whitepaper recommendations
- Security Program initiative
- Initiative Overview
- Methodology
- Challenges and open issues
- Project Timeline

## Identity Management and Federation - Overview

- Enable users to use their institution, or other certified third party, provided identity for authenticating to the Grid
- User should be able to authenticate to the Grid using their institution’s existing mechanisms

*Image taken from the caBIG Security Evaluation White Paper*

## Proposed Conceptual (“Notional”) Architecture

- Courtesy of Kenneth Lin, BAH

## Federation – Virtual Organizations

- Span across multiple physical organizations
- Members are probably more interested in solving a particular problem then in who any individual works for
- Each physical organization probably has it’s own infrastructure
- The members of the VO probably do not have authority over their own physical infrastructure

*Definition from the Condor-Shibboleth Integration Project*

## Federation status

- (very) Large Federations are real and in use today
- Higher-Ed *InCommon*
- UTHSC
- Federal e-Authentication Project
- European Grid Initiative EGEE
- Inter-Federation Federations emerging
- Virtual Organizations have similar status

## Slide 7

## Whitepaper Recommendations

## Security Whitepaper Technology & Architecture Recommendations

- Develop business-oriented security use & abuse cases
- Current use cases do not reflect cancer center requirements from IRBs, Compliance Officers, Honest Brokers, CIOs, other relevant C-level execs, etc.
- Vet the Federated Identity Management requirements and the notional architecture
- Other Identity & Access Management use cases will evolve over time from business use/abuse cases
_**Federation is Strategic Level Working Group requirement for caBIG**__**TM**_
- Develop a Proof-of-Concept  implementation
- Test bed needed for the conceptual-level architecture
- Play an influential role in future security technology development
- In V1 of whitepaper, highly important from business value perspective
- High impact in particular in this (grid) space
- Consider the maturity of technologies
- Consider level of funding, size of development groups, and adopter base (vertical “market” & peers)

**Notes:**
Develop “business-oriented” security use cases. caBIGTM should develop “business
oriented” security use cases to represent community processes. The technical focus of the
current security use cases (iteration2) does not represent the actual security requirements
from the caBIGTM community. Because 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 caBIGTM 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 caBIGTM 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 (e.g. Auditing) 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 caBIGTM 0.5 release, however, many
implementation requirements need to be evaluated. For example, every technology should
communicate with caBIGTM services using defined protocol in caBIGTM. So far only GUMS
and CAMS are supporting this. The POC implementation should focus on: 1) the IFS
component and its capability to federate different types of credentials into X.509 certificates,
and 2) the Policy Decision Point (PDP) chaining in GSI to implement attribute based
authorization.
• Play an influential role in future technology releases. caBIGTM can play an influential role
in the development of key technologies such as Globus GSI and GridShib. The community
can drive their implementations to continue closing the gap with caBIG’s requirements.
• Define caBIGTM governance policies. The capstone policies and enabling standards,
guidelines, and procedures should be developed along with the IdAM mechanism. caBIGTM
needs to define the governance policies that will promote operational success of federated
identity management within the caBIGTM community. Based on the notional architecture, the
trust agreement for identity federation, the assurance level of credentials, certification and
accreditation guidance for credential providers, and the standard for authorization attributes
are key governance policies to enable federated identity management.

## Security Whitepaper Policy & Regulatory Recommendations

- Develop caBIGTM governance policies
- Success involves multiple layers (i.e., trust, identity vetting, guidelines, data standards, SoD, firewalls, physical security, etc.)
- Facilitate cross-cutting policy development
- Involve multiple workspaces & working groups
- Identify the minimum security requirements from regulatory mandates
- Need comprehensive review
- Consider separating regulated and non-regulated environments
- Mixing environments increases costs, may reduce adoption

**Notes:**
Develop “business-oriented” security use cases. caBIGTM should develop “business
oriented” security use cases to represent community processes. The technical focus of the
current security use cases (iteration2) does not represent the actual security requirements
from the caBIGTM community. Because 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 caBIGTM 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 caBIGTM 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 (e.g. Auditing) 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 caBIGTM 0.5 release, however, many
implementation requirements need to be evaluated. For example, every technology should
communicate with caBIGTM services using defined protocol in caBIGTM. So far only GUMS
and CAMS are supporting this. The POC implementation should focus on: 1) the IFS
component and its capability to federate different types of credentials into X.509 certificates,
and 2) the Policy Decision Point (PDP) chaining in GSI to implement attribute based
authorization.
• Play an influential role in future technology releases. caBIGTM can play an influential role
in the development of key technologies such as Globus GSI and GridShib. The community
can drive their implementations to continue closing the gap with caBIG’s requirements.
• Define caBIGTM governance policies. The capstone policies and enabling standards,
guidelines, and procedures should be developed along with the IdAM mechanism. caBIGTM
needs to define the governance policies that will promote operational success of federated
identity management within the caBIGTM community. Based on the notional architecture, the
trust agreement for identity federation, the assurance level of credentials, certification and
accreditation guidance for credential providers, and the standard for authorization attributes
are key governance policies to enable federated identity management.

## Security Whitepaper Process & Execution Recommendations

- Create an “Independent & Integrated” cross-cutting security working group
- Problems
- Domain workspaces currently disconnected from security implementation
- No consolidated security requirements across workspaces
- Inconsistent security message from domain workspaces
- Lack of resources on development team
- Recommendations
- Establish Central security governance entity
- Dedicate more effort to security
- Consistent, consolidated design
- Develop a security engineering process

**Notes:**
Develop “business-oriented” security use cases. caBIGTM should develop “business
oriented” security use cases to represent community processes. The technical focus of the
current security use cases (iteration2) does not represent the actual security requirements
from the caBIGTM community. Because 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 caBIGTM 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 caBIGTM 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 (e.g. Auditing) 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 caBIGTM 0.5 release, however, many
implementation requirements need to be evaluated. For example, every technology should
communicate with caBIGTM services using defined protocol in caBIGTM. So far only GUMS
and CAMS are supporting this. The POC implementation should focus on: 1) the IFS
component and its capability to federate different types of credentials into X.509 certificates,
and 2) the Policy Decision Point (PDP) chaining in GSI to implement attribute based
authorization.
• Play an influential role in future technology releases. caBIGTM can play an influential role
in the development of key technologies such as Globus GSI and GridShib. The community
can drive their implementations to continue closing the gap with caBIG’s requirements.
• Define caBIGTM governance policies. The capstone policies and enabling standards,
guidelines, and procedures should be developed along with the IdAM mechanism. caBIGTM
needs to define the governance policies that will promote operational success of federated
identity management within the caBIGTM community. Based on the notional architecture, the
trust agreement for identity federation, the assurance level of credentials, certification and
accreditation guidance for credential providers, and the standard for authorization attributes
are key governance policies to enable federated identity management.

## Example Security Architecture – SAFE

*From caBIG**TM** security whitepaper*

## caBIGTM Security Program

## caBIGTM Security Program

- Cross-cutting joint effort between Architecture, VCDE, TBPT, DSIC workspaces
- Pilot project to develop initial frameworks for:
- Business-based use cases
- Required trust anchors – agreements, policies, procedures
- Security management governance infrastructure
- Will target the initial four caTIES adopters
- Washington University, U Pitt Med.Ctr., Thomas Jefferson, U Penn
- Focus on involving regulatory and other “business users” at the Centers
- IRB members
- Compliance officers

## caBIGTM Security Program

- Principal Investigators: F. Manion (FCCC),    Dr. R. Crowley (UPMC), Dr. R. Robbins (FHCRC)
- Consultants: IRB members from UPMC/FCCC, Grid Security Experts, Federation Security expert Dr. William Weems, UTHSC
- Two (small) recruited working groups:
- Legal, regulatory compliance, patient advocates, and bioethics
- Technical, data models, vocabulary, grid security
- Will seek to develop framework trust agreements and define trust anchors
- Consequently, will develop required policy and procedure frameworks at several levels of the architecture and operational structure

## caBIGTM Security Program

- Will attempt to define the requirements for the permanent security governance process
- Will address identity management, access control, privacy, and intellectual property issues
- Deliverables:
- Capstone governance structure framework and documents
- Includes security refinement processes
- Policy and procedures sufficient to operate caTIES
- Trust agreements between adopters
- Will not address deep details of de-identification

## Trust Establishment & Maintenance Issues

- User 1

- User 2

- Identity & Authorization Mapping

- Identity & Authorization Mapping

- Identity & Authorization Mapping

- Trust

- Trust

- Protocols

- Graphic from CERN

- Trust

- Trust

- Operations

## Methodology

- Community-based process
- Establish (small) cross-cutting security/technical/policy committee
- IRB members, compliance officers, CIOs, etc.
- Other site-specific stakeholders as required
- Security/Policy/process experts on Grid/Federated security
- Legal/Ethics experts
- Patient advocates
- VCDE, caGRID team member(s)
- Two working groups
- Policy/Legal/Regulatory
- Technical
- Develop _*high level*_* *scripted* *usage scenarios
- Policy/Legal working group interviews adopter IRB and other stakeholders for input on these scenarios & other requirements

## Methodology - Continued

- Policy WG collects responses, develops business use cases and minimum set of requirements for trust
- Joint working group review
- Joint working group develops security boundary conditions, final use cases and desired *future state* security document
- Community review
- Used to inform caGRID development
- Policy team develops strawman trust agreements
- Input from other Grids/Federations such as the IGTF, InCommon
- Technical team develops policies and procedures for Authentication, Authorization in major roles (for caTIES)

## Methodology - Continued

- Joint Working groups develop operational Policies
- Regulatory requirements, HIPAA, 21 CRF 11
- Input from best practice standards such as ITIL, ISO 17799, NIST, etc.
- Other operational policies and procedures from existing grids/federations such as IGTF
- Joint working groups develop an initial Security Governance Framework
- A recommended governance structure for security
- Recommended processes for risk assessment and management
- A process for *on going policy and operations review* involving end users and stakeholders
- Requirements for *external audit review* *& associated policies*
- A process for managing* security incidents* *& events*
- A process for *management, review, and modification of trust agreements*

## TRUST: Must cope with different management policies & procedures of different centers
TRUST: Can we avoid the N^2 problem by developing a small set of federation agreements that each party certifies against?
Conflicting socialogy and operating principles between different subject domains
TRUST: Congruence of deep grid services and regulatory policy
Network Caches, for example – degree of risk?
TRUST: Some logical and physical GRID infrastructure must persist. Implications for developing and funding hard infrastructure. 
Security, Resource Naming & Discovery & certain other 
TRUST: Certain physical infrastructure must be securely managed

**TRUST**: Must cope with *different management policies* *& procedures* of different centers
**TRUST**: Can we avoid the N^2 problem by developing a small set of federation agreements that each party certifies against?
- Conflicting socialogy and operating principles between different subject domains
**TRUST**: Congruence of deep grid services and regulatory policy
*Network Caches*, for example – degree of risk?
**TRUST**: Some logical and physical GRID infrastructure must *persist*. Implications for developing and funding hard infrastructure.
*Security, *Resource Naming & Discovery & certain other
**TRUST**: Certain physical infrastructure must be securely managed

## Example Issues

**Policy: Management**
- What is the governance structure of the security management program
**Policy: Trust**
- Who are the right people/groups to involve in developing & maintaining trust agreements?
**Policy: Identity and Identity information architecture**
- What is minimum set of attributes?
- What role vocabularies should be used?
- How is identity vetting done?
- What about things like “Institution” & “Project” names?

## Example Issues

**Policy: Business Agreements**
- Which Groups should provide identity and digital certificates?
- Should third parties provide aspects of identity vetting and certification? Which ones?
- Policy implications/tradeoffs?
- For which levels of trust can & should we allow campus-based certificate authorities?
- If so, who certifies?
- Which federation bridge authorities will we need to cross certify with?
- What are the implications of failure to certify with certain federation bridges?
- Cost/benefits?

## Example Issues

**Policy: Identity**
- Who gets to be an Identity Provider?
- Will all identity providers function under identical policies regarding granting and terminating access?
- We need policies regarding Identity Provisioning very quickly for caTIES and caGRID 1.0
- How quickly can we realistically expect these?
- What do we do in the meantime?
- Who will set these policies - how often and under what condition will they be reviewed?

## Example Issues

**Policy: Auditing & Compliance**
- What are the minimal auditing requirements of applications?
- Should we treat identified data, de-identified data and non-patient related data separately?
- What are the advantages and disadvantages of doing that?
- Security event management
- What do you do if you detect that someone has accessed data that they shouldn't have?
- In a federated environment, who can individuals and organizations go to if they have a concern or complaint?

## Example Issues

**Policy: Technology**
- Where are the _*important*_  technology gaps?
- How much can we “patch” these with human processes until we have adequate technology?
- The security white paper evaluates very little of the security technology (CSM, CAMS, DORIAN) – i.e., what level of quality assurance is required
- What do we do if projects like caTIES need Virtual Organizations? How do we manage VOs?

**Notes:**
How much say will individual developers and adopters have in what kinds of technologies they can use. The White Paper argues for a federated approach with bridges etc. On the other hand BAH and NCICB tend to push particular solutions. Which is it?

## Security Engineering Process

**Security Engineering Process**

****

****

**(********)**

## Security Engineering Process (cont)

**(********)**

****

****

## Project Timeline

- 1 month – Mid June
- Working groups operational
- Face to face meeting to develop trial scenarios
- 2 months – Mid July
- Security scenarios completed
- 3 months – Mid August
- IRB interviews complete
- 4 months – Mid September
- Governance frameworks
- caTIES operating policies ready @ 4.5 months
- 5 months – Mid October
- Operational policy frameworks
- Scope/policy compliance report
- Trust frameworks
- 6 months – Mid November
- Signed trust agreements

## Slide 30

## Identity & Authorization Management Section

## IdAM Operating Model

- Courtesy of Kenneth Lin, BAH

## Identity & Access Control Framework

- Courtesy of Kenneth Lin, BAH

## caBIG V0.5 Identity Management Architecture

- Courtesy of Kenneth Lin, BAH

## Authentication Notional Architecture

- Courtesy of Kenneth Lin, BAH

## Authorization Notional Architecture

- Courtesy of Kenneth Lin, BAH

## Proposed Conceptual (“Notional”) Architecture

- Courtesy of Kenneth Lin, BAH

## Proposed Federation for Authentication

- Courtesy of Kenneth Lin, BAH

## Proposed Federation for Authorization

- Courtesy of Kenneth Lin, BAH

## Misc. Slides follow, no order

## Definitions & Key Concepts (Ian Foster)

***coordinates resources that are not subject to centralized control *****...**A Grid integrates and coordinates resources and users that live within different control domains — for example, the user’s desktop vs. central computing; different administrative units of the same company; or different companies; and addresses the issues of security, policy, payment, membership, and so forth that arise in these settings. Otherwise, we are dealing with a local management system.
***... ******using standard, open, general-purpose protocols and interfaces***A Grid is built from multi-purpose protocols and interfaces that address such fundamental issues as authentication, authorization, resource discovery, and resource access. It is important that these protocols and interfaces be s*tandard *and *open*. Otherwise, we are dealing with an application specific system.
** ... ****to deliver nontrivial qualities of service. **A Grid allows its constituent resources to be used in a coordinated fashion to deliver various qualities of service, relating for example to response time, throughput, availability, and security, and/or co-allocation of multiple resource types to meet complex user demands, so that the utility of the combined system is significantly greater than that of the sum of its parts.
**Scales in a uniform manner (Manion)**A Grid typically is designed so that as the need for additional services, fabric, and others resources grow, the amount of effort to add and maintain the additional resource grows approximately linearly.

**Notes:**
The Grid, itself, was born at a workshop at Argonne National Laboratory in September 1997, called "building a computational Grid", which was followed in 1998 by the publication of "The Grid: Blueprint for a New Computing Infrastructure" by Ian Foster of Argonne National Laboratory and Carl Kesselman of the University of Southern California. This book is often called the Grid bible. Ian Foster had previously been involved in the I-WAY project, and the Foster-Kesselman duo published a paper in 1997 called "Globus: a Metacomputing Infrastructure Toolkit", clearly linking the Globus Toolkit, which is at the heart of the Grid, with its predecessor, metacomputing. 

## Definitions & Key Concepts (Ian Foster)

- The real and specific problem that underlies the Grid concept is *coordinated resource sharing and problem solving in dynamic, multi-institutional virtual organizations*.
- Not primarily file exchange
- Rather, direct access to computers, software, data, and other resources
- Required by a range of collaborative problem-solving and resource brokering strategies emerging in industry, science, and engineering.
- This sharing is,
- necessarily, highly controlled, with
- resource providers and consumers defining clearly and carefully just what is shared, who is allowed to share, and the conditions under which sharing occurs.
- A set of individuals and/or institutions defined by such sharing rules form what we call a *virtual organization *(VO).

## Grids and Virtual Organizations

- Use Cases:
- 	An individual can be a member of several virtual organizations hosted on a single grid
- 	An individual can be a member of several virtual organizations hosted on several different grids.

## Security Status of caGRID 0.5.1

- Secure communications in place
***Common Security Module****** ******[CSM], ******the ******Group and****** ******User Management Services*** ***[GUMS], ***and the*** Common Attribute Management System [CAMS]*** operational
- Conceptual Architecture ***partially defined*** via the caBIG Security White paper
- But:
- Common attributes not defined
- No concept of how Certificate Authorities will provide trust anchor in the Grid fabric
- Applications/services defining their own security models within the application
- IRBs, compliance officers, etc., not involved in requirements planning to date
- No Trust Anchors in place

## Following on the Extreme Boundary Conditions

- 21 CFR 11

- HIPAA

- Public

- 21 CFR 11

- HIPAA

- Public

- Policy Filters

- Policy Filters

- Policy Filters

**Notes:**
What does it mean for a grid project with public parts to be HIPAA/21 CFR compliant?

## Federated Identity Management

**Federated Identity Management**

**Dorian**
- Successor of GUMS, redesigned to address Federated Identity Management Requirement.
- WSRF compliant Grid service
- Manages user’s Grid credentials
- Enables users to authenticate and create grid proxies via their institution’s Identity Provider (IdP)
- Internal Dorian IdP allows unaffiliated users or small institutions access to the grid.
- Internal Certificate Authority / ability to integrate with existing Certificate Authorities
- Administration Interface
- Configurable/Extensible User Policies
- User Management
- Trusted IdP Management
- Full Client API / Administrative Portal

## Federated Identity Management

## Trust Management

**Grid Trust Service (GTS)**
- WSRF Grid Service
- Provides Support for Managing Trusted Certificate Authorities
- Administrator register/manage certificate authorities and CRLS with GTS
- Client tools synchronize Globus Trust Framework with GTS
- Globus is authenticating against the current trust fabric
- GTS Current Status
- Prototype Development Almost Completed