Implementing Security in a Regulated Environment:
Expectations of IRBs and Other Regulatory Groups
Frank J. ManionFox Chase Cancer [email protected]
Thursday October 4, 2007
Outline
Background on caBIG project and development of the current security model
Development of caBIG security from a regulatory perspective
Development of the caBIG™ Security Model
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/
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
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
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
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/
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
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
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
GAARDS Security Infrastructure
From http://gforge.nci.nih.gov/frs/download.php/1416/caGrid-1-0_Users_Guide.pdf
caBIG™ security project - what IRBs want…
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 of Information Model– Security/privacy parameters– Regulatory environments– Supporting technology requirements
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
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
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
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.
Organizational Role of Interviewees
Organizational Role Count
University and IRB legal counsel 3
IRB Director or Chair, or Director of Human Subjects Protection 5
IRB Regulatory Affairs Officer 1
Information Security Officer 3
Hospital Privacy Officer 3
Hospital Compliance Officer 1
University or Research Institution Privacy Officer (supervising Hospital Privacy Officer) 4
University or Research Institution Compliance Officer 3
Institutional Strategic Planning Executive 2
Director of Office of Research, or Vice President for Research 3
Hospital Department Director of Information Services 1
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
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
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
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
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
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
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
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
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