diff --git a/docs/source/evaluations/alan_turing_institute.md b/docs/source/evaluations/alan_turing_institute.md index 74d73cca..add83762 100644 --- a/docs/source/evaluations/alan_turing_institute.md +++ b/docs/source/evaluations/alan_turing_institute.md @@ -721,6 +721,111 @@ - ``` +## Information security + +```{list-table} +:header-rows: 1 +:name: tab-turing-dsh-information-security + +* - + - Score + - Response + +* - 2.5.1. + - 1 + - Some research environment data is backed up. + This includes virtual disks and object storage accounts which contain users personal/configuration files and working data. + Backups are distributed across data centres within a single region. + Input data is only kept as a single, immutable copy which is not backed up (although users may make copies which would be). + Because input data is always a copy, we are not concerned about the loss of input data. + #### Potential improvement + - We could ensure that non-file working data, such as database contents are also backed up. +* - 2.5.2. + - 2 + - We use Microsoft Azure's features for geo-redundant storage for data, which can handle load balancing and replication of data between multiple storage locations. + For TRE computng infrastructure, components are replicable via infrastructure as code. +* - 2.5.3. + - 2 + - Infrastructure is defined by configuration files and replicable via infrastructure as code. +* - 2.5.4 + - 2 + - Our terms-of-use require users to report any potential data incident. + We have a process in place for managing data incidents, whether raised by users or discovered independently, that ensures we meet our legal requirements and also implement any necessary changes, such as disabling access to a TRE if necessary. +* - 2.5.5. + - 0 + - Although we have have a process for incidents, we don't have a incident response simulation process. +* - 2.5.6. + - 0 + - Azure handles update automation, but not vulnerability scanning specifically. +* - 2.5.7. + - 1 + - - Many cloud services, for example virtual networks, are kept up to date by the cloud provider. + - All Windows and Ubuntu virtual machines have system package updates automatically applied on a weekly schedule. + - Other parts of the TRE infrastructure, for example Docker images used by the remote desktop and package proxy servers, are not automatically updated. + ##### Potential Improvements + - We should add a process for recognising when container images are out of date and for updating them. +* - 2.5.8. + - 2 + - Any security patches will get automatically applied to VMs during Azure's update management process. +* - 2.5.9. + - 1 + - A thorough external penetration test is carried out upon each major release of the Data Safe Haven codebase used by our TRE. + The results are used to identify and make security improvements to infrastructure, processes and documentation. + #### Potential improvements + - We could additionally test our production deployments. +* - 2.5.10. + - 2 + - The Data Safe Haven codebase used by our TRE has a system for creating internal security advisories and vulnerability reports. + After a penetration test these are updated and new advisories are added. + Each one is ranked for severity and it is decided whether they can be fixed technically or addressed with workarounds or mitigations. + #### Potential improvements + - Ensure that changes are made to production systems rather than simply incorporated into the next code release. +* - 2.5.11. + - 1 + - The Data Safe Haven codebase used by our TRE makes public the overall results of our regular penetration tests, although the detailed report remains confidential. + We have a publicly available document that describes the security checks our code goes through before release. + These security checks are also carried out on our production systems. + #### Potential improvements + - We could try to find a way to securely run penetration tests on our production environments rather than setting up dedicated testing environments. + - We should run regular security tests rather than only doing so at deployment time. +* - 2.5.12. + - 2 + - We rely on Azure platform level encryption. + This is done via platform managed keys rather than customer managed keys. + #### Potential improvements + - We could take over management of our own encryption keys but we would then need an independent solution for securing these. +* - 2.5.13. + - 2 + - We use Azure Storage Explorer to securely copy data from a local or cloud datasource to our TRE, and from our TRE to known external locations. + Connections made through Azure Storage Explorer are encrypted. + User connections to access the TRE are made over https. +* - 2.5.14. + - 0 + - Once a user has access to a TRE, they are able to work with any input data in a collaborative space. + Any transfer of data within the TRE would be a movement from one folder to another on the same virtual machine. + This would be restricted to the approved users who already have access, and so encryption is not needed. +* - 2.5.15. + - 2 + - We rely on Azure's encryption implementation and trust that this is kept up to date. + Details are available [here](https://learn.microsoft.com/en-us/azure/security/fundamentals/encryption-atrest). +* - 2.5.16. + - 2 + - We rely on Azure's secure key management practices and trust that these are kept up to date. + Details are available [here](https://learn.microsoft.com/en-us/azure/security/fundamentals/encryption-atrest#azure-key-vault). +* - 2.5.17. + - 1 + - We do not apply physical protection methods. + Our infrastructure is virtual and we allow users to connect on their own devices from an allowed IP address. + Our terms-of-use require that users take reasonable precautions against physical attack. + For example, connecting from a location that is as secure as practical such as via a VPN from a home office rather than insecure wifi in a public area. +* - 2.5.18. + - 2 + - We are not hosting data that has specific regulatory requirements. +* - **Capability met?** + - **YES** + - +``` + ## Data lifecycle management ```{list-table} @@ -742,29 +847,31 @@ A signed approval form for the security tier of each project is also required. These signed forms are kept in a private sharepoint folder, maintained by the TRE operators. * - 3.1.3. - - ? - - ? + - 2 + - {ref}`Information asset owners ` must undergo a data classification process by following a flow chart to determine which of five sensitivity tiers data falls into. + The data will then only be used within a TRE of an equivalent security tier (or higher). * - 3.1.4. - 2 - We implement data handling restrictions on data coming into the environment. - These involve getting agreement from the information asset owner, {ref}`project manager ` of the project and an independent representative from the Institute before any data or outputs are moved into the TRE. + These involve getting agreement from the {ref}`information asset owner `, {ref}`project manager ` of the project and an independent representative from the Institute before any data or outputs are moved into the TRE. These stakeholders must sign a form detailing the requested ingress to confirm their agreement. * - 3.1.5. - 2 - We implement data handling restrictions on data coming out of the environment. - These involve getting agreement from the information asset owner, {ref}`project manager ` of the project and an independent representative from the Institute before any data or outputs are moved out of the TRE. + These involve getting agreement from the {ref}`information asset owner `, {ref}`project manager ` of the project and an independent representative from the Institute before any data or outputs are moved out of the TRE. These stakeholders must sign a form detailing the requested egress to confirm their agreement. These signed forms are kept in a private sharepoint folder, maintained by the TRE operators. * - 3.1.6. - - ? - - ? + - 2 + - Egress can only be performed by individuals with a secure access token, provided by secure email. + Administrators will only provide access to named egress contact(s) that are signed off on by the {ref}`information asset owner `, amongst other stakeholders. * - 3.1.7. - 2 - - Our data egress procedure requires signed agreement from representatives of all information asset owners, the project team and a referee external to the project. + - Our data egress procedure requires signed agreement from representatives of all {ref}`information asset owners `, the project team and a referee external to the project. * - 3.1.8. - 2 - Input data is recorded in the aforementioned forms. - The record includes a description of the data, its source (the information asset owner) and the data owner's contact details. + The record includes a description of the data, its source (the {ref}`information asset owner `) and the data owner's contact details. This project initialisation document is specific to the particular TRE project that uses the data and will include the date of data ingress. At, or shortly after, the project end date, the data is securely and irreversibly deleted from the TRE. * - 3.1.9. @@ -775,17 +882,10 @@ - We should draft a clear policy on data deletion in the case that communication breaks down between the project team and TRE operators. In particular, this should focus on ensuring GDPR rules and data sharing agreements are not broken. * - 3.1.10. - - ? - - ? -* - 3.1.11. - - 1 - - Some research environment data is backed up. - This includes virtual disks and object storage accounts which contain users personal/configuration files and working data. - Backups are distributed across data centres within a single region. - Input data is only kept as a single, immutable copy which is not backed up (although users may make copies which would be). - Because input data is always a copy, we are not concerned about the loss of input data. - #### Potential improvement - - We could ensure that non-file working data, such as database contents are also backed up. + - 2 + - The platform is based on Microsoft Azure cloud service and data is held within an Azure Storage Account. + We have process forms in place for data deletion during the TRE project duration, and end-project termination whereby all data and TRE cloud infrastructure is deleted. + An administrator could provide proof that the data has been deleted by showing the Azure Storage Account no longer exists, or that it is empty. * - 3.1.12. - 2 - The input data is immutable to users, it is kept in a folder that is read-only for TRE users. @@ -797,8 +897,9 @@ Copying data into the TRE from the clipboard is not permitted. All users must complete relevant training before accessing a TRE, and sign our terms-of-use, which make them aware that they must not attempt to move data in or out of the environment without authorisation. * - 3.1.14. - - ? - - ? + - 2 + - Before data is added to the TRE, the research PI and other stakeholders must complete an ingress request form detailing the data to be included. + The decision on what data is required for the project is with the {ref}`information asset owner ` and project PI. * - **Capability met?** - **YES** - @@ -855,7 +956,7 @@ - Response * - 3.3.1. - 1 - - All outputs from a TRE go through our security classification process, carried out by the project investigator, information asset owner representative and an independent referee at the Turing. + - All outputs from a TRE go through our security classification process, carried out by the project investigator, {ref}`information asset owner ` representative and an independent referee at the Turing. Different egress processes are required according to the sensitivity of the outputs. #### Potential improvements - We would like to create better guidance and documentation for classification, or possibly build tools to classify/create classification reports. @@ -875,19 +976,23 @@ - We should improve documentation of this process * - 3.3.4. - 2 - - The {ref}`project manager `, information asset owner representative and referee are jointly responsible for output checking. + - The {ref}`project manager `, {ref}`information asset owner ` representative and referee are jointly responsible for output checking. * - 3.3.5. - 2 - - We do not allow egress of files that cannot be manually checked except in the case of release back to the original information asset owner. + - We do not allow egress of files that cannot be manually checked except in the case of release back to the original {ref}`information asset owner `. * - 3.3.6. - - ? - - ? + - 1 + - There is a process in place to decide on the security tier of outputs before egress. + This involves following a flowchart. + There are no specific statistical rules. * - 3.3.7. - - ? - - ? + - 0 + - All output checking is manual. * - 3.3.8. - - ? - - ? + - 1 + - There is a process in place for tracking everything destined for egress, which requires sign off from relevant stakeholders. + It should be possible for output checkers (project team) to make a call on what is the minimum requirement for results sharing. + The process itself does not prevent the project team exporting more data, provided it has been signed off by stakeholders (including the {ref}`information asset owner `). * - **Capability met?** - **YES** - @@ -910,96 +1015,6 @@ - ``` -## Information security - -```{list-table} -:header-rows: 1 -:name: tab-turing-dsh-information-security - -* - - - Score - - Response - -* - 3.5.1. - - 1 - - - Many cloud services, for example virtual networks, are kept up to date by the cloud provider. - - All Windows and Ubuntu virtual machines have system package updates automatically applied on a weekly schedule. - - Other parts of the TRE infrastructure, for example Docker images used by the remote desktop and package proxy servers, are not automatically updated. - ##### Potential Improvements - - We should add a process for recognising when container images are out of date and for updating them. -* - 3.5.2. - - 1 - - Daily anti-virus definition updates and scans are carried out by ClamAV on all Linux VMs. - ##### Potential Improvements - - Extend anti-virus coverage to user-inacessible Windows machines, and also scan data (block and object storage) if possible. -* - 3.5.3. - - 1 - - We comply with the NHS DSPT standard which allows us to process anonymised, patient-derived data. - #### Potential improvements - - We would like to gain accreditation for more wide-ranging standards, for instance CyberEssentials+, ISO27001 and DEA, which cover holistic safe data and research management. -* - 3.5.4. - - 1 - - A thorough external penetration test is carried out upon each major release of the Data Safe Haven codebase used by our TRE. - The results are used to identify and make security improvements to infrastructure, processes and documentation. - #### Potential improvements - - We could additionally test our production deployments. -* - 3.5.5. - - 2 - - The Data Safe Haven codebase used by our TRE has a system for creating internal security advisories and vulnerability reports. - After a penetration test these are updated and new advisories are added. - Each one is ranked for severity and it is decided whether they can be fixed technically or addressed with workarounds or mitigations. - #### Potential improvements - - Ensure that changes are made to production systems rather than simply incorporated into the next code release. -* - 3.5.6. - - 2 - - Our terms-of-use require users to report any potential data incident. - We have a process in place for managing data incidents, whether raised by users or discovered independently, that ensures we meet our legal requirements and also implement any necessary changes, such as disabling access to a TRE if necessary. -* - 3.5.7. - - 1 - - The Data Safe Haven codebase used by our TRE makes public the overall results of our regular penetration tests, although the detailed report remains confidential. - We have a publicly available document that describes the security checks our code goes through before release. - These security checks are also carried out on our production systems. - #### Potential improvements - - We could try to find a way to securely run penetration tests on our production environments rather than setting up dedicated testing environments. - - We should run regular security tests rather than only doing so at deployment time. -* - 3.5.8. - - 2 - - We rely on Azure platform level encryption. - This is done via platform managed keys rather than customer managed keys. - #### Potential improvements - - We could take over management of our own encryption keys but we would then need an independent solution for securing these. -* - 3.5.9. - - 2 - - We use Azure Storage Explorer to securely copy data from a local or cloud datasource to our TRE, and from our TRE to known external locations. - Connections made through Azure Storage Explorer are encrypted. - User connections to access the TRE are made over https. -* - 3.5.10. - - 0 - - Once a user has access to a TRE, they are able to work with any input data in a collaborative space. - Any transfer of data within the TRE would be a movement from one folder to another on the same virtual machine. - This would be restricted to the approved users who already have access, and so encryption is not needed. -* - 3.5.11. - - 2 - - We rely on Azure's encryption implementation and trust that this is kept up to date. - Details are available [here](https://learn.microsoft.com/en-us/azure/security/fundamentals/encryption-atrest). -* - 3.5.12. - - 2 - - We rely on Azure's secure key management practices and trust that these are kept up to date. - Details are available [here](https://learn.microsoft.com/en-us/azure/security/fundamentals/encryption-atrest#azure-key-vault). -* - 3.5.13. - - 1 - - We do not apply physical protection methods. - Our infrastructure is virtual and we allow users to connect on their own devices from an allowed IP address. - Our terms-of-use require that users take reasonable precautions against physical attack. - For example, connecting from a location that is as secure as practical such as via a VPN from a home office rather than insecure wifi in a public area. -* - 3.5.14. - - 2 - - We are not hosting data that has specific regulatory requirements. -* - **Capability met?** - - **YES** - - -``` - ## Security Levels and Tiering ```{list-table} @@ -1009,15 +1024,15 @@ * - - Score - Response -* - 3.6.1. +* - 3.5.1. - 2 - We categorise projects into one of five security tiers. These are clearly defined in our documentation. We are able to support four of those tiers and would reject any projects falling into the most sensitive tier. -* - 3.6.2. +* - 3.5.2. - 2 - We support projects with differing security requirements through security controls that are pre-defined for each tier. -* - 3.6.3. +* - 3.5.3. - 2 - We support a documented set of security control tiers that projects can choose from at the outset. * - **Capability met?** @@ -1034,14 +1049,17 @@ * - - Score - Response -* - 3.7.1. - - ? - - ? -* - 3.7.2. - - ? - - ? +* - 3.6.1. + - 0 + - We do not hold a catalogue of data in this format for this purpose. + The data is provided to us by the {ref}`information asset owner ` for a specific purpose. + Researchers do not apply to us to access specific datasets and thus do not need to have access to a description of the data. +* - 3.6.2. + - 0 + - This is something we would expect the {ref}`information asset owner ` to do, rather than implement ourselves. + For example, they could use a high-security tier 3 TRE to summarise or produce a synthetic version of a sensitive dataset for use in a lower security, tier 2 TRE. * - **Capability met?** - - ? + - **YES (no mandatory statements)** - ``` @@ -1054,11 +1072,12 @@ * - - Score - Response -* - 3.8.1. - - ? - - ? +* - 3.7.1. + - 0 + - We do not provide such an application. + We do not maintain meta-data for sets of available datasets, since we do not maintain a corpus of datasets for people to apply for access to. * - **Capability met?** - - ? + - **YES (no mandatory statements)** - ``` @@ -1071,14 +1090,15 @@ * - - Score - Response -* - 3.9.1. - - ? - - ? -* - 3.9.2. - - ? - - ? +* - 3.8.1. + - 1 + - We don’t have a particular method for data archiving in the TRE, though administrators do have the ability to move data to a read-only location if needed. +* - 3.8.2. + - 0 + - We don’t have a particular method for archiving data in the TRE, though it is possible to keep data in the Azure Storage Accounts whilst restricting access to users. + We don’t handle formatting or maintaining of datasets, which is up to project teams using the TRE. * - **Capability met?** - - ? + - **YES (no mandatory statements)** - ``` diff --git a/docs/source/pillars/computing_technology.md b/docs/source/pillars/computing_technology.md index 3309abce..710d9cbe 100644 --- a/docs/source/pillars/computing_technology.md +++ b/docs/source/pillars/computing_technology.md @@ -532,7 +532,7 @@ The process of applying updates or patches to software and systems to address kn - This includes any software used for remote desktop portals, databases, webapps, creating and destroying compute infrastructure, configuration management, or software used for monitoring the TRE. - Mandatory * - 2.5.8. - - Infrastructure and should be automatically patched for vulnerabilities. + - Infrastructure should be automatically patched for vulnerabilities. - Planning will be required across infrastructure and software systems to ensure security patches remain available from suppliers. Many systems may be isolated from the internet making TRE infrastructure more difficult to automatically patch. - Recommended