Arrow DownArrow ForwardChevron DownDownload facebookGroup 2 Copy 4Created with Sketch. linkedinCombined-Shape mailGroup 4Created with Sketch. ShapeCreated with Sketch. twitteryoutube

Data security in the Faculty platform

1. Introduction

This document details how data security is implemented and enforced in the design and implementation of Faculty Platform. Maintaining the security of client data is Faculty Science Limited’s utmost priority, and data security has been built as an integral part of each component rather than as a separate layer. This model provides defence in depth and resilience against incidental and malicious threats to data security.

For the purposes of this document, the definition of data includes, but is not limited to, computer program source code, files containing numeric data, files containing textual data, image and video files, database dump files, program and server configurations, artefacts such as serialised models, customer information, employee information, and intellectual property in similar forms.

2. Data Classification

All data is classified based on its level of sensitivity and the impact to Faculty Science Limited and its clients should that data be disclosed, altered, or destroyed without authorisation. The classification of data helps determine what baseline security controls are appropriate for safeguarding that data. All client data is classified into one of three sensitivity levels, or classifications: Restricted data, Private data, and Public data.

Data is classified as Restricted when the unauthorised disclosure, alteration or destruction of that data could cause a significant level of risk to Faculty Science Limited or its client. Examples of Restricted data include data protected by government level privacy regulations and data protected by confidentiality agreements. The highest level of security controls should be applied to Restricted data.
Data is classified as Private when the unauthorised disclosure, alteration or destruction of that data could result in a moderate level of risk to Faculty Science Limited or its clients. By default, all institutional data that is not explicitly classified as Restricted or Public data should be treated as Private data. A reasonable level of security controls should be applied to Private data.

Data is classified as Public when the unauthorised disclosure, alteration or destruction of that data would result in little or no risk to Faculty Science Limited or its clients. Examples of Public data include press releases, open data, and research publications. While little or no controls are required to protect the confidentiality of Public data, some level of control is required to prevent its unauthorised modification or destruction.

3. Data Security Model

The Faculty Platform data security model is designed to satisfy four broad requirements:

  1. application security and access control;
  2. security of data at rest and in transit;
  3. logging and auditing;
  4. preparedness and incident response.

The provisions for satisfying each of these requirements are described in the remainder of this document. Security is a continuous process and Faculty Science Limited has a responsibility to stay abreast of developments in network and device security. As such, this document is reviewed every three months to ensure it is up-to-date, relevant, and consistent with industry best practises.

4. Application Security and Access Control

Faculty Platform is hosted using Amazon Web Services (AWS). All Faculty Science Limited administrators are mandated to have two factor authentication on their AWS accounts, and high entropy passwords stored in a password manager. The administrator accounts to not allow programmatic access: tasks that do require programmatic modification of AWS resources are performed through system users with appropriate permissions.

Faculty Science Limited administrator access to the AWS servers hosting Faculty Platform services is permitted only by public key-based SSH, with password authenticated access prohibited by the server configuration. Faculty Science Limited administrators’ private SSH keys are not shared, and are stored in the Faculty Platform private data vault.

Connections to ports not required to be accessible for the essential functionality of each server are blocked by firewall rules implemented using AWS security groups. Connections to ports required only for communication between internal systems, rather than client applications, are accepted only when the connection is initiated from specific whitelisted addresses. A recurrent scheduled task checks the programs listening for each open port against a whitelist of allowed programs.

A daily scheduled task on each server hosting Faculty Platform services checks for system security patches and installs them automatically.

Every client will have their own project and project user group. Faculty Platform users are added to the appropriate user group, and only users in this group can access data for that project. User management is contained within a single user management and permissions service. This allows user credentials, access rights, and project memberships to be managed from a single point. This allows a user’s credentials to be modified across all Faculty Platform resources–both storage and compute–in a single action, providing the ability to rapidly react to changing circumstances and modify a user’s access rights across the entire Faculty Platform platform.

Each user of Faculty Platform signs up with a username and password. There are rules in place to encourage users to have a secure password. Upon logging into the Faculty Platform user interface, the browser is provided with a short lived token which is presented when authenticating with each Faculty Platform service. Therefore, the long lived user password is not transmitted over the network to each Faculty Platform service. Upon receiving a user token, Faculty Platform services check the validity of the token with the user management and permissions service upon each request, allowing token invalidation to be quickly applied across the entire Faculty Platform platform from the user management and permissions service.

