Terms & policies

National Cyber Security Centre Cloud Security Principals

The points below detail how the Referral System has been built to encompass the Cloud Security Principals outlined by the National Cyber Security Centre.

Data in transit protection

User data transiting networks should be adequately protected against tampering and eavesdropping.

The data is stored (at rest) on Heroku, below are the technical details:

All production plans (Standard, Premium, Private and Shield) are encrypted at rest with AES-256, block-level storage encryption. Keys are managed by Amazon, and individual volume keys are stable for the lifetime of the volume.

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html

In transit (including during user login) we https encrypt, SHA-256.

https://www.heroku.com/policy/security

Both the intermediate and end-entity certificates (where the signatures matter) use SHA-256.

Asset protection and resilience

User data, and the assets storing or processing it, should be protected against physical tampering, loss, damage or seizure.

Case details submitted via the platform are stored in a secure database, along with further case notes and files.

The data is stored (at rest) on Heroku, below are the technical details:

All production plans (Standard, Premium, Private and Shield) are encrypted at rest with AES-256, block-level storage encryption. Keys are managed by Amazon, and individual volume keys are stable for the lifetime of the volume.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html

In transit (including during user login) we https encrypt, SHA-256.
https://www.heroku.com/policy/security

Both the intermediate and end-entity certificates (where the signatures matter) use SHA-256.

Case files are stored in AWS S3 and are only accessible through the use of a specific Identity and Access Management (IAM) policy which is used by the application and is not exposed to users of the platform.

