Implementing Security in a Regulated Environment: Expectations of IRBs and Other Regulatory Groups

1. Implementing Security in a Regulated Environment:Expectations of IRBs and Other Regulatory Groups Frank J. Manion Fox Chase Cancer Center Frank.Manion@fccc.edu Thursday October 4, 2007

2. Outline • Background on caBIG project and development of the current security model • Development of caBIG security from a regulatory perspective

3. Development of the caBIG™ Security Model

4. caBIG™ Structure • Domain Workspaces (focused on specific disciplines) Clinical Trial Management Systems (CTMS) Develops a comprehensive set of standards-based tools designed to meet the diverse clinical trials management needs of the Cancer Center community. Integrative Cancer Research (ICR) Produces tools and interfaces for integration between biomedical informatics applications and data. This will ultimately enable translational and integrative research by providing for the integration of clinical and basic research data. In Vivo Imaging (IMAG) Creates and validates tools and methods to extract meaning from and share imaging data. Tissue Banks and Pathology Tools (TBPT) Develops a set of tools to inventory, track, mine, and visualize biospecimen and related annotations from geographically dispersed repositories. • Cross-Cutting Workspaces (focused on defining and achieving interoperability) Architecture (ARCH) Develops the fundamental caGRID platform that supports the analytic tools. caGRID is the underlying network architecture and platform that provides the basis for connectivity, tools deployment, and data sharing between caBIG™ participants. Vocabularies and Common Data Elements (VCDE) Evaluates and integrates systems and standards for vocabularies and common data elements and ontology content development, as well as software systems for content delivery. They also define semantic interoperability, train and provide mentors, and provide guidelines for the adoption of standards and CDE harmonization. • Strategic-Level Workspaces (focused on overarching issues integral to all workspaces) Data Sharing and Intellectual Capital (DSIC) Addresses issues and develops recommendations related to data sharing, patient privacy, intellectual capital, security and other policies related to caGRID as well as other regulatory and proprietary issues. Documentation and Training (D&T) Defines guidelines, processes, templates and tools for developing consistent software documentation and training materials and for fostering mentoring activities throughout caBIG™. Strategic Planning (SP) Assists caBIG™ senior leadership with strategic planning and vision development activities. Modified from https://cabig.nci.nih.gov/overview/howitworks/

5. Issues related to privacy and security are addressed in the Data Sharing and Intellectual Capital Workspace (DSIC WS). • Goal: identify and then propose solutions to potential barriers to data and resource sharing and other collaborative work across the caBIG community • These barriers may arise from law, regulation, institutional policies and desire to protect intellectual property interests • DSIC WS contains about twenty regular participants, and an additional twenty to thirty ad hoc participants, with a wide range of perspectives and expertise • 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. Dan Steinberg JD, in https://cabig.nci.nih.gov/working_groups/DSIC_SLWG/Documents/ HIPAA_Summit_Presentation_v1_09.26.2006.ppt

6. Federation • What is a federation? • An association of organizations that use a common set of attributes, practices, and policies to exchange information about their users and resources in order to enable collaborations and transactions. [InCommon website] • Other (basic technical) characteristics • Resources (data, computation) remain under control of the owner of the same • Strict separation of responsibilities for Authentication from Authorization • One & possibly many directories of people, objects, and other resources involved. • Drivers in caBIG™ • Need to retain local control of resources • HIPAA • Presumed very large ultimate community size • Possible to leverage 3rd party identity credentials by several initiatives • SAFE, CRIX/Firebird FDA 1572 investigator registry • Federal e-Authentication credentials • Possible to leverage campus provided credentials • Perceived requirement from some Centers • Many members with existent Identity Management infrastructures or projects for the same

7. Necessary elements for federations • Common Governance Frameworks • Legal Agreements • Federation structure • Attribute release policies • Operating practices • Common standards • Authentication • Naming • Identity vetting • Technology – SAML, PKI • Attributes • Levels of trust • Certifying authorities • Common Operating Policies and Procedures • Variety of frameworks that may provide guidance • COBIT 4.0 • ISO 17799:2005(E) • Variety of FIPS/NIST publications • Agreement on type of federation • Federations represent a continuum

