Vendor Assessment Worksheet:



Similar documents
VISP Vendor Information Security Plan: A tool for IT and Institutions to evaluate third party vendor capacity and technology to protect research data

HIPAA Security Alert

8/17/2010. Over 90% of all compromised merchants are PCI level 4 (small) merchants or merchants with less than 1 million transactions per year

How To Write A Health Care Security Rule For A University

LAMAR STATE COLLEGE - ORANGE INFORMATION RESOURCES SECURITY MANUAL. for INFORMATION RESOURCES

Central Agency for Information Technology

SUBJECT: SECURITY OF ELECTRONIC MEDICAL RECORDS COMPLIANCE WITH THE HEALTH INSURANCE PORTABILITY AND ACCOUNTABILITY ACT OF 1996 (HIPAA)

Implementation Guide

Responsible Access and Use of Information Technology Resources and Services Policy

HIPAA Security Training Manual

Information Technology Branch Access Control Technical Standard

White Paper. BD Assurity Linc Software Security. Overview

Montclair State University. HIPAA Security Policy

Information Security Policy

Catapult PCI Compliance

Supplier Information Security Addendum for GE Restricted Data

Network Security Policy

Estate Agents Authority

Hang Seng HSBCnet Security. May 2016

Server Security Checklist (2009 Standard)

Introduction. PCI DSS Overview

CHIS, Inc. Privacy General Guidelines

Best Practices For Department Server and Enterprise System Checklist


Section 12 MUST BE COMPLETED BY: 4/22

Remote Access and Mobile Working Policy. Document Status. Security Classification. Level 4 - PUBLIC. Version 1.1. Approval. Review By June 2012

IT Security Standard: Computing Devices

Cyber Self Assessment

MUSC Information Security Policy Compliance Checklist for System Owners Instructions

The City of New York

Authorized. User Agreement

How To Secure An Emr-Link System Architecture

PII Compliance Guidelines

Policies and Procedures

Office of the Auditor General Performance Audit Report. Statewide Oracle Database Controls Department of Technology, Management, and Budget

Medical Privacy Version Standard. Business Associate Agreement. 1. Definitions

State of South Carolina Policy Guidance and Training

Credit Card Acceptance Policy. Vice Chancellor of Business Affairs. History: Effective July 1, 2011 Updated February 2013

ensure prompt restart of critical applications and business activities in a timely manner following an emergency or disaster

Wellesley College Written Information Security Program

Security Guide for the BD Remote Instrument Support Solution BD Biosciences workstations

Supplier IT Security Guide

PREPARED BY: AUDIT PROGRAM Author: Lance M. Turcato. APPROVED BY: Logical Security Operating Systems - Generic. Audit Date:

Security Standard: Servers, Server-based Applications and Databases

TASK TDSP Web Portal Project Cyber Security Standards Best Practices

How To Protect Data From Attack On A Network From A Hacker (Cybersecurity)

MIT s Information Security Program for Protecting Personal Information Requiring Notification. (Revision date: 2/26/10)

Question Name C 1.1 Do all users and administrators have a unique ID and password? Yes

MONTSERRAT COLLEGE OF ART WRITTEN INFORMATION SECURITY POLICY (WISP)

Did you know your security solution can help with PCI compliance too?

PCI DSS Requirements - Security Controls and Processes

Network Detective. HIPAA Compliance Module RapidFire Tools, Inc. All rights reserved V

Information Security Risk Assessment Checklist. A High-Level Tool to Assist USG Institutions with Risk Analysis

System Security Plan University of Texas Health Science Center School of Public Health

Access Control BUSINESS REQUIREMENTS FOR ACCESS CONTROL

SUPPLIER SECURITY STANDARD

SonicWALL PCI 1.1 Implementation Guide

NETWORK AND INTERNET SECURITY POLICY STATEMENT

ISAAC Risk Assessment Training

Belmont Savings Bank. Are there Hackers at the gate? 2013 Wolf & Company, P.C.

Information Security: A Perspective for Higher Education

Dublin Institute of Technology IT Security Policy

Credit Cards and Oracle: How to Comply with PCI DSS. Stephen Kost Integrigy Corporation Session #600

How To Protect Your Data From Being Stolen

INFORMATION SECURITY GOVERNANCE ASSESSMENT TOOL FOR HIGHER EDUCATION

Unified Security Anywhere HIPAA COMPLIANCE ACHIEVING HIPAA COMPLIANCE WITH MASERGY PROFESSIONAL SERVICES

e-governance Password Management Guidelines Draft 0.1

Research Information Security Guideline

Policy Title: HIPAA Access Control

CITY OF BOULDER *** POLICIES AND PROCEDURES

FINAL May Guideline on Security Systems for Safeguarding Customer Information

Georgia Institute of Technology Data Protection Safeguards Version: 2.0

This document and the information contained herein are the property of Bowman Systems L.L.C. and should be considered business sensitive.

Nine Steps to Smart Security for Small Businesses

micros MICROS Systems, Inc. Enterprise Information Security Policy (MEIP) August, 2013 Revision 8.0 MICROS Systems, Inc. Version 8.

