SRCPS User Security Policy¶

Secure Research Compute Platform Services (SRCPS) provide a secure private tenanted cloud platform for the storage and processing of level 3 confidential data as defined by the Universities approved information security classification.

SRCPS is a limited scope organisation that sits within University Information Systems (UIS).

To demonstrate a clear commitment to information security management, the Secure Research Computing Platform (SRCP) is ISO 27001 compliant, which is the international standard for information security management. This requires that SRCPS 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 platform is overseen by a governance group consisting of the Head of Research Computing, The UIS Chief Information Security Officer, a representative of the Research Governance office at the Clinical School and Academic representatives.

All members of the Clinical School should first read the Clinical School’s Secure Data hosting policy and gain authorisation from the Clinical School Information Governance Office (IGO) before approaching SRCPS.

Each Tenancy provisioned on the SRCPS will require a Client who:

Must be a member of the University
Has overall responsibility for the use of the tenancy ensuring any relevant Information governance is being considered and adhered to.
Either approves all user access or delegates approval to a named trusted Data Manager.
Is responsible for ensuring all relevant Information governance training is undertaken by users of the tenancy.

Authentication to the SRCPS¶

Authentication and access to the SRCPS is provided via unique, individual University user accounts. These accounts are managed by SRCPS.

Authentication into the SRCPS working environment will be by two-factor authentication. The user will be issued with a second factor authentication via their mobile device (e.g mobile phone or laptop). It is a user’s responsibility to inform the SRCPS if the device is lost or stolen via the SRCPS service desk.

A research group requiring access to the SRCP must first undertake a risk assessment process to identify whether the controls on the platform are suitable and sign off on residual risk.

Changes in access to the SRCPS, e.g. a new member of staff requires access for an existing tenancy, must be authorised by the Client or Platform Manager. SRCPS will only accept instructions to carry out the changes from the Client or delegated Platform Manager.

Access into the SRCPS must only be done by SRCPS approved methods (see remote access below). Circumvention of these methods using other services is forbidden.

Data Storage¶

SRCPS is responsible for the provision of data storage within the SPRC. Storage is logically allocated to tenancies as requested.

SRCPS are responsible for setting security permissions as requested by the Client or Platform Manager 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 Platform Manager who has specifically requested this ability SRCPS will assist the Platform Manager where required.

The permissions of SRCPS Staff must not be altered or removed

The SPRCPS Infrastructure¶

SRCP Platform - The SRCP platform is a collection of modules and software components, plus a specific configuration that works together to provide the required functionality
Shared service - Shared services are Internal or external services used by the SRCP platform (e.g. authentication, authorisation).
The OpenStack platform - The OpenStack platform is defined as the collection of software, services, tools, and related hardware that create together a Cloud Operating system that controls large pools of resources.

Network segregation as employed by SRCP and in the wider network of WCDC Data Hall 1 is achieved through the use of VLANs; virtual network broadcast domains that are isolated from one another at the data link (layer 2) level of the typical OSI network model. VLANs are defined on core and top of rack switches and server network interfaces such that, although traffic on different VLANs may pass through the same sets of switches, these traffic flows do not interact except at pre-defined points of crossing.

The list of VLANs in use inside WCDC Data Hall 1 can be separated into those that are intended for administrative or otherwise non-user facing purposes and those that are intended to be networks visible to and used by groups of users, who may be academic staff or students of the University or external users drawn from academic or commercial entities.

Further segregation in the context of SRCP project environments is achieved by the use of VXLAN tunnels and VXLAN VNIs. A single VLAN is nominated on the OpenStack platform for the use of tunnelled user project networking traffic in the form of VXLAN tunnels, and OpenStack private networks created within this VLAN as VXLAN VNIs. VNIs use a numeric identifier similar to the VLAN identifier, but larger in size. The use of a VXLAN VNI per private network used by SRCP or on the wider OpenStack ensures that SRCP project networks are kept completely isolated from one another, despite passing through the same network infrastructure.

In segregating networks in use by SRCP, an SRCP Network or other Operator will only ever be expected to interact with VXLAN VNIs. The underlying physical VLAN configuration on core and rack network switches and network interfaces on OpenStack servers is fixed and will not need to be changed for the lifetime of the platform. The one exception to this may be in the rarer case that an SRCP project network requires access to physical resources in the data centre that are not directly governed by OpenStack, such as external data storage facilities. This will require making additional VLANs (termed Provider VLANs) available to OpenStack and also on the core and rack network switches

Remote Access Policy and Teleworking¶

Only approved access methods are permitted to be used for the SRCPS. Access to the platform from outside of the CUDN is only allowed via VPN. SRCPS documentation sets out how VPN connectivity is to be operated https://docs.hpc.cam.ac.uk/srcp/ <link to come>

It is not necessary for the remote device (defined as any laptop, tablet or PC) to be managed by SRCPS, however;

SRCPS requires users to be responsible for the deployment of firewalls, anti-malware software and automatic updates on remote devices that they use to connect to the SRCP, all of which should be up to date.
SRCPS requires users to be responsible for the associated risk of connecting from public networks and to act with care in public places to avoid the risk of screens and confidential notebook computer activity being overlooked by unauthorised persons.
SRCPS requires users are responsible for the deployment of the usernames and passwords on their machine. Passwords should follow the guidelines in the password section below.
SRCPS users are required to follow their departmental teleworking policy.
SRCPS users will connect to SRCP information processing systems using secure encrypted connection as defined in the SCRPS user documentation – https://docs.hpc.cam.ac.uk/srcp (functionality to come in phase 2).

