If you can detect your system is attempting to talk to unknown servers, then you get warnings of a compromise, and 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 doesn’t work with modern cloud-based APIs.
Why we don’t support IP address whitelists for our APIs
We're often asked by government departments for the IP addresses of our APIs so they can be whitelisted in their network firewalls.
We don’t support the use of IP address whitelists for our API’s 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 whitelisting approach
Happily there is a whitelisting approach that does work for cloud hosted APIs and provides equivalent benefits to IP whitelisting, and that’s 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, and 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
The approach described above is the equivalent of traditional IP address based whitelisting. 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, which may include personal details or authentication tokens for external APIs.
Whether you do simple whitelisting 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 whitelisting approaches. Please feel free to comment below.
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.