SECURITY POLICIES AND PROCEDURES PANEL DISCUSSION

1. SECURITY POLICIES AND PROCEDURES PANEL DISCUSSION Joint DSIC, TBPT, CTMS Meeting Natcher Building, National Institutes of Health (NIH) 45 Center Drive, Bethesda, MarylandNovember 29, 2006

2. Session Goals • Examine current security management, policy, procedure assumptions • Clarify where outstanding issues are in major workspaces • Discuss how current architecture and security project data from IRB interviews supports • One to two actionable items if possible

3. Agenda • Key drivers • Frank Manion, FCCC • Tissue Banks • Jack London, TJU • Clinical Trials • Warren Kibbe, Northwestern • Susan Pannoni, CoH • Patient Advocates • Diane Paul • Technology Policy and Trust Management • Bill Weems, UTHSC • Chris Loudon, Federal e-Authentication project/Enspire Technologies • Q&A – 20 minutes • Recap – capture and validate the notes derived from the audience

4. Policy Models • Effective collaboration in a federation requires • Data standards for authentication • Data standards for authorization • Standardization of policy models • All current grids/federations have policy models for • Identity/Certificate issuance (trust fabric maintenance) • Attribute release policies (required for authorization, implication for privacy) • Authorization/Entitlement issuance (conditions and mechanisms for authorization) • Security Incident handling (trust fabric maintenance) • These are being standardized according to policy frameworks for both secure operation and to allow federations to inter-operate • Most built on RFC 2527 • Newer, more robust framework is RFC 3647 reviewed by American Bar Association

5. Policy Decisions • Do we have an appropriate model of authentication • Strong identity vetting across all workspaces? • Same for authorization • Static versus dynamic roles • Are current processes sufficient for binding authorization to data objects • Are current development processes sufficient • Should there be a security/policy review group • Operating models for trust maintenance • Risk assessment • Accountability

6. TBPT Jack London, TJU

7. General caBIG Security Framework • Authentication will be an institutional responsibility. • Authorization will be application and institution specific. • Overall governance will be on a grid level, with institutional participation.

8. TBPT-Specific Security Issues • Currently, mandated security for biorepositories relates to the protection of privacy of the data characterizing the biospecimens, not the biospecimens themselves. • Conceivably the identifying potential of the biospecimen genetic material may lead to future security issues relating to the material itself, as well as the annotation.

9. TBPT-Specific Security Issues • Within an institution, authorization may be a function of the “instance” of an application. • Separate tumor banks often exist within one institution (created and maintained by different departments or investigators). • Different instances of the same application may be necessitated by a need for different authorizations, e.g., • An investigator may be an “honest broker” for his breast tissue bank, but a “researcher” for someone else’s prostate bank.

10. CTMS Susan PannoniCity of Hope National Medical Center spannoni@coh.orgWarren KibbeRobert H. Lurie Comprehensive Cancer Center Northwestern University wakibbe@northwestern.edu

11. Purpose of CTMS WSThe Clinical Trial Management Systems Workspace is developing a comprehensive set of modular, interoperable and standards based tools designed to meet the diverse clinical trials management needs of the Cancer Center community. The tools developed will be configurable to meet the needs of Cancer Centers with little or no clinical data management systemsin place as well as those with robust systems, and will take into account the diversity of clinical research activities and local practices that exist among these Cancer Centers.

12. CTMS Data Considerations • Secure Information Held Locally • Protect Patient Health Information • Protect Scientific Findings until Publication • Traceable provenance and access • Information Distributed on an As-Needed Basis • Protocol Specific Sharing/Export of Data to Cooperative Group, Coordinating Center or Pharmaceutical Sponsor • Regulatory Reporting • Patients are now Active Consumers of Health Care and Research rather than Passive Recipients

13. General caBIG Security Framework • Authentication will be an institutional responsibility. • Authorization will be application and institution specific. • Authorization needs to be data-driven: Roles are dependent on the protocol and the organizational source of the data. Needs to accommodate Pharma, NCI, and cooperative group studies. Protocol Based Security (restrict access to clinicians and research staff involved with the study) Role Based Security (DSMB, IRB, Quality Assurance) Institutional Security (for Multi-Center/Consortium trials) • Overall governance will be on a grid level, with institutional participation. • Centralized Management of Standard Code Lists “Pushed Out” to Adopters of caBIG Modules • Sponsors able to “Push Out” Protocol Information to Eliminate Duplicate Entry and Errors

14. Administration of Identity • Probably will vary from Institution to Institution • Most Larger Institutions have a Division/Department Responsible for Clinical Trials Management • Security for Financial Billing or Protocol Authoring may be Managed by a Different Group • May leverage Shibboleth or LDAP for institutional authentication and authorization

15. Patient Advocates Diane Paul

16. Loose Lips Sink Ships OR HOW COMMON IS COMMON SENSE? Vulnerabilities

17. Vulnerabilities • WHO HOLDS THE KEYS TO THE KINGDOM?

18. Vulnerabilities • WHOSE DATA IS IT ANYWAY?

19. Technology Policy & Trust Management William Weems, UT Health Science Ctr Chris Louden, Enspier Technologies representing Federal Govt. e-Authentication

20. Identity Management for caBIG Identity management (IdM) is critical to the operation of the Cancer Biomedical Information Grid (caBIG) if it is to enable seamless, secure collaborative research among individuals using restricted resources operated by numerous organizations. caBIG member institutions must agree upon a shared trust fabric for identity management. Individuals affiliated with member institutions must have certified identities that permit relying caBIG applications and personnel to • authenticate the certified physical identity of a credentialed claimant • to determine from trusted attribute authorities (AA) if an authenticated claimant has the appropriate identity attributes to • access restricted resources at a defined level of authorization, and/or • provision approved restricted resources with certain identity information.