8. Example Legal Agreements – UT System Federation • UT System IdM Federation Policy Documents • Federation Foundation Documents (Lists all documents with summaries) • Federation Charter • Federation Operating Practices • Member Operating Practices • Federation Attribute Table • Membership Fee Schedule • Federation Membership Agreement • Federation Membership agreement with Exhibit See https://idm.utsystem.edu/utfed/

9. What are the data security and data protection requirements? Requirements regarding data security • Confidentiality: the assurance that data are not made available or disclosed to unauthorized person. • Integrity: ensure data cannot be changed/deleted/altered by unauthorized party/person. • Authenticity: • ensure that the person is the one she claimed to be. • integrity plus freshness. • Accessibility: upon demand (patient) data can be accessed and used by authorized people. • Accountability: actions of a person, especially modifications that she performs on data can be traced. Courtesy Ulrich Sax

10. What are the data security and data protection requirements? Additional data protection requirements when dealing with person related data • Data necessity principle: disclose all person related data of a patient, but not more than the needed data for the treatment. • Context of treatment: person related data of a patient should be disclosed only to the personnel participating in his treatment. • Patient consent: the patient should formally agree on the handling of his person related data. • The guarantee of patient rights: the possibility of rectification, blocking, deletion of his personal data should be offered. Courtesy Ulrich Sax

11. Levels of Assurance • e-Authentication effort (OMB, NIST SP-800-63) defines four levels of assurance (LOAs) as follows: • Level 1 – assertion based, no restrictions on form. Primarily used for session context in anonymous applications • Level 2 – Assertion based, photo id required to register, remote validation with third party information okay. • Level 3 – Cryptographic credentials, photo id, remote validation with third party information okay • Level 4 – Cryptographic hardware base, in person, photo id, two forms of identity

12. GAARDS Security Infrastructure From http://gforge.nci.nih.gov/frs/download.php/1416/caGrid-1-0_Users_Guide.pdf

13. caBIG™ security project - what IRBs want…

14. Some Challenges in Practice – caBIG™ as a Case Study • caBIG™ has enormous scope and (potential) scale • 800-1000 participants, potentially 10’s of thousands of end users. • Constituencies requiring differing levels of authorization and regulatory controls • Clinical Trials – Strong Authentication (hardware based 2-factor), Digital Signatures • Tissue banks and pathology tools – Assertion based identity may be sufficient, HIPAA, Common Rule still and issue, IP Concerns • Integrated Cancer Research – IP Concerns probably predominate, HIPAA may be a factor in some cases • Complex, evolving technology base at or near state of the art • Grid technology, semantic web, etc. • Security technology itself is a area in rapid evolution • Tools vary in: • Complexity • Maturity ofInformation Model • Security/privacy parameters • Regulatory environments • Supporting technology requirements

15. Initial state – circa 2005 • Security viewed as a strictly technical issue • Regulatory issues viewed as legal and application centric issues • Strategic planning group felt federation was essential for future proofing • Variety of standards, but which ones? • Different constituencies had different views of the beast • Grid security, electronic signature, de-identification of PHI from free text, etc. • Patient advocates, clinicians, tissue bankers, basic scientists, etc. • Stronger systematic approach or “engineering process” needed • Evolutionary, not revolutionary

16. Intervening activity • Lead to development in late 2005 of caBIG Security Technology Evaluation White Paper • Too focused on technology use cases • Did, however, recommend development of a security engineering process as part of caBIG™ • Recommendations from the White Paper included: • Develop business-oriented security use & abuse cases • Need input from IRBs, Compliance Officers, Honest Brokers, CIOs and other institutional executives, Bioethicists, etc. • Vet the notion of employing Federated Identity Management • Develop caBIG™ governance policies • Success involves multiple layers (i.e., trust, identity vetting, guidelines, data standards, firewalls, physical security, etc.) • Involve multiple workspaces and stakeholders in policy development • Identify the minimum security requirements from regulatory mandates • Develop a Proof-of-Concept implementation • Consider the maturity of technologies • Consider separating regulated and non-regulated environments

17. caBIG™ Security Program Goals • Subsequent development of project for data gathering • Major goal was to develop a framework for security engineering for the caBIG™ project as a whole • Targeted Cancer Centers which are the initial four adopters of caTIES • Washington University, U. Pittsburgh Medical Center, Thomas Jefferson, U Penn • Focus on involving regulatory and other “business users” at the Cancer Centers • IRB members • Compliance officers • Deliverables: • Capstone governance structure framework and documents • Security refinement processes • Interconnection security agreement (trust agreement) among adopters • Policy and procedures sufficient to operate caTIES at individual Cancer Centers

