07 August 2020 update: We’ve updated this post to remove references to ‘whitelisting’ and ‘whitelists’. GDS has updated its style guide to ban references to the racist terms ‘whitelist’ and ‘blacklist’. We now use ‘allow list’ and ‘block list’ instead.
One common and powerful security measure you can apply to a system is controlling which other networks and computers it can talk to.
If you can detect your system attempting to talk to unknown servers, you get warnings of a compromise. If you can prevent your system from accessing unknown servers, you can make it significantly more difficult for attackers to exploit any weakness.
The traditional approach to this has been IP address-based firewall rules, however this does not work with modern cloud-based APIs.
Why we do not support IP address allow lists for our APIs
We're often asked by government departments for the IP addresses of our APIs so they can be added to an allow list in their network firewalls.
We do not support the use of IP address allow lists for our APIs because these measures are not compatible with modern cloud architectures.
Cloud-hosted APIs, like ours, take advantage of Content Delivery Networks (CDNs), and scalable load balancers, which rely on flexible, rapid allocation of IP addresses. They also often rely on sharing of IP addresses, making IP-based restrictions ineffective.
A workable allow list approach
Happily there is an approach that does work for cloud-hosted APIs and provides equivalent benefits to IP allow lists. That approach is using an HTTPS egress proxy.
In this approach, you have egress proxy software that sits at the edge of your network, between your internal servers and the internet. It examines the HTTPS traffic from your internal servers to determine if it's intended for a trusted recipient based on the domain name.
You configure the software to only allow traffic to an API endpoint, such as https://api.notifications.service.gov.uk. It can enforce that the server providing the API presents a valid TLS certificate for api.notifications.service.gov.uk, ensuring the internal system is connecting to a trusted API via a secure connection.
Using an intercepting HTTPS proxy
This approach is the equivalent of traditional IP address-based allow lists. It’s also possible to configure egress proxy software so that it intercepts the HTTPS connection to inspect the contents of the data leaving the network (rather than just the traffic’s destination). There are trade-offs to this that you should consider.
The benefits of interception are that you can:
- log more details of what is leaving the network
- use data loss prevention technology to prevent sensitive data leaving the network
The downside is the proxy is a more valuable target for attackers as any sensitive data is available at the proxy. This sensitive data may include personal details or authentication tokens for external APIs.
Whether you do simple allow lists or apply interception will depend on:
- the type of APIs you're using
- whether your API data is likely to be a target for attackers
- how widely shared your proxies are
- the capabilities you have to analyse logs generated by the proxies
We use egress proxies without interception to connect GOV.UK Pay and GOV.UK Notify to supplier APIs. This has been relatively cheap and easy to deploy, as we've based them on the robust Squid proxy.
We’d be interested in your thoughts on our allow list approaches. Please feel free to comment below.
You can follow David on Twitter, sign up now for email updates from this blog or subscribe to the feed.
If this sounds like a good place to work, take a look at Working for GDS - we're usually in search of talented people to come and join the team.