Database Security Guideline. Version 2.0 February 1, 2009 Database Security Consortium Security Guideline WG

Index .700 FORMS - SAMPLE INCIDENT RESPONSE FORM.995 HISTORY

REMOTE WORKING POLICY

Information Resources Security Guidelines

The Internet and 2 Acceptable use 2 Unacceptable use 2 Downloads 3 Copyrights 3 Monitoring 3. Computer Viruses 3

BSHSI Security Awareness Training

AUDIT REPORT WEB PORTAL SECURITY REVIEW FEBRUARY R. D. MacLEAN CITY AUDITOR

Network Security Guidelines. e-governance

Transcription:

Vendor Assessment Worksheet: A sample set of IT security controls for evaluation of third party vendors capacity to protect institutional research data 1

Table of Contents Executive Summary... 3 Vendor Assessment Worksheet... 4 Network Security s... 4 System security requirements... 5 Operational requirements... 6 Information Collection... 9 Managing Pre-existing Databases... 10 Authors and Contributors... 11 Attribution, Sharing and Adapting... 12 Contact Us... 13 2

Executive Summary This worksheet may be used alone or in conjunction with the Harvard Catalyst Vendor Information Security Plan. This worksheet offers a list of data security controls that institutions may require that vendors or other third parties implement to protect confidential data. As used here, confidential data refers broadly to any data that an institution considers to merit a heightened degree of protection because unauthorized release of the information may present a risk of physical, psychological, or financial harm to an individual. This worksheet was adapted from a Harvard University template for evaluation of systems, servers, technology, and/or platforms holding data classified at a risk of level 3 on a 5 level scale, 5 representing the highest degree of risk. Use this worksheet when your institution or researchers intend to utilize a vendor or third party providing software, service or infrastructure that will hold, analyze, or otherwise persistently process research data. Institutions may present the Vendor Assessment to prospective vendors for completion. Once completed, the vendor or third party returns the Assessment to the institution. It is then be the responsibility of the institution to undertake a review the completed response and manage any further clarifications or negotiation of gaps in understanding of implementation requirements. Institutions are encouraged to establish both baseline research data security standards along with sets of standards and controls adaptable on a project-by-project basis, which adhere to risk based frameworks. 3

1. Network Security s 1.1. must not be directly accessible from the Internet or from open parts of the [INSTITUTIONAL] networks unless the confidential information is encrypted. (Note that use of a VPN concentrator is not considered "direct access.") 1.2. Servers holding [ CONFIDENTIAL INFORMATION OR ALTERNATIVE DATA CLASSIFICATION TERM] connected to any network must run host-based firewalls configured to block all connections to the system other than the specific types of connections needed to perform the approved functions. 1.3. Documented practices must be in place and followed on maintaining the configurations of the host-based firewalls. 1.4. The must be encrypted when it traverses any network (outside of a switch in a secure information center). 1.5. The must never be sent via email except in encrypted files. 1.6. All users needing to transfer the must make use of a secure transfer method. (e.g., Accellion or encrypted email). How 4

2. System security requirements: 2.1. Administrative functions on the SECURE SERVERS or applications that access the information must be logged. The logs should include the identity of the user, the time, and the command executed. 2.2. Generic accounts on systems must be disabled. 2.3. Default passwords on systems must be changed before systems are put into use. 2.4. A mechanism must be in use on SERVERS HOLDING [ CONFIDENTIAL INFORMATION OR ALTERNATIVE DATA CLASSIFICATION TERM] to inhibit attackers guessing passwords (e.g., lockout after multiple bad password guesses). 2.5. A mechanism must be in use on servers or clients to block access to idle sessions (e.g., an application timeout or a locking screen saver). How 5

3. Operational requirements: 3.1. All media (including magnetic media such as portable disk or thumb drives and non-magnetic media such as optical disks or paper) containing the confidential information must be encrypted or secured in a locked container ( e.g., a file cabinet or safe) when not actually in use. 3.2. Where access to systems storing the information from outside of the premises is permitted, there must be a written policy identifying individuals or categories of persons who have permission, and under what conditions ("The remote access policy"). 3.3. Users must only have access to the through their individually assigned (non-shared) user accounts. 3.4. Users' access to [ CONFIDENTIAL INFORMATION OR ALTERNATIVE DATA CLASSIFICATION TERM] or servers must be removed if they no longer have a reason under the access policy to access the information (e.g., they change jobs or leave the institution). 3.5. servers must enforce standard password complexity rules. 3.6. SERVERS HOLDING [ CONFIDENTIAL INFORMATION OR ALTERNATIVE DATA CLASSIFICATION TERM] and the applications that process the confidential information must be designed so that passwords cannot be retrieved by anyone (including system administrators). (This should include a mechanism to ensure that any assigned passwords are changed on initial use.) 3.7. Interactive access to SERVERS HOLDING must be logged. The logs should include the identity of the user, the time, and the function (login or logout). 3.8. The logs should be reviewed periodically to determine if the systems are under attack and that the users are following the documented access practices (e.g., not logging in as root). How 6

