SecurityNCSC Cloud Security Principles
How Assistiv Labs Meets the NCSC Cloud Security Principles
Assistiv Labs complies with the NCSC CSPs. This means Assistiv Labs runs securely and is in line with security best practices and UK government guidance.
- 1. Data in transit protection
- 2. Asset protection and resilience
- 3. Separation between users
- 4. Governance framework
- 5. Operational security
- 6. Personnel security
- 7. Secure development
- 8. Supply chain security
- 9. Secure user management
- 10. Identity and authentication
- 11. External interface protection
- 12. Secure service administration
- 13. Audit information for users
- 14. Secure use of the service
All connections between the end user's web browser and the web front end application are encrypted over TLS 1.2 and are terminated at a Vercel edge network. After the web front end application has been loaded in an end user's web browser and the user has started a session with a remote device or virtual machine (VM), the front end application's communications with the remote backend service that proxies the device/VM connection are encrypted over TLS 1.2, using both HTTPS and secure WebSocket tunnels (wss://), and are terminated at a Google Cloud Load Balancer.
Data inside the Assistiv Labs remote backend service is within a Google Cloud Platform (GCP) Virtual Private Cloud (VPC).
All APIs which are exposed only offer encrypted connections where they are exposed over the internet.
Assistiv Labs is based in the US and runs and stores data in in GCP data centers in the USA and Belgium. GCP is also subject to US jurisdiction and has controls in place to secure and protect assets. For more information, see GCP's official webpage on CSP alignment. Billing is handled by Stripe, also based in the US. Learn more about security at Stripe.
All user data is encrypted at rest and it's not possible to disable encryption.
When an end user ends their test session with a VM, the VM is destroyed and it's storage devices are erased in accordance with GCP's data protection procedures. The only exception to this rule is dedicated company VMs, which have a long lifetime, but access is restricted to only users in your account.
Assistiv Labs is a public SaaS offering available to any user who subscribes to the service.
Users authenticated by GCP Firebase Auth can only access their own data, or data of an account they have been granted access to. VMs used for test sessions run in a GCP VPC and does not have its own external IP address. VPC firewall rules prevent VMs from communicating or discovering each other's existence.
Assistiv Labs is currently a one employee company, who oversees the ownership of risk and security to information assets and services. Threats are identified through a combination of:
- Threat Intelligence from government sources
- Guidance from GCP
- Internal monitoring
Configuration and code changes to Assistiv Labs are continuously deployed to live environments through a continuous integration (CI) and continuous delivery (CD) pipeline. Potential security impact of changes is assessed through both manual and automated testing that's required before a change can enter the CI/CD pipeline.
Fixes to Common Vulnerabilities and Exposures (CVE) are deployed regularly. GCP and Stripe send alerts and fixes are applied within 12 hours of being published.
Suspicious activity or abuse of the system is monitored through both daily manual checks and automated alerts if certain system conditions are met.
External entities can report security incidents at https://assistivlabs.com/security and incidents are disclosed within 24 hours after they have been resolved.
Assistiv Labs is owned and operated by a single person. If and when additional employees or contractors join the staff, Assistiv Labs will verify an individual's education and previous employment, and perform internal and external reference checks. Where local labor law or statutory regulations permit, Assistiv Labs may also conduct criminal, credit, immigration, and security checks. The extent of these background checks is dependent on the desired position.
All staff undergo security training as part of the orientation process and receive ongoing security training. Staff with administrative access to systems are centrally tracked, and only have access to the systems necessary for their job.
Google Cloud Platform also has detailed employment checks.
When developing code, commits are signed by the developer. The 8 NCSC Secure Development Principles are followed.
Code is securely stored in GitHub and securely tested and deployed by GCP Cloud Build. Configuration of GCP resources is also stored as code to ensure integrity and consistency in different environments.
Dependencies are monitored on the web frontend application and backend services and addressed in accordance with the governance framework.
The following table summarizes supply chain organizational and technical controls:
|Organization||Function||Organizational controls||Technical controls|
|GCP||IaaS provider for Assistiv Labs VMs and backend services||GCP holds publicly available security certifications||Data is encrypted at rest.|
Data is encrypted in transit.
Service is subject to independent checks.
|Stripe||Payment provider||Stripe holds publicly available security certifications||Data is encrypted at rest.|
Data is encrypted in transit.
Service is subject to independent checks.
|Vercel||IaaS provider for Assistiv Labs web front end application||Public security policies||Data is encrypted in transit.|
VMs run Microsoft Windows, with latest Windows Updates applied.
Assistiv Labs user and account management is primarily self service through the web front end application. Users authenticated by GCP Firebase Auth can only access their own data, or data of an account they have been granted access to.
Where required, support is available by emailing firstname.lastname@example.org with the email that matches your user account.
All access to Assistiv Labs is secured using GCP Firebase Auth. Account owners and members can give other users permission to access their accounts testing minutes and dedicated devices (as long as they share the same email domain), but only account owners may alter the account details (plan, billing details, etc).
You are responsible for keeping your credentials safe, and they can be changed any time at https://assistivlabs.com/reset-password.
External web traffic coming into Assistiv Labs backend services is protected with GCP Armor. GCP VPCs and security groups protect internal systems.
You are responsible for ensuring your activity on a testing VM is secure and appropriate.
The Assistiv Labs team undertake service administration via bastion hosts. The bastion hosts are accessed using corporate single sign on and multi-factor authentication (MFA).
End user accounts may not perform any administrative actions. They can only connect, spin up a VM, carry out testing, then exit at which point the VM is destroyed.
Available audit information is intentionally limited as VM activity is private to the user / organization consuming the service. As such limited information is captured. When a user connects to a VM, the only details recorded are:
- The assistive technology, version, browser, and browser version selected
- The duration of the session
- Any user preferences for the session (like keyboard shortcut remapping)
- Client details, like the browser's user agent
What you do on a VM in a test session is completely private to you, and the VM is completely destroyed after you're finished.
Users and account owners may request audit logs at any time in JSON format, but data is only retained for up to 26 months.
Make sure you share access to your Assistiv Labs account only with users you trust. You can regularly review the list of users who have access in settings, as well as revoke access at any time.