21. Key Concepts • Two types of identity • Physical identity is unique to only one person (Responsibility of the credentialing authority) • Personal attributes. Each attribute is usually not unique to a single individual. (Generally the validity of these attributes are managed by many sources of authority (SOAs) and systems of records (SORs). They are often referred to as authorization attributes.) Examples • entitlements, • memberof, • roles, • potentially an infinite number of attributes managed by multiple SOAs within and external to an organization..

22. Authentication Credential • Certifies at a known level of assurance (LOA) that the claimant presenting the credential is the certified entity. The certified credential must minimally • Positively identify the certifying authority (CA). • Positively identify a person whose physical identity was vetted • Provide a persistent unique identifier for the vetted person. • Provide a level of assurance that the credential is presentable only by the person it authenticates.

23. Levels of Assurance (LOA) • The extent to which an electronic identity credential may be trusted to actually represent that the individual explicitly identified by the credential is the same person engaging in the electronic transaction with application, service or relying party. LOA is dependent of • trustworthiness of the identity proofing process, and • trustworthiness of the credential management function

24. Authentication Policies & Procedures • Determine if IdM policies and procedures for identity vetting, registration, issuance of authentication credentials, and credential management will be based on an accepted body of standards. Adherence to the U.S. E-Authentication Standards, for example, will permit the use of authentication credentials provided by a number of trusted partners and will greatly facilitate a broad range of research, clinical and administrative collaborative efforts and requirements. • Decide if authentication credentials are to be used solely for access or also for digital signatures (It is recommended that credentials be capable of producing digital signatures.) • Decide if username/password credentials (e.g. E-authentication LOA 2) as well as cryptographic based credentials (e-authentication LOA 3 and 4) will be required. • Define what organization(s) will be the authentication credentialing/certifying authority or authorities.

25. Federal Government Programs • Federal Public Key Infrastructure (FPKI) • High Assurance / Certificate Based Credentials • Federal Bridge Certificate Authority (FBCA) • Common Policy • Criteria Methodology (for Cross Certification) • Substantial Traction • E-Authentication • Federal Identity Federation • 19 agencies, 6 IdPs, 32 enabled applications • Inter-federation pilot with inCommon • Planned demo 12/4 in Chicago Internet2 fall member meeting • SAML product testing, member Acceptance Testing • 67 New Applications planned for FY2007 • Trust Model • Homeland Security Presidential Directive 12 (HSPD-12) • Merges Logical and Physical Access into a single smart card • Required for federal employees and contractors See http://www.idmanagement.gov

26. Federal PKI HEBCA? TAG PMA See http://www.cio.gov/fpkipa

27. E-Authentication Trust Model 2. Establish standard methodology for e-Authentication risk assessment (ERA) 1. Establish e-Authentication risk and assurance levels for Governmentwide use (OMB M-04-04 Federal Policy Notice 12/16/03) 3. Establish technical assurance standards for e-credentials and credential providers (NIST Special Pub 800-63 Authentication Technical Guidance) 4. Establish methodology for evaluating credentials/providers on assurance criteria (Credential Assessment Framework) 6. Establish common business rules for use of trusted 3rd-party credentials 5. Establish trust list of trusted credential providers for govt-wide (and private sector) use See http://www.cio.gov/eauthentication

28. HSPD-12 • Policies / Standards • FIPS 201: Personal Identity Verification of Federal Employees and Contractors • SP 800-79: Guidelines for Certification and Accreditation • Many many more on card interfaces, cryptography, middleware • http://csrc.nist.gov/piv-program/index.html See http://www.whitehouse.gov/news/releases/2004/08/20040827-8.html

29. Q & A

31. Will need alternate/interim policy frameworks for first drafts Suggestions for using Teragrid policies Uses ISO 17799:2005 and RFC 3647 Will point to general policy statements Will not provide “trust” What matters will be what is in, what is not Will need to grapple with the issues of identity management project wide Will need to grapple with assignment of authorization attributes on data objects in the data model Risk assessment methodologies should be used for policy development Policy frameworks and development methods such as ISO/IEC 17799 and COBIT v4 should be used to help define security and policy work Still need broader, cross-domain consensus on a security model or models Convene a cross project working group Recommendations

33. General caBIG Security Framework • Authentication will be an institutional responsibility. • Authorization will be application and institution specific. • Overall governance will be on a grid level, with institutional participation. Note: Within an enterprise, authentication, authorization, and overall governance are often operated in a coordinated manner, by the same administrative unit, with no effort to distinguish among them or to establish clear boundaries between them. On the grid these will certainly be administered separately, often by different organizations that are not accountable to each other, or to a common authority. Decomposing security functions into logically separable activities, then designing security operations and policies in a way that allows sensible interoperation among the different components is substantially more complex than simply extending an enterprise model to a multi-site environment.

34. TBPT-Specific Security Issues • Currently, mandated security for biorepositories relates to the protection of privacy of the data characterizing the biospecimens, not the biospecimens themselves. • Conceivably the identifying potential of the biospecimen genetic material may lead to future security issues relating to the material itself, as well as the annotation. • For example, in forensics, biological evidence (fingerprints or DNA samples) is considered a more reliable identifier than written records. In principle, DNA from a biospecimen could be used to identify the donor as effectively as DNA evidence can be used in forensic analysis. As DNA analysis continues to drop in cost and complexity, it is very likely that concern will begin to mount about the inherent, irremediable identifiability within any biospecimen.