Malware Controls¶

All SRCPS Users should complete the Cyber-Security Training Moodle course as described here. Completion of this is to be checked and logged by the Lead Client.
SRCPS Users managing their own device are advised of the availability of anti-malware from the University - as described at https://help.uis.cam.ac.uk/service/user-accounts-security/security/antivirus - and made aware that installing and running this is a formal requirement for use of the University’s data network, and of the platform, and that anti-malware software updates and complete system scans should be configured to occur automatically at a minimum frequency of weekly.

Policy on user-installed software and downloaded files¶

Users are not allowed to install software directly onto the platform.
Users should follow the change request procedure to request installations or updates to software.

Data Flows in and out of the SRCPS Network¶

Data must flow in and out of the SRCPS environment by approved methods only.
Data from Client approved external sources (e.g. NHS) will be transferred via an encrypted channel. Details on setting up these secure channels are covered during the Client onboarding process.
The oboardng process will require a meeting … and an onboarding plan and the agreement of an SLA.
By default, there will be no access to the CUDN directly from the SRCPS tenancy unless a business need is identified during the onboarding process.
By default, there will be no internet access from the SPRCS platform unless a business need is identified during the onboarding process when restricted access may be enabled to certain white listed sites.

Restrictions on the use of SRPCS Virtual Machines and Applications¶

As the SRCP has been designed to provide a secure area to store sensitive data, including Personally Identifiable Data, SRCPS rightly treat the security of such data with the highest regard.

There is no ability to access any resources not contained within the SRCPS unless an exception has been granted during the onboarding process or as a change request from the Lead Client.

By default, there are no printing facilities from within the SRCPS unless an exception has been granted during the onboarding process or as a change request from the Lead Client.

Data cannot 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 SRCPS environment. Applications must be approved and published by SRCPS. If you would like an application included, you should submit a change request to the SRCPS Service Desk, where your request will then be reviewed for suitability for processing level 3 sensitive data and their suitability to operate within the SRCPS environment. Access to Virtual Computers requires two factor authentication and SRCPS provide a two factor authentication token for this purpose.

Passwords¶

All Cambridge users can request a password reset via the UIS password management system. Passwords must follow the minimum strength policies defined in this tool.

External Collaborators must set password per guidance below:

https://help.uis.cam.ac.uk/service/security/cyber-security-awareness/passwords

Methods of Encryption¶

All credentials within the Platforms Password Repository are encrypted with GNU Privacy Guard (GPG) keys generated by each member of the Platforms Team. All members of staff are responsible for the proper protection of their GPG keys and must ensure their GPG private key is protected with a strong passphrase. Members of staff must ensure their GPG private keys are never disclosed to others and stored on encrypted storage at all times. All staff members’ GPG keys must be RSA keys of at least 2048-bits, with 4096-bits preferred.

All SSH keys must be of type RSA 2048-bit or greater (preferable RSA 4096-bit), Ed25519, or ecdsa. DSA keys or RSA <2048-bit must not be used.

The following ciphers are recommended for all SSH servers:

All devices used by members of staff with privileged access to connect to the SRCP platform, or any related service or restricted network connected to the SRCP, must use Full-Disk-Encryption, and take sensible precautions to restrict unauthorised access to this device. This might include, but is not limited to, password access to login, screensaver or lock screen password, and the installation of a firewall, or other precautions taken to secure or prevent remote access to the device.

Mobile devices that can generate Google Authenticator TOTP codes to authenticate with the SRCP platform or related services must also be encrypted and unlocked with a passphrase.

Transport Layer Security (TLS) is used to authenticate and encrypt communications between services over the network. TLS relies on a trusted Certificate Authority to vouch for the authenticity of a certificate.

Network services should be configured with TLS enabled wherever possible. If the service is public to the internet or widen CUDN, then it should be configured with a TLS certificate signed by a CA that is already in the standard operating system’s trust store, such as a certificate obtained through the University (see: https://help.uis.cam.ac.uk/service/website-resources/website-components/tls-certs/applying). Otherwise the TLS certificate should be generated from the Platforms Internal Certificate Authority: RIS Certificate Authority, which is generally trusted on all infrastructure servers.

System Protection¶

Electronic data stored within the SRCPS study group drives is replicated to an off-site location according to a schedule.

By default SRCPS backs up home and data folders but does not back up scratch folders.

Access to the SRCPS Main Server Room in the West Cambridge Data Centre 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 WCDC are required to follow the WCDC access policy.

System Audits¶

The Client or Platform Manager must inform SRCPS of employees that should be removed from the SRCPS service via the SRCPS service desk.

The Client or Platform Manager must ensure that only users with a valid reason to have access to the SRCPS should be granted access to their tenancy. The Client or Platform Manager should review the access permissions to their tenancy on at least a yearly basis.

The ISO:27001 certification of the SRCPS Information Security Management is assessed annually by an external auditor. A recertification audit is required every third year.

Internal audits of the SRCPS 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.

SRCPS will arrange penetration testing of the SRCP by a third party to verify its effectiveness. A retest will be arranged following any significant change to the service.