1. Security Working Group George Komatsoulis, PhD. NCI CBIIT Marsha Young, J.D. Booz Allen Hamilton Presentation prepared by: Frank Manion, FCCC William Weems, UTHSC caBIG™ Architecture and VCDE Face to Face Meeting January 29, 2008

2. Outline Current agenda and working groups caBIG™ initiatives for federated authentication and authorization Risk analysis and the caBIG™ Data Sharing and Security Framework (DSSF) Background materials on the SWG and an introduction to the Security infrastructure may be found at: https://cabig.nci.nih.gov/working_groups/DSIC_SLWG/F2F_Meeting s/2008_January/DSIC_F2F_Background

3. Current Agenda and Working Groups

4. Current Status Basic Technical Infrastructure in place – caGrid GAARDS infrastructure Basic decisions to leverage extensive, and growing, OMB/NIST E-Authentication federated infrastructure Supports federation initiatives and multi-institutional workflows Defines four “Levels of Assurance” around individual identity LOA1 essentially is no real assurance of physical identity LOA2 is assertion based – typically user name/password Additional levels require stringent identity checking and two factor components See http://www.cio.gov/eauthentication/http://www.cio.gov/eauthentication/ Security Working Group in place Operating using Security Policies derived from TeraGrid project caGrid Level 1 Host Agreement OMB LOA1 and LOA2 Certificate Practice Statements (CPS). Available at the NCICB GForge site: https://gforge.nci.nih.gov/projects/gridsecurity/https://gforge.nci.nih.gov/projects/gridsecurity/

5. Short Term Agenda: October ’07 to March ‘08 Focused on Rolling out caBIG™ IdM and Authorization Federated Services and Resources Key Tasks Describe a Governance Model that creates & manages policies, procedures and administers caBIG™ federated activities and systems. Operationalize minimum risk level data security policies & procedures – proceed with plans to provide interested parties with OMB LOA 1 credentials. Map Security Policy Project Recommendations to SWG Agenda to ensure all are considered and disposed of (approved, revised, disapproved) Develop policies & procedures for low to medium sensitivity data Authentication/identity management issues Authorization/privilege management issues: Determine a privilege management infrastructure for authorization including study and definition of required workflows.

6. SWG Working Groups Working GroupInputsOutcomesDeliverables Governance Model for Authentication Various Federation Operating Agreements UT, NIH inter-federation, E- Authentication, SAFE, Federal Bridge Certification, InCommon Silver Agreement Trust agreement template Legal basis for authentication agreements Member operating practices caBIG Federation policy document and governance model Model trust agreement for inter- federation LOA2 Technical Implementation and Procedures Trust Agreement Developers guide to integrating an identity provider to Dorian (caGRID) Integrate caGRID with several institutions willing to express LOA2 credentials Working Level 2 pilot at OSU and UTHSC Mapping of Security Policy Project to SWG Agenda Policy Project Recommendations SWG short term agenda Mapping document Changes to Short term agenda Identification of long term requirements Mapping Document Authorization Procedures for LOA1 and LOA2 DSIC case studies Deliverables 10-11 DSIC Data sharing framework caBIG data sharing problems analysis matrix Authorization Procedure documents for LOA1 and LOA2 Mapping of the DSIC data sharing framework to appropriate authorization requirements Trust Agreement for Authorization

7. SWG Subgroup 4 – Authorization Provisions DocumentProvisionCommentsConditionsIssues Data Use Agreement RecipientLegal entity/agent receiving dataLOA2+Recipient data for academic institutions Recipient data for hospitals Authorized AgentPerson authorized to bind the legal entity. Recipient/someone else LOA2+Authorized agent data for academic institutions Authorized agent data for hospitals Mechanism of access How will the data be accessed by/transferred to the recipient LOA2+caGrid, API, ftp, direct transfer Data use paradigmUnrestricted, research only, specific research project LOA2+Unrestricted use, research only use, project specific use Specialized restriction information Additional information if data use paradigm is "specific research project" LOA2+Project description Intellectual Property Provisions IP constrained data Redistribution Provisions To whom may the data be transferred, other than the recipient above No redistribution, No restrictions, Specific individuals Common RuleAcceptance of common ruleHuman subjects HIPAAAcceptance of HIPAALOA2+ IRB approval certification Where neededHuman subjects Security Provisions for locally stored data Varies by level, should involve physical and data level controls By LOALevel 1 Level 2, etc. Signature blocksLOA2+

