How does MOJ Forms handle security?
Context
What is MOJ Forms - Publish digital forms quickly and easily. Give your users a secure, accessible way to contact you, make a request or submit information.
The whole platform is made from separate services that perform different tasks to collect user data in a structured, secure manner.
MOJ Forms is listed as a Data Asset by the MOJ DPIA team, which means the MOJ Forms part of the DPIA process is already assured and only needs referencing.
Editor
The Editor is a staff facing application which provides the tools to build a form which meets the user journey. Add settings and publish to a test environment and then publish to the live environment.
The Form uses json to store the content and branching instructions. This metadata can be stored in the open as it does not contain anything confidential or personal.
Accessing the Editor we use Auth0 for Single Sign On which confirms the authentication with our domains Active Directories.
Platform
The main services which lets MOJ Forms work are:
- Runner - The application is the form, it is citizen facing.
- User Datastore - Saves data entered in the form.
- User Filestore - Save upload documents
- Malware Scanner - Scans uploaded documents for malware
- Submitter - Passes the data to the backend team as directed in the settings for the form.
Service Token Cache
This service is used to confirm each application is communicating with the application within the platform. This fulfils one of the principles to make sure we do not reply to the hosting for security between the services. For example, the runner and the user datastore will request a token and only if they match will they communicate.
The deployed token caches use service accounts to look at configmaps kubernetes resources in their corresponding service namespaces, ie platform-test-dev has a rolebinding in saas-test and services-test-dev allowing that service account to get configmaps.
The cache then holds the public key in redis for 5 minutes, keyed to that user/session id and service id, to prevent making an expensive kubernetes read too often.
Downstream services like the user datastore and filestore can request that public key and use it to verify the JWT included in each request is valid for that service. New public keys are generated per service per publish.
End User data
The data is transported over https and encrypted at rest using the session cookie generated when the user starts the form so it is stored encrypted per-user + per-form. This Sequential data is encrypted at rest in an RDS hosted in AWS, and user data is deleted after 28 days automatically. Documents are checked on upload via https that they meet the type and size validation and streamed to a malware checker, only then it is stored at rest encrypted in a S3 bucket. Only the internal services can add and get files from the filestore. We can save partial form progress which is stored in the same way as other user data, plus a record we use to resume progress (a record of the user, form and session token needed to resume progress) which is also encrypted at rest using a separate key. Once users resume progress (using a one time secret answer) these records have sensitive items (keys, answers etc) deleted immediately, and the record itself is deleted after 60 days.
Submissions
Once the end user has completed they submitted the data. This takes the data and processes it as determined in the settings. Either produced in a pdf or csv attached to an email or send encrypted data to an API endpoint.
Cloud platform
MOJ forms is hosted in MOJ’s strategic hosting environment Cloud Platform which is a managed Kubernetes cluster. It is secure by default and can host service up to Secret.
Development
Developers - Part of the recruitment process is that each developer has at least BBPS clearance.
Code management - All source code is held in github and public under the government open source licence, only deploy configurations are held internally. Each repository requires a pull request and is approved by a team member before merging into the main branch. 3rd party software and frameworks are managed using Dependabot, and there is a 3 day cooling off period before merging - if there is an issue a ticket is raised to fix when programmed in.
Automated security checking - The deployment pipelines are configured to take the main branch, run security tooling against the code and build the application into the test environment, this then has all the acceptances test run against it. Only when that has successfully completed that the changes are built and deployed to the live environment.
Threat Model - The team runs threat modelling exercises either over the whole platform or for a distinct feature and the parts of the platform it interacts with.
ITSHC - The platform was formally tested in 2021 (using the legacy editor and runner), since then ITSHCs are not available through central funding with the view that more continuous testing based approach is used. MOJ Forms does have good coverage for testing in its deployment pipeline and routinely (at least quarterly or during a feature development cycle) tested using tools provided by cyber.
Security tooling used include Brakeman, CodeQL, Cymulate and OWASP ZAP