3.9. There must be a documented practice, known by the users, to ensure that any possible breach that might put the confidential information at risk is promptly reported to the [APPROPRIATE INSTITUTIONAL OFFICE]. 3.10. The confidential information is not permitted to be stored on any user computer or portable computing device (e.g., laptop, PDA, or smart phone) unless the information is encrypted. 3.11. The appropriate [INSTITUTIONAL OFFICES] must be informed of any plans to have a vendor store or process the confidential information. 3.12. Contracts must be executed with all external vendors who process or store the at INSTITUTION'S direction. 3.13. The contracts must contain specific contract language (approved by INSTITUTIONAL OFFICE) that requires the vendor to protect the [ CONFIDENTIAL INFORMATION OR ALTERNATIVE DATA CLASSIFICATION TERM] and to inform [APPROPRIATE INSTITUTIONAL OFFICE] of any possible breach that may put the information at risk of exposure. 3.14. The contracts must contain specific contract language [APPROVED BY APPROPRIATE INSTITUTIONAL OFFICE] to ensure that the protection of the confidential information meets the requirements in INSTITUTION'S information security policy. 3.15. Controls must meet conditions of institutional contract rider specifications 3.16. All software (operating system and application) patches must be up to date. 3.17. Only the applications that are actually required to support the required services can be running on a SECURE SERVER. 3.18. must be running an appropriate virus checker and the virus checker information files must be updated at least weekly. How 7

3.19. Operators of non-it-managed servers holding must annually certify to [INSTITUTIONAL OFFICE] that they are compliant with the [INSTITUTIONAL POLICY]. 3.20. [INSTITUTIONAL] employees working with any kind of [ CONFIDENTIAL INFORMATION OR ALTERNATIVE DATA CLASSIFICATION TERM] should undergo training in general information security at least annually. 3.21. [INSTITUTION] owned systems should be scanned at least annually to ensure that designated information is stored on the system. 3.22. Implementation of operational requirements is subject to review and audit by [INSTITUTIONAL OFFICES] How 8

4. Information Collection 4.1. Collection of [ CONFIDENTIAL INFORMATION OR ALTERNATIVE DATA CLASSIFICATION TERM] while in the field must adhere to [INSTITUTIONAL POLICY]. 4.2. Computer-based collection of in the field may be done using a VPN connection to a secure server. 4.3 Computer-based collection of information in the field may be done using a computer with an encrypted disk. Information collected in the field must be transferred (by secure means) to systems incorporating appropriate SAFEGUARDS at the earliest possible opportunity, and then promptly and securely deleted from the field device (laptop, digital recorder, etc.). How 9

5.0 Managing Pre-Existing Databases 5.1 Collection of [ CONFIDENTIAL INFORMATION OR ALTERNATIVE DATA CLASSIFICATION TERM] while in the field must adhere to [INSTITUTIONAL POLICY]. 5.2. Computer-based collection of FROM A PRE-EXISTING DATABASE may be done using a VPN connection to a secure server. How 10

CORE WRITING GROUP Last Name First Name Company/ Affiliation Zurba Joe Partners HealthCare Bolt Kris Harvard University Edmiston Scott Harvard Catalyst Winkler Sabune Harvard Catalyst CONTRIBUTORS Recognizing those that contributed specific content, templates or examples that are included within this guidance document: Last Name First Name Company/ Affiliation Aske Jennings Partners HealthCare (formerly) Kane Esmond Harvard University (formerly) Steve Berry Beth Israel Deaconess Medical Center Jason Rightmyer Hebrew Senior Life David St. Clair Boston Children s Hospital 11

ATTRIBUTION, SHARING AND ADAPTING We encourage broad dissemination of this guidance document, and incorporation of these practices into clinical trial operations. We would also appreciate feedback and additional contributions so that we can continuously improve this work product. We encourage you to: request email us and request the materials share copy, distribute, and transmit the work adapt adapt the work to suit your needs Under the following conditions: Attribution: In freely using the materials, we require that you acknowledge Harvard Catalyst as the publisher and that you give appropriate credit to any named individual authors. Suggested citation: This material is the work the Harvard Catalyst Data Protection Taskforce and subcommittee of the Regulatory Foundations, Ethics, and Law Program. This work was conducted with support from Harvard Catalyst The Harvard Clinical and Translational Science Center (National Center for Research Resources and the National Center for Advancing Translational Sciences, National Institutes of Health Award 1UL1 TR001102-01 and financial contributions from Harvard University and its affiliated academic health care centers). The content is solely the responsibility of the authors and does not necessarily represent the official views of Harvard Catalyst, Harvard University and its affiliated academic health care centers, or the National Institutes of Health. With the understanding that: We might contact you: We are interested in gathering information regarding who is using the material and how they are using it. We may contact you by email to solicit information on how you have used the materials or to request collaboration or input on future activities. When reusing or distributing, make clear the above terms: For any reuse or distribution, you must make clear to others the terms of this work. The best way to do this is with a link to the web page containing this guide. When adapting: Please share improvements to the tool back with us so that we may learn and improve our materials as well. 12

CONTACT US Copies of all materials are freely available. Please send your requests, questions and comments to regulatory@catalyst.harvard.edu and visit the Harvard Catalyst Data Protection Subcommittee web page. 13