User authentication is granular, with all permissions being granted on a per project and service basis. Therefore a user can be permitted to access the filesystem for a given client project, but not the reports for that project, or the reports or filesystem for any other client project. User access to individual projects is controlled by project admins. There are no system level accounts in Faculty Platform permitting access to all services and projects, even for Faculty Science Limited administrators, and there is no privileged account permitting universal access (such as a “root” account).

5. Security of Data at Rest and in Transit

Communication of data between the user’s web browser, the Faculty Platform user interface, and between Faculty Platform internal services, is carried out over HTTPS. To ensure the security of data in transit, all HTTPS communications are secured with the TLS (Transport Layer Security) protocol. TLS is used universally, for transfers of all data whether classified as Restricted, Private, or Public. We use a 2048 bit TLS certificate issued by Amazon Web Services with a validity of 1 year. Certificates are automatically renewed before expiration.

A modern TLS configuration is used across all Faculty Platform services, providing perfect forward secrecy (PFS) to sufficiently modern clients to prevent the compromise of past communications in the case of a future TLS vulnerability. Currently, TLS protocol versions 1.1 and 1.2 are supported. This list, and the corresponding list of cipher suites, are reviewed by Faculty Science Limited data engineers on a regular basis to ensure they follow evolving industry best practices.

All communications between a Faculty Platform user’s workstation and their Faculty Platform compute instance initiated using the Faculty Platform command line client are carried over the SSH protocol. SSH authentication uses public keys rather than passwords, with a unique key for each compute instance. Client data remains in Faculty Platform and will not be downloaded to user workstations, enforced by administrative controls. Separate Faculty Platform compute instances are used for each combination of user and project: data from two different clients will not be present on the same server, and two different users cannot access the same individual compute instance.

The Faculty Platform datasets backend uses Amazon’s Simple Storage Service (S3) for object storage. Restricted, Private, and Public data stored on the Faculty Platform datasets are encrypted on the server-side using the AES block cipher with a unique 256 bit key. The per file encryption keys are encrypted with a master key which is stored in Amazon’s key management infrastructure, and regularly rotated. S3 is configured to refuse uploads of data which does not specify encryption at rest.

The Faculty Platform workspace backend uses Amazon’s Elastic File System (EFS) service for storage. Firewall rules ensure EFS file servers can only be accessed from servers within the Faculty Platform private network in AWS, and cannot, for example, be mounted on a laptop external to the AWS network.

Faculty Science Limited clients may load their data into Faculty Platform. Communications with this site are secured with TLS, and files uploaded are stored on Amazon S3 as described above.

On completion of a project, all compute instances associated with the project will be permanently terminated. All client data stored within Faculty Platform can be moved into encrypted glacial storage if requested by the client, and Faculty Science Limited keep audit logs for all data access during the lifetime of the project.

We state here explicitly that email must not be treated as a secure channel of communication. By default, email transits the network in plain text and the contents of an email message are therefore accessible to any party with access to any of the many connections and servers through which the email travels. Restricted and private data must not be transferred in email attachments without the use of strong encryption, such as OpenPGP or S/MIME.

6. Logging and Auditing

All user attempts to authenticate with Faculty Platform, whether failed or successful, are logged by the user management and permissions service. Logging includes the name of the user making the authentication attempt, and the Faculty Platform service and project for which the attempt was made.

All reads of data stored on Faculty Platform datasets are logged, with logs including the full time and date the data was read, the IP address from which the read was made, the identity of the user, the name and path within the filesystem of the data read, and the user agent of the client used to make the read.

Filesystem logs are retained indefinitely, encrypted with AES-256 and stored on Amazon S3 in buckets accessible only by Faculty Science Limited administrators. Upon request from the client, Faculty Science Limited administrators can provide full access logs to the corresponding client project for audit.

7. Preparedness and Incident Response

In any cases of suspicious activity on Faculty Platform, such as a user accessing Faculty Platform from a distant geographic location, or high bandwidth downloads from Faculty Platform, Faculty Science Limited administrators will immediately disable the credentials of the user in question as the first action, preventing all further access to Faculty Platform by that user. All logs, servers, and databases will be retained to permit later examination as required.

Faculty Science Limited administrators will investigate the nature and scope of the incident in order to apply necessary remediations to Faculty Platform infrastructure, and communicate this to Faculty Science Limited management. After the severity of the incident has been assessed, the client will be notified of the incident including all remediative actions carried out by Faculty Science Limited, if the severity of the incident requires it (i.e. excluding false alarms, such as a user accessing Faculty Platform from an unusual location because they are travelling to a conference).