1. Thursday, April 27, 2006 Development of caBIG™ Security Program Presentation to Cooperative Groups Teleconference April 27, 2006 Frank J. Manion, M.S.

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

3. 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

4. 4 Proposed Conceptual (“Notional”) Architecture Courtesy of Kenneth Lin, BAH

5. 5 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

6. 6 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

7. 7

8. Thursday, April 27, 2006 Whitepaper Recommendations

9. 9 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™ 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)

10. 10 Security Whitepaper Policy & Regulatory Recommendations Develop caBIG™ 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

11. 11 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

12. 12 Example Security Architecture – SAFE From caBIG™ security whitepaper

13. Thursday, April 27, 2006 caBIG™ Security Program

14. 14 caBIG™ 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

15. 15 caBIG™ 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

16. 16 caBIG™ 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

17. 17 Trust Establishment & Maintenance Issues User 1 User 2 Identity & Authorization Mapping Trust Protocols Graphic from CERN Trust Operations

18. 18 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

19. 19 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)

20. 20 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

21. 21 Security: What are some of the challenges? 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

22. 22 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?

23. 23 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?

24. 24 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?

25. 25 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?

26. 26 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?

27. 27 Security Engineering Process   ()()

28. 28 Security Engineering Process (cont) ()()  

29. 29 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

31. Thursday, April 27, 2006 Identity & Authorization Management Section

32. 32 IdAM Operating Model Courtesy of Kenneth Lin, BAH

33. 33 Identity & Access Control Framework Courtesy of Kenneth Lin, BAH

34. 34 caBIG V0.5 Identity Management Architecture Courtesy of Kenneth Lin, BAH

35. 35 Authentication Notional Architecture Courtesy of Kenneth Lin, BAH

36. 36 Authorization Notional Architecture Courtesy of Kenneth Lin, BAH

37. 37 Proposed Conceptual (“Notional”) Architecture Courtesy of Kenneth Lin, BAH

38. 38 Proposed Federation for Authentication Courtesy of Kenneth Lin, BAH

39. 39 Proposed Federation for Authorization Courtesy of Kenneth Lin, BAH

40. 40 Misc. Slides follow, no order

41. 41 Definitions & Key Concepts (Ian Foster) 1.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. 2.… 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 standard and open. Otherwise, we are dealing with an application specific system. 3. … 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. 4.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.

42. 42 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).

43. 43 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.

44. 44 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

45. 45 Following on the Extreme Boundary Conditions 21 CFR 11 HIPAA Public 21 CFR 11 HIPAA Public Policy Filters

46. 46 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

47. 47 Federated Identity Management

48. 48 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