As a managed service, Amazon S3 is protected by the AWS global network security procedures that are described in the Amazon Web Services: Overview of Security Processes. (https://d1.awsstatic.com/whitepapers/aws-security-whitepaper.pdf)

The Supplier will treat all personal data in accordance with the requirements of the Information Commissioner’s Office.

User level access policy

A malicious or compromised user of the service should not be able to affect the service or data of another.

This is achieved by enforced user roles which are as follows:

Super User

Can access the live system to configure the application and create the initial root administrators.

To investigate reported issues which cannot be replicated using the test database.

Administrator

An existing user can only be made a system administrator upon request to support@hutfortytwo.co.uk

Their permissions are as follows:

Can create and edit issue types.
Can define what classifies an ‘urgent’ referral.
Can set an overdue threshold.
Can set a global inactive logout timer.

Can create, manage and suspend organisations within the application.

Can create, manage, activate and suspend users within the application.
Can add users to organisations.
Can unlock users who have been denied access to the system.
Can create referrals on behalf of any sending organisation.
Can update the status of all referrals.
Can remove notes and files from referrals.
Can clone referrals.
Can print referrals.
Can export referrals.

Organisation Lead

An existing user can be made an organisation lead by a system administrator or an existing organisation lead for the organisation in question.

Their permissions are as follows: 

Can manage their own organisation’s name.

Can edit/remove staff from their own organisation.

Can change referral acceptance status for their own organisation.

Can view and update referrals sent to their organisation.

Can export and print referrals sent to or from their organisation.

User w/ Referral Acceptance

An existing user can be granted permission to control their organisation’s capacity to accept referrals by a system administrator or an organisation lead from the same organisation.

User

A user can only be created by a system administrator, a user can be added to and organisation as ‘staff’ by either and organisation lead or a system administrator.

Can manage their login details (username, email, password).
Can update their position and phone number.
Can view and update referrals sent to their organisation.
Can export and print referrals sent to or from their organisation.

Governance framework

The service provider should have a security governance framework which coordinates and directs its management of the service and information within it. Any technical controls deployed outside of this framework will be fundamentally undermined.

Our security governance framework is grounded on the following principles:

Policy:

Our internal policy is that access to the application and data is restricted to authorised individuals. In normal circumstances, the authorised individuals are limited to the Data Protection Officer (DPO) who has access to the platform in case of emergency. This access is a matter of ensuring the integrity and availability of the platform cannot be undermined, and the access is not utilised without prior consent of the Administrating Organisation. In circumstances where other internally employed individuals require access to the platform for investigative or development purposes, a request must be made to the DPO which will be recorded and considered. All other avenues for carrying out the works will be considered before access is provided, and no access will be provided without the consent of the Administrating Organisation. Following the completion of works, the employee will be required to provide a report to the DPO on works carried out, warrant that no data was modified or extracted, and further access will be revoked. No third party individual will be granted access to the platform.

Due to the way we maintain a test environment for the platform which contains no real-world personal data, no access has had to be provided by the DPO.

Program: 

Roles and Responsibilities:

Data Protection Officer:

Manages access to the platform and ensures that no unauthorised access from employees of the Supplier.

Project Manager:

Liaises with the Administrating Organisation to ensure they understand their responsibilities

Technical Director:

Responsible for the security auditing and ongoing maintenance works of the platform. Does not have access to data without following the Policy.

Developer:

Responsible for carrying out works on the platform. Does not have access to data without following the Policy.

Test Analyst:

Responsible for carrying out tests to ensure that works carried out on the platform are correct and appropriate. Responsible for ensuring that the User Level Access Policy is maintained. Does not have access to data without following the Policy.

Risk Assessment: 

Risk: Unauthorised Data Access

Who this affects: Supplier, Administrating Organisation, Application Users, Platform Service Beneficiaries

Risk Evaluation: Unauthorised access to the platform carries risk for all interested parties of the platform who stand to suffer the consequences of unauthorised access to sensitive data.

Supplier, Administrating Organisation, Application Users – may face prosecution or fines as well as a loss of credibility in circumstances where data is exposed through negligence.

Platform Service Beneficiaries – may face persecution, harassment or an incalculable risk to their safety should sensitive information about them be exposed.

Mitigation: A security and compliance policy is in place to ensure that every step is taken to maintain data integrity and security in response to threats from third parties. A User Level Access Policy is in place to ensure that platform data access is restricted to authorised users as outlined by the Administrating Organisation. The Administrating Organisation is responsible for their own policies in managing data and special category data that the platform hosts.

Risk Manager: Data Protection Officer

Risk: Denial of Service

Who this affects: Supplier, Administrating Organisation, Application Users, Platform Service Beneficiaries

Risk Evaluation: Denial of service through any means carries risk for all interested parties of the platform.

Supplier, Administrating Organisation – faces a loss of credibility and a potential breach of any Service Level Agreement if the platform is unavailable for a lengthy time period.

Application Users – may not be able to fulfil their duty of care to their beneficiaries through an inability to operate efficiently.

Platform Service Beneficiaries – may not have access to the support they require which could have an incalculable detrimental effect on their wellbeing, safety and general circumstance.

Mitigation: The applications are routinely monitored to ensure high availability. They are hosted on scalable architecture to cope with rising traffic demands. We recommend to all of our Administrating Organisations that they allow us to manage their domain records through Cloudflare, who offer leading industry level Denial of Service protection.

https://www.cloudflare.com/en-gb/ddos/

Risk Manager: Technical Director

Policies and Training: 

Policies:

Data Protection Officer:

Do not access the Platform without written consent from the Administrating Organisation

Do not provide access to the Platform to employees unless it is appropriate and you have written consent from the Administrating Organisation

All other employees:

Do not attempt to access the Platform without written consent from the Data Protection Officer

Do submit a request for access to the Data Protection Officer if you feel it is required to carry out your responsibilities

Developer:

Do not develop features that do not adhere to the User Level Access Policy without prior consent from the Project Manager

Do not develop features that modify existing application data without prior consent from the Project Manager

Do not develop features which provide new access routes to the platform without written consent from the Data Protection Officer

Do not deploy new application features without having the feature approved by the Test Analyst and the Technical Director

Test Analyst:

Do not pass tests for features that provide new access routes to the platform without written consent from the Data Protection Officer

Do not pass tests for features that modify existing application data without prior consent from the Project Manager

Do not pass tests for features that do not adhere to the User Level Access Policy without prior consent from the Project Manager

Project Manager

Do not provide consent to develop features that provide new access routes to the platform without written consent from the Data Protection Officer

Do not provide consent to develop features that modify existing application data without prior consent from the Data Protection Officer

Do not provide consent to develop features that do not adhere to the User Level Access Policy without prior consent from the Data Protection Officer

Technical Director

Do not provide consent to deploy new features which have not been assessed for conformance to our security and compliance policy

Training:

All employees who work on the platform are required to receive an instructional walk through of our policies as defined by this document carried out by the Data Protection Officer, the Project Manager and the Technical Director.

Response: 

In the event of a suspected data breach carry out the following:

  1. Data Protection Officer: Move the application into maintenance mode to mitigate the risk of a further breach. Request access to the platform if required
  2. Project Manager: Inform the Administrating Organisation of the possibility of a breach, supplying full available details
  3. Technical Director: Request access to the platform if required. Analyse the information available to ascertain whether there has been a breach and if so, identify the cause of the breach, data that is likely to have been exposed and document the findings
  4. Project Manager: Relay the outcome of the investigation including 
  5. Technical Director: Develop a plan for mitigating the potential for a further breach
  6. Developer: Request access to the platform if required. Carry out the plan.
  7. Test Analyst: Test the works to ensure system and policy integrity is maintained
  8. Technical Director: Test the works to ensure the risk has been mitigated, and the security and compliance policy is still in force
  9. Developer: Receive approval from the Test Analyst and Technical Director before deploying
  10. Project Manager: Provide a full report of investigations and works carried out
  11. Data Protection Officer: Move the application out of maintenance mode. Revoke all non-essential access to employees

Operational security

The service needs to be operated and managed securely in order to impede, detect or prevent attacks. Good operational security should not require complex, bureaucratic, time consuming or expensive processes.

This is achieved by carrying out the policies defined in our Governance framework

Personnel security

Where service provider personnel have access to your data and systems you need a high degree of confidence in their trustworthiness. Thorough screening, supported by adequate training, reduces the likelihood of accidental or malicious compromise by service provider personnel.

This is achieved by carrying out the processes in our Governance framework

Secure development

Services should be designed and developed to identify and mitigate threats to their security. Those which aren’t may be vulnerable to security issues which could compromise your data, cause loss of service or enable other malicious activity.

This document outlines our security and compliance policy as well as our approach to secure development, and works alongside the policies outlined in our Governance framework to ensure that the application and our operational practices continually take steps to mitigate the risk of malicious activity.

Supply chain security

The service provider should ensure that its supply chain satisfactorily supports all of the security principles which the service claims to implement.

We only utilise suppliers for the provision of service, and those are restricted to Heroku (Salesforce) and Amazon Web Services. These suppliers are leading organisations and publish their practices in immense detail. They provide evidence of all of their accreditations and compliance, links to which can be found elsewhere in this document.

Secure user management

Your provider should make the tools available for you to securely manage your use of their service. Management interfaces and procedures are a vital part of the security barrier, preventing unauthorised access and alteration of your resources, applications and data.

The application comes bundled with a full featured administration platform through which the Administrating Organisation can manage all data in the system including users and their permissions.

Identity and authentication

All access to service interfaces should be constrained to authenticated and authorised individuals.

The Administrating Organisation are responsible for ensuring the authentication and authorisation of Platform Users.

External interface protection

All external or less trusted interfaces of the service should be identified and appropriately defended.

There are no external or less trusted interfaces of the service.

Secure service administration

Systems used for administration of a cloud service will have highly privileged access to that service. Their compromise would have significant impact, including the means to bypass security controls and steal or manipulate large volumes of data.

All access to systems for administrating provision of service is restricted to the Data Protection Officer in line with our Governance framework. The passwords for these systems are all unique, very strong and are stored in a leading enterprise level security vault.

Audit information for users

You should be provided with the audit records needed to monitor access to your service and the data held within it. The type of audit information available to you will have a direct impact on your ability to detect and respond to inappropriate or malicious activity within reasonable timescales.

Some change management auditing is available by default. Administrating Organisations can request additional auditing functionality and we will enable this in line with their requirements.

Secure use of the service

The security of cloud services and the data held within them can be undermined if you use the service poorly. Consequently, you will have certain responsibilities when using the service in order for your data to be adequately protected.

This document outlines all of the responsibilities in place for Administrating Organisations and Platform Users