SDHS Security Policy March 2017 – February 2019
1. SDHS Overview
The purpose of this security policy is to outline the Clinical School’s Secure Data Hosting Service (SDHS) and general working practices in handling sensitive data. The SDHS is designed to ensure that highly sensitive information, required by research groups at the Clinical School, is secure from unauthorised modification or disclosure, either accidental or deliberate, and that the storage of this data complies with all required regulations.
Note that there is an accompanying SDHS Technical Design document.
It has been developed, implemented and managed by the University of Cambridge.
It is for use by Clinical School research groups.
Authorisation to use the service is provided by the Information Governance Officer (IGO).
Queries on School Policy for existing studies must be addressed to the Information Governance Office in the Clinical School – firstname.lastname@example.org
The IT infrastructure is provided by the Clinical School Computing Service (CSCS).
The policy structure has been agreed by the Cambridge University Data Protection Officer and the Addenbrooke’s (Cambridge University Hospitals NHS Trust) Data Protection Officer.
All data is managed in accordance with the Data Protection Act 1998. The University of Cambridge is registered under the Act, registration number Z6641083.
To demonstrate a clear commitment to information security management, the Secure Data Hosting System has been certified as ISO 27001 compliant, which is the international standard for information security management. This requires that CSCS management:
– Systematically examines the organisation’s information security risks, taking account of the threats, vulnerabilities, and impacts.
– Designs and implements a coherent and comprehensive suite of information security controls and/or other forms of risk treatment (such as risk avoidance or risk transfer) to address those risks that are deemed unacceptable.
Adopts an overarching management process to ensure that the information security controls continue to meet the organisation’s information security needs on an on-going basis. The standard CSCS Acceptable Use Policy is applicable to the SDHS.
The Security Managers (SMs) within CSCS are the Head of Department and his nominated deputies in the CSCS Management Team. They are responsible for ensuring that all operations undertaken by CSCS staff on the SDHS are in accordance with this Policy.
The identities of the SMs will be recorded in the service documentation.
Each research group using the SDHS will require an authorised Chief Investigator (CI), who:
- Must be an employee of the University of Cambridge.
- Approves at least one Data Manager (DM) for a study.
- Acts on behalf of, or appoints a replacement DM, if the original DM is not available.
Each research group using the SDHS will require at least one authorised Data Manager (DM), who:
- Is the recognised point of contact between the Research Group and the IGO in the area of confidential data. Is the recognised point of contact between the Research Group and CSCS in the area of confidential data.
- Is responsible for ensuring the working practice of the study conforms to this Policy.
- Is responsible for requesting any desired exceptions to this Policy
2. Applications for existing studies
Applications for existing studies must be reviewed and approved by the School IGO before being passed to CSCS for consultation.
CSCS will report to the IGO if there are concerns arising from the consultation.
CSCS will provide written confirmation upon successful implementation of the SDHS.
3. Applications for new studies
Applications for new studies must be approved by the IGO before being passed to CSCS for implementation.
CSCS will report to the IGO if there are concerns arising from the implementation.
CSCS will provide written confirmation upon successful implementation of the SDHS.
4. Clarifications and exceptions to Policy
If the DM or CI believes a study’s working practice is inadvertently or unjustly impacted by the technical implementation of this Policy, they may make a written request for clarification from the SM.
It will be decided by the SM whether the implementation is appropriate to the Policy.
If judged inappropriate, CSCS will review the implementation with the IGO.
If decided appropriate, the SM / CI may decide to request an exception to the Policy.
Exceptions to the policy will be decided upon by a member of the SM and a member of the Information Governance Office.
SDHS System Design
5. Authentication to the SDHS
Authentication and access to the SDHS is provided via unique, individual University user accounts. These accounts are managed by CSCS.
Authentication into the SDHS working environment will be by two-factor authentication. It is the end user’s responsibility to ensure that the authentication key fob supplied by CSCS is kept safe and protected from theft, loss or damage
A research group requiring access to the SDHS must be first authorised by the IGO, who will provide written authorisation. The CI / DM will then contact CSCS. CSCS staff are not permitted to add new studies to the SDHS without this authorisation.
Changes in access to the SDHS, e.g. a new member of staff requires access for an existing research group, must be authorised by the DM or CI. CSCS will only accept instructions to carry out the changes from the DM or CI.
Access into the SDHS must only be done by CSCS approved methods (see technical design for details). Circumvention of these methods using other services is forbidden.
6. Data Storage within the SDHS
All personally identifiable research data collected as part of a research project should be stored within the SDHS. The only exception is a list of names and addresses/email addresses required for the sole purpose of communicating with participants. Prior agreement must have been given by the IGO and it must be within the terms of the approved project protocol. This information must be kept separately from all other research data.
The decision to designate research data as appropriate for the SDHS is done by the CI / DM in conjunction with the IGO. CSCS will not provide advice in these decisions.
Anonymised data should be located on the normal data storage but it is expected that for practical reasons, some anonymised data will be stored in the SDHS.
CSCS is responsible for the provision of data storage within the SDHS. Storage is logically allocated to research groups as requested.
CSCS are responsible for setting security permissions so that research staff may have access into group level storage areas.
Within a group-level storage area individual file permissions may be managed by the DM who has specifically requested this ability
CSCS will assist the DM where required.
The permissions of CSCS must not be altered or removed.
Patient identifiable information should be separated from research data and a link only made where clinically important information needs to be passed to a participant or their doctor as set out in the approved ethics application and protocol.
In limited circumstances sensitive data may be temporarily stored on a computational server also attached to the SDHS network. This is done only as part of an agreed working procedure specific to the research study.
7. The SDHS infrastructure
The SDHS is provided using logically separate servers, storage and networking.
Devices added to the SDHS infrastructure must be authorised and managed by CSCS.
The SDHS networks are protected by a firewall which restricts network access into and out of the SDHS. The firewall is managed by CSCS. The default position is to deny all network traffic in both directions.
Firewall rules are approved by the CSCS in consultation with the IGO.
Web filtering is applied to the SDHS network such that websites that represent a security risk are not accessible.
8. Computer Access
Only approved access methods may be permitted to be used with the SDHS.
CSCS provides a Citrix-based remote virtual computer to access the SDHS Network. This is the default method of access for all users.
It is not necessary for the local computer to be managed by CSCS, however;
– The user should ensure they have a private workspace when viewing PID.
– The user should be sure that the computer has up-to-date security (OS patches, anti-malware, etc) as any malware infection increases the chance of data loss e.g. by screen capture, keystroke capture.
– Data cannot be transferred from the virtual computer to the local computer.
If limitations inherent in remote working are deemed to hinder or prevent a user from performing their work, then a consultation with CSCS to determine possible workarounds will occur.
For all workarounds, CSCS, the IGO and the CI / DM will determine a new working practice that is achievable using remote access and agree a timescale for adoption.
9. Data Flows in and out of the SDHS Network
Data must flow in and out of the SDHS environment by approved methods (the CSCS external access exceptions process) only.
Data that has been anonymised by study co-ordinators can be published onto the standard Clinical School IT infrastructure for access by researchers for normal analysis.
There will be no direct access between the SDHS network and the standard network.
Publishing to the standard network must be via a Transfer Service to reduce the risk of accidental publishing of PID.
By default, there will be no internet access from the SDHS Network. Studies can request exceptions to this to support data flows by submitting a SDHS Amendment. Any exceptions will be reviewed by both CSCS and the IGO to ensure that they do not invalidate any controls on integrity or confidentiality. All external access from the SDHS networks is monitored.
CSCS will manage secure mechanisms for initial data imports into the SDHS.
CSCS provide a Transfer Service that can be used to import and export data from the SDHS. This service can be used by both External Collaborators to supply data to studies, and by SDHS Users for the export of anonymised data. All data transfers are logged.
10. Restrictions on the use of SDHS Virtual Desktops and Applications
As the SDHS has been designed to provide to a secure area to store sensitive data, including Personally Identifiable Data, CSCS rightly treat the security of such data with the highest regard.
There is no ability to access any resources not contained within the SDHS unless an Exception has been granted.
By default, there are no printing facilities from within the SDHS. DM may request an exception to this.
If customers do wish us to add SDHS printing facilities via CSCS-managed print servers to on-site network printers, then as part of the application, CSCS will require a suitable business justification as to why this it is required.
Printers used to print PID must be suitably private and have appropriate policies governing their use. Key points that should be considered are:
- Business need – Are printing facilities actually required and justifiable?
- Location of printer – is it in either a secure or high visibility location?
- Working practices – advise staff to ensure that they collect their printing immediately or considering whether you can work on a delegated print release
Data should not be moved or copied between virtual computers and local computers; this includes files, clipboard data, screen captures or video / audio recordings.
A limited number of applications are available in the SDHS environment. Applications must be approved and published by CSCS. Not all applications are suitable. If you would like an application included, you should submit a request to the CSCS Service Desk, where your request will then be reviewed for suitability for processing PID and their suitability to operate within the SDHS environment.
Access to Virtual Computers requires two factor authentication and CSCS provide a two factor authentication token for this purpose.
Virtual Computers will lock after 15 minutes of inactivity, and will require re-authentication to unlock.
The NHS.net email system is designed to handle sensitive/identifiable data and should be used wherever possible if staff have access to an NHS.net email account. It can be used to receive and send sensitive/identifiable data to any appropriate source or destination under the terms of the research project.
If NHS.net e-mail is not available to researchers, then the SDHS Transfer Service is provided to fulfil this function.
In the exceptional case that PID has to be transferred via the Clinical School e-mail system it must be approved by the IGO and must be in line with the approved protocol. Any data sent this way must be with the agreement of the relevant NHS trust and it MUST be encrypted in line with NHS and NHS Digital guidance. Any request to do so will be added to the CSCS risk register
Consenting volunteers may email their own information to a Clinical School email address providing prior agreement has been arranged under the terms of the research project.
Sensitive data stored as plain text in emails should be recorded appropriately by the researcher, before being deleted and expunged.
Emails containing participant identifiable data must not be copied, or saved, from the University email systems onto personal data storage (e.g. laptop, USB stick or a mobile phone).
Received email attachments containing participant identifiable data must be removed – either deleted or imported into the SDHS through the Transfer Service.
12. Sharing data files with collaborators outside of the Clinical School
The distribution of data files, containing sensitive/identifiable information, to external collaborators must only be performed using a secure method of transfer, such as Transfer Service provided by CSCS.
External collaborators can access the Transfer Service through either a web interface over HTTPS or through an SFTP interface.
Studies can define the directory structure that they would like to apply to the Transfer Service. Directories can be created to separate off functions or practices, and users can be granted access to one or more directories. Access to directories must be explicitly defined by the Data Manager for both SDHS Users and External Collaborators. By adopting a fine-grained approach studies can control the ingress and egress of data according to users.
The transfer server should not be used to store data for long periods of time, and CSCS implement measures to ensure that data is not retained for long periods of time.
Data files uploaded to the Transfer Server will be automatically checked for viruses.
If data being exported from the SDHS contains PID/sensitive information, it should be encrypted to a suitable level. Both SDHS Users and External Collaborators should only decrypt PID on an NHS IGT certified ‘Safe Haven’ or equivalent environment. This requirement should be included in any relevant data transfer agreement or collaboration agreements
13. Password Policy
An enhanced password policy shall apply to all users of the SDHS service, including both SDHS Users and External Collaborators. This policy enforces the following characteristics:
- Minimum password length is 15 characters with complexity
- Password history is enabled, with a setting of 1 (users cannot reuse the same password consecutively, but can reinstate a password following IT reset).
- The lockout threshold is 4 failed login attempts within a 30-minute period. If a lockout is triggered, then the account will be locked out for 30 minutes.
Users can request a password reset via the CSCS service desk.
External collaborators can request password reset via the email address they have been registered with by the Data Manager
14. Methods of Encryption
Sensitive data may be protected by encryption.256bit AES is the minimum standard of encryption to be used in all cases. CSCS have best practice advice on data encryption to cover requests to encrypt data in the SDHS. It is the user’s responsibility to use appropriately complex encryption keys.
It is the user’s responsibility to securely store the encryption keys. Loss of the encryptions keys render the data unrecoverable and disclosure of the keys to unauthorised users may jeopardise the confidentiality of the data.
15. System Protection
All electronic data stored within the SDHS study group drives is replicated to an off-site location according to a schedule.
Access to the CSCS Main Server Room is managed in a controlled manner to ensure that an appropriate level of security is maintained at all times. All visitors requiring access to the MSR must follow the CSCS procedure.
16. System Audits
The CI / DM must inform the IGO and CSCS of employees that should be removed from the SDHS service.
The CI and/or DM must ensure that only users with a valid reason to have access to the SDHS and the Study Data. It is the CI and/or DM’s responsibility to ensure that the access list for a study is promptly updated in the event of staff changes. This includes both SDHS Users and External Collaborators.
CSCS reserves the right to remove user’s access if the CHRIS system indicates they have left the University.
The IGO may audit the group storage areas to ensure that access is limited to the correct individuals and that data is being used in line with the original REC application received for the study.
The SDHS design shall be risk assessed every 12 months.
The ISO:27001 certification of the CSCS Information Security Management is assessed annually by an external auditor. A recertification audit is required every third year.
Internal audits of the SDHS will be carried out periodically according to the agreed audit schedule. Risk assessment are performed when considering any change or when changes are imposed upon the system or service.
CSCS will arrange penetration testing of the SDHS by a third party to verify its effectiveness. A retest will be arranged following any significant change to the service.