18. Method • Focused on caTIES as a model project • Four scripted elicitation interview scenarios were developed collaboratively during a 1½ day face-to-face meeting on June 12-13, 2006 by 38 individuals representing a wide spectrum of experts and caBIG™ stakeholders • Scenario questioned focused on Locus of Control, Auditing, Consenting, and De-identification. • Scenarios used as a basis for interviews with 19 regulatory affairs and information security personnel at six cancer centers • Interviews were either done face to face (N=5) or by phone (N=14), recorded, and transcribed.

19. Organizational Role of Interviewees

20. Findings – Governance Issues • Strong desire for a clear, cohesive and empowered governance entity, separate from government or individual centers • Major recurring theme in interviews • Should be a separate legal structure • Functions include • Governance of data exchange • Risk assessment • Audit • Security control • Operations • Consistent with Cobit 4.0, ISO recommendations • Substantial concern over stricter European privacy laws • Up to, and including desire not to partner with caBIG™ if in partnership • Strong desire for risk data to routinely be available to all parties for decision making • Issues of risk asymmetry, financial, idemnification

21. Findings – Application models • Application Models • Application models of security and operational characteristics should be agreed on • Includes personal attributes, authorization inventory and authorization attribute definitions done in a systematic fashion across project working groups • Includes definitions of private versus public data stores • Includes awareness of other types of security exploits such as cross site scripting • Honest Broker System • Trusted third party that acts as a broker, removing identifiers and otherwise brokering transactions • Separate from authentication/authorization functions • Developed, well-vetted in SPIN project • Should be considered as a model for all caBIG™ projects handling de-identified data and “limited data sets” as defined by HIPAA

22. Findings – Auditing/Regulatory Compliance • Auditing • A central auditing authority appears to be needed • Specific tooling, such as unified log analysis tools, are needed to support audit functions. • Regulatory Compliance and Training • Adopter and developer institutions should attempt to agree on a common training set. • Audit retention policy – Very substantial differences between respondents

23. Findings – Specific infrastructure tooling needed to promote trust • Desire to have support infrastructure for regulatory “Credentialing” processes • Registry of caBIG™ security program accredited “participating” institutions • Protocols • Trust and security levels of members • IRB federal certification status • Other metadata • Tools to determine ahead of time who can access what data under what circumstances and where from • Strong authentication was viewed as required • Supports notion of OMB e-Auth • Unaffiliated investigators pose special problems • Define steps & governance needed to allow access to regulated resources. • Special infrastructure possibly needed for compliance certification and authentication credentialing. • An unaffiliated investigator agreement will need to be developed

24. General ongoing challenges • Basic vocabulary • Basic concepts • Legal, technical, governance, processes, security • Particularly concept of service discovery and use • Agreeing on common models at a variety of levels in the architecture • Agreement on scope of “security” • Agreeing on degree of scale and complexity in the system

25. Conclusions to date • In general, project provided a reasonable framework in a variety of areas • A roadmap to secure operations of “production grid” remains to be done • Issue of scale and complexity of the caBIG™ project • Decisions and agreements still needed by the project • Agreement on Federation model • Agreement on business model of governance • Agreement on necessary authentication practices and levels of assurance • Agreement on authorization parameters

26. Current Status • caBIG Security Working Group Formed • Working on common identity standards • Agreed on OMB e-Authentication standards per NIST SP-800-63 • Currently working on LOA-1 agreements • Need input from ISSOs and other stakeholder

27. For more information • caBIG™ Website • https://cabig.nci.nih.gov/ • caBIG™ Security technical evaluation white paper • https://cabig.nci.nih.gov/workspaces/Architecture/caBIG_Security_Technology_Evaluation_White_Paper_20060123.pdf • caBIG™ Security project white papers (8) resulting from inteviews 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

28. Acknowledgements • Robert Robbins - FHCRC • Rebecca Crowley - UPMC • William Weems - UTHSC • Denton Whitney - OSU • Dan Steinberg - BAH/NCI • Marsha Young - BAH/NCI • Wendy Patterson - NCI • Amin Chisti - FCCC • George Mathew - FCCC • Marcia Ransom - FCCC • Dom Olivastro - FCCC