8. Technology and Federation

9. Security 101 Security is conceptually built on layers in at least three spaces Policy Procedure Technical implementation Example: IHE Defined Policy Environment Material derived from the IHE IT Infrastructure White Paper, 2007 draft, available at http://www.ihe.net

10. Security 101 caBIG™ defined legal and policy requirements related to privacy and security drivers include HIPAA Privacy Rule HIPAA Security Rule The Common Rule for Human Subjects Research FDA Regulations on Human Subjects 21 CFR Part 11 State and institutional requirements

11. Technical security and privacy is achieved by a combination of controls in the following dimensions: Accountability – audits, logs, reporting, alerting, alarming Identification and Authentication – proof that a system or person is who they say they are Access or Authorization controls – limits authenticated entity to authorized functions Confidentiality controls – e.g. encryption for sensitive information Data Integrity controls – i.e. protection against unauthorized modification Non-Repudiation controls – disallows refutation of an act Patient Privacy Controls – Enforce patient/subject specific instructions Availability controls – backup, replication, etc. Security 101 Material derived from the IHE IT Infrastructure White Paper, 2007 draft, available at http://www.ihe.net

12. Identity in Cyberspace Physical Identity - is unique to only one person or entity. (Its certification is the responsibility of a certifying/credentialing authority) Facial picture, Fingerprints Retina Scan Identity Attributes – are a time-varying set of attributes associated with each unique individual. Common name, Address, Institutional affiliations - e.g. faculty, student, staff, contractor, Specific group memberships requiring certain attributes, Roles, Etc. Two Kinds of Identity

13. Authentication 1.Can only be activated by the certified person, 2.Positively identifies the physical claimant, 3.Positively identifies the certifying authority (CA) – i.e. the identity provider (IdP) 4.Provides a certified unique identifier issued to the vetted individual and registered with the CA, and 5.Asserts a defined level of assurance (LOA) that the credential is presentable only by the person it authenticates. An Authentication Credential when presented to a relying Party

14. Authentication: Levels of Assurance Federal E-Authentication Initiative http://www.cio.gov/eauthentication/ http://www.cio.gov/eauthentication/ Levels of assurance (Different Requirements) Level 1 – e.g. no identity vetting Level 2 - e.g. specific identity vetting requirements Level 3 – e.g. cryptographic tokens required Level 4 – e.g. cryptographic hard tokens required Credential Assessment Framework Suite (CAF) Federal Bridge Certification Authority (FBCA) http://www.cio.gov/fbca/ The FBCA is an information system that facilitates an entity accepting certificates issued by another entity for a transaction.

15. GAARDS Security Infrastructure

16. Inter-Federation Project NIH and the University of Texas Identity Management (IdM) Federation will develop an inter-federation agreement at LOA 2. NIH will rely on the GSA E-Authentication Credential Assessment Framework (CAF) as the standard for determining whether the UT Federation SAML assertions meet OMB Level 2 NIH and UT will agree how and by whom the CAF assessment will be preformed. Upon successful completion of an NIH/UT agreement, efforts will be made to develop similar inter-federation agreements with other federations such as InCommon Develop and test an open-source interface for sending SAML assertions between and an institutional Shibboleth identity provider (IdP) and DORIAN

17. Authorization Process of determining if an authenticated person qualifies to conduct certain activities in cyberspace. 1.A relying party obtains from a SOA certain attributes to determine if an authenticated claimant qualifies for certain privileges. 2.The source of authority (SOA) “knows” the certified identifier of an authenticated person. 3.The SOA verifies that the identified person has certain attributes. 4.Upon verification of the required personal attributes, the relying parting authorizes the authenticated claimant to conduct the desired activities.

18. Source of Authority (SOA) Knowing the certified identifier of a person of interest Following defined policies and procedures required to assign or verify specific personal attributes Maintaining records of personal attributes Determining if an attribute is currently valid Providing relying parties with information about specific attributes of an identified individual. A trusted entity responsible for assigning to and/or verifying defined attribute values to a person. The SOA is responsible for

19. Authorization Polices & Procedures Designated Sources of Authorities (SOAs) and Sources of Records (SORs) for personal attributes. Specific personal attributes and allowed values required for authorization decisions. What constitutes an acceptable certified identifier of physical person. How physical identity is reconciled when SOAs use different identifiers for the same individual. How attribute values are managed – i.e. assigned, verified and altered in a timely fashion by an SOR. A community of relying parties that has a common operational context requiring “trusted” authorization of individual activities must agreed upon policies and procedures that define

