Building Web Check using PaaS

When we started building Web Check, delivering services via the cloud was a new and less well-understood way of working. The cloud was seen by some as, 'high risk'. 

Despite this, we decided to host Web Check in the cloud, rather than our own data centre, for cost-saving and scalability reasons. We opted to use Amazon Web Services (AWS), due to our team's experience, but we could have chosen one of the similar services, available from other providers, like other teams in the NCSC have done.

Initially we weren't ready to jump in with both feet on any vendor-specific services, fearing that we'd become 'locked in' to a system we couldn't use long term. So we decided to use Infrastructure-as-a-Service (IaaS), with our own software and configurations running on top.

But, not using PaaS meant we had to maintain almost the entire stack. This left us with quite a lot of work to do to protect ourselves.

We had to ensure we could:

• update and patch the virtual machines (VMs) we would use
• manage our own public key infrastructure (PKI)
• build and maintain lots of servers and software (such as databases)
• manage and maintain all of the virtual private networks (called Virtual Private Clouds in this context, or VPCs)

Although our service was hosted in the cloud, we realised that we weren't getting many of the benefits associated with cloud services. So we decided to look at our PaaS options. 

When we first began to think about using a PaaS service, we needed to re-examine the question of whether the processing and storage of our data would be sufficiently isolated from other customers of the same service.

For AWS, we looked at the material Amazon has published online about their approach to security, including its response to our Cloud Security Principles. This covers in detail how data belonging to different customers is separated and the mechanisms put in place to restrict access to customer data.

The AWS shared responsibility model explains which aspects of data security Amazon takes responsibility and which the customer must manage. This gave us a lot of information with which to reason about security questions. And there's more available for specific services.

An example of this process is the AWS Lambda FAQ. This states that, "AWS Lambda uses the same techniques as Amazon EC2 to provide security and separation at the infrastructure and execution levels." This gave us the confidence that migrating workloads to Lambda would have broadly similar security properties to the existing version executing in VMs on Amazon EC2.

We are now heavy users of AWS Lambda, executing around 1.7 million Lambda invocations per day to perform our security scans. Using serverless services like Lambda has meant we no longer need to patch the operating system or the language runtime, since these are taken care of by AWS. This allows us to focus squarely on our application logic.

We have also been able to delete a lot of now-redundant code, such as the code for sending and receiving messages to invoke scans. Lambda keeps a record of each version we've uploaded, making it very clear which one is in use. This gives us peace of mind that adding a new version can't somehow affect an existing version.

By using version aliases, it becomes very easy to change which version is in use and to roll back to a known good version if necessary. All without having to perform additional deployments.

The productivity gains from using these PaaS features dramatically eased the burden of ongoing maintenance. And, since the underlying platform is patched for us automatically, there is no drop in security. 

We have also seen substantial cost savings by migrating to Lambda, as our software only executes when it needs to, rather than silently costing money while idle. 

We also use Amazon Certificate Manager (ACM) to provision and update our HTTPS certificates. It's all too easy to forget to renew a certificate and for your reputation to suffer as a result. Offloading that risk to Amazon has given us additional peace of mind. 

All this has left us with more time and resources to iterate the Web Check service. 

We've made some good progress, but we want to go much further. We still have plenty of code running on IaaS platforms, and plenty of direct interaction with that infrastructure. Both of which we want to move away from.

Our experience with Web Check has shown us that by replacing IaaS with appropriate PaaS services we're able to reduce costs and focus more effort on improving our end product.

Done well, the security properties are the same as, or better than, the IaaS alternative. So, we intend to use PaaS to build our services from now on.

While the move to PaaS has had some challenges (such as reduced visibility, less control over factors like DNS, and having to train our developers to think in a new, event-driven paradigm), we've found that these are outweighed by the benefits.

Jamie H - Senior Cloud Security Researcher