Security
Our safety measures
The platform is designed to meet both the Cloud Security Principles and the common security needs of data classified as 'OFFICIAL':
- data in transit is protected by HTTPS from the client to the platform
- apps communicate with each other through private LANs using Silk. Silk uses VXLAN to address private virtual network address spaces. Cloud Foundry network policies use iptables to stop unwanted communication between apps.
- connections from your application to backing services require TLS
- we host on Amazon Web Services (AWS) - their physical security procedures are robust and audited
- data in backing services can be encrypted at rest
- separation between users of the platform is enforced by Cloud Foundry's internal authentication and access control system
- Linux containers provide the boundary between running application instances
- the platform relies on robust operational security and processes (see below)
- it's possible to change and revoke your team members' permissions and roles to manage the service
- users can authenticate via single sign-on with your organisation's Google account
- we use 2-factor authentication, short-lived credentials and IP restriction policies for identity and access management to protect AWS resources
- shared credentials are rotated to minimise risk of unauthorised access
- Amazon Cloudtrail audits and monitors AWS activity
- the CloudFoundry events API provides audit information about the use of your service
How we manage change, vulnerabilities and incidents
The platform is built and maintained by a government team within the Government Digital Service, and these are the established working practices:
- everyone with production access has appropriate security clearance
- code changes are approved by team members who haven't worked on the feature
- we do pair programming whenever possible
- system configuration and access privileges are under source code control and so is documentation
- control changes to the production platform are overseen by civil servants
- we code in the open and our code is available in the alphagov project on GitHub - search for the 'paas' repositories
- we have a tried and tested incident management approach
- reports of incidents are published and available on our status page
- external penetration tests (IT Health Checks) of the platform are carried out annually and it's our policy to address all issues discovered with a CVSS score of medium or above
- when security updates become available, we start working on them within one working day, prioritising fixes to critical severity vulnerabilities
If you need more information, contact us at:
gov-uk-paas-support@digital.cabinet-office.gov.uk
Who's responsible for what
| Your responsibility | Our responsibility |
|---|---|
| Security of the application design and code | Security of the platform |
| Applying security updates to application dependencies | Applying security updates to the platform including the underlying operating system |
| Updating custom buildpacks (if you use them) | Updating system buildpacks |
| Applying security updates to your Docker images (if you use them) | Applying security updates to backing services |
| Telling us if you experience any security breaches | Telling you if the platform experiences any security breaches |
| Performing penetration testing on your applications | Performing penetration testing on the platform |
| not applicable | Setting defaults that optimise for security |