20. Authentication/Authorization Interactions

21. Selecting Appropriate Authentication/ Authorization Controls Authentication - Levels of Assurance (LOA) LOA provides some idea of the risk that a claimant other than the certified physical person may have authenticated to a system. How thoroughly was physical identity vetted by the credentialing authority? Was the activator (e.g. password) of the credential actually given to the vetted person? How easy is it for others to use the credential of someone else? Authorization – Areas of Risk Specified and validated SOA, SOR and privilege management processes provide some idea of the risk that inappropriate authorizations may be granted to correctly authenticated individuals. Do all relying parties use the same identifier for the same physical person? If no, how good is the identity process? Do all SOAs and SORs use standard processes and well defined attribute sets and values? What level of authentication is required to assign attribute values or system privileges.

22. caBIG™ Data Sharing Framework

23. caBIG™ Data Sharing and Security Framework

24. Understanding the Framework Purpose of the Framework Determine which data can be shared Identify necessary access and data security controls (authentication, authorization) Audiences IRBs Privacy Officials Industry-Sponsored Projects/Grants & Contracts Administration/Tech Transfer Officers Institutional Attorneys Function (Summary) Assess data sensitivity by reference to the Framework’s four principal elements: Privacy Considerations IRB/Ethical Restrictions Proprietary Value (to Researcher/Institution) Sponsor Requirements Assign a low, medium or high sensitivity rating to the data Use sensitivity assignment process to determine what data will be shared and the appropriate mechanism for sharing

25. Data Sharing in the Green Lane Minimum Restrictions on Access Provider/Grid Host (individual or institutional) must: No authorization conditions on users and therefore no contract (MTA, DUA, etc.) required Enter into the LOA1 NCI-caGrid Host Agreement – agree to Only make non-sensitive data available through NCI-caGrid Operate in accord with fairly common security practices -- apply patches for known/published “bugs” or prevent known security attacks Recipient/Grid User must : Accept General Website Terms of Use Authenticate to LOA1 or LOA2 of the NIST Guidelines

26. Data Sharing in the Yellow Lane Standardized Click-Through Terms and Conditions: Some Limitations on Access to the Data Provider/Grid Host must: Enter into a trust agreement – in development Adopt model caBIG™ standardized click-through agreement that specifies some restrictions on data sharing – in development Define required user qualifications for specific authorizations Recipient/Grid User must: Agree to terms of standardized click-through agreement Enter into an agreement with NCI or 3 rd party authentication certificate provider concerning authentication (NIST LOA 2 or 3) – in development Meet defined qualifications to be authorized for specific access

27. Data Sharing in the Orange Lane More Restricted Access Conditions: Could be Standardized or Individually Negotiated Agreement Provider/Grid Host must: Enter into a trust agreement – in development Specify restrictions on data sharing in model caBIG™ standardized terms and conditions OR adapt institutional agreement to adhere to caBIG™ standards/guidelines for negotiating such agreements – BOTH in development Define required user qualifications for specific authorizations Recipient/Grid User must: Agree to Provider/Grid Host’s terms and conditions (adopted or adapted) Enter into an agreement with NCI or 3 rd party authentication certificate provider concerning authentication (NIST LOA 3 or 4) – in development Meet defined qualifications to be authorized for specific access

28. Questions?

29. For more information caBIG™ Website https://cabig.nci.nih.gov/ caBIG™ Security Working Group https://gforge.nci.nih.gov/projects/gridsecurity/ caBIG™ Security technical evaluation white paper https://cabig.nci.nih.gov/workspaces/Architecture/ caBIG_Security_Technology_Evaluation_White_Paper_20060123.pdfhttps://cabig.nci.nih.gov/workspaces/Architecture/ caBIG™ Security project white papers resulting from interviews with regulatory personnel at six cancer centers http://gforge.nci.nih.gov/projects/secprgmdevl/ Initial problem scenarios used for scripted elicitation interviews Requirements analysis Report on Technical Implications Policy compliance report Trust agreements for use in federation Policies for Authentication and Authorizations Standards procedures for signoff on use of caTIES by IRBs Security operations conceptual document Proposed Governance frameworks

30. QUESTIONS QUESTIONS??????