On-Ramping Traffic to a Cloud-Based Secure Web Gateway

Most organizations have deployed a secure web gateway (SWG) to proactively manage and control employees’ access to the public internet and to identify and block malicious content such as malware, ransomware, and phishing attacks.

Originally, SWGs were deployed in data centers as physical or virtual appliances, and since most employees worked in physical locations and were connected to the corporate network, on-ramping internet traffic to the appliance was simple and straightforward. Employees who needed to work remotely used a virtual private network (VPN) to backhaul internet traffic to the data center to apply security controls. 

A brave new (security) world

The world is now a very different place. It’s true that there are organizations that need to retain on-premises security appliances for compliance reasons. However, the overall number of organizations with on-premises secure web gateways has decreased rapidly and now the majority are based in the cloud. 

Moreover, unlike when it was an on-premises–appliance world and employees were tied to their company desktop computer, many organizations now operate a fully remote or hybrid work-from-anywhere-on-any-device model.

Cloud-based secure web gateways

Cloud-delivered SWGs eliminate many of the problems associated with on-premises appliances, such as scalability and ongoing device management and maintenance, and deliver improved flexibility that supports these new working models. 

However, delivering consistent security no matter where an employee is located or which device they are using has introduced new challenges — most specifically, around on-ramping traffic to the SWG.

In this blog post (part 1 of a two-part series), I’m going to look at why having a wide choice of methods to on-ramp traffic to a cloud-based SWG is one of the most important aspects you need to consider when evaluating different solutions. 

DNS-based protections: DNS redirection and DNS forwarding

For completeness, let’s start by reviewing DNS redirection and DNS forwarding as quick and simple approaches to securing internet traffic. This would most typically be used with a DNS firewall solution rather than an SWG, but this approach offers many advantages.

In simple terms, a DNS firewall checks every DNS request from an organization’s employees and compares it against a list of malicious domains. The firewall blocks requests to any malicious domains and allows requests to safe domains to proceed as normal. In addition, the firewall can identify and block traffic from compromised devices to command and control servers or detect DNS exfiltration.

All that security goodness can be delivered in minutes by redirecting or forwarding traffic to the cloud firewall. For redirection, an organization simply has to make a quick change in its existing recursive DNS service to send the traffic to the firewall. 

Another approach is to deploy a DNS proxy, most typically as a virtual appliance, and configure this to forward the DNS traffic to the cloud firewall. Using a proxy also delivers an additional benefit in that it will identify the device making the request to allow for remediation. 

The benefits of a selective proxy

DNS redirection and forwarding can also be used with a selective proxy that delivers deeper insights and more granular control of internet traffic. With a selective proxy, in addition to blocking or allowing DNS traffic, a domain can be marked in the threat list as risky. When a request is made to a risky domain, the firewall returns the IP address of the cloud proxy and the device then makes the connection to the proxy.

The proxy can then examine the URL that is being requested to determine if it is safe or malicious; this provides additional protection against domains that might host both safe and malicious content for example. One significant benefit of using a selective proxy approach is that it blocks risky content, but minimizes the risk that the proxy will break applications. 

Clients to provide protection from anywhere 

As we know, employees no longer work from a single static location but can now work from anywhere that happens to have connectivity: whether that’s through the Wi-Fi in their home office or local coffee shop, or via a cellular network. 

To help protect and enforce security controls on these devices, organizations will need to deploy client software on them. The software ensures that internet traffic is routed to the cloud-secure web gateway, irrespective of how the device is connecting to the internet. An additional advantage of the client is that it can be used to identify the device making the request. 

Clients will typically be available for desktop and laptop operating systems and mobile device operating systems and can be used for DNS-based protections, selective proxy protections, and full proxy protections.

On-ramping all web traffic to an SWG

When optimal security is required, then all HTTP and HTTPS traffic needs to be sent to the cloud-based SWG. A common method is to use Internet Protocol Security (IPsec) tunnels to direct web traffic to the SWG for scanning. 

This requires the configuration of on-premises infrastructure (firewalls or SD-WAN controllers, for example) to optimally and securely transport traffic from branch or headquarters locations to the SWG. One added benefit of IPsec is that all web traffic is encrypted, which further protects private information such as internal IP addresses.

HTTP/S traffic forwarding

An alternative to configuring IPsec tunnels is to deploy an on-premises HTTP/S proxy, most typically as a virtual machine. The proxy simply forwards all HTTP and HTTPS traffic to the cloud-based SWG over a TLS-encrypted tunnel. One advantage of this approach is that multiple forwarders can be deployed to load balance large traffic volumes to improve scalability. It also delivers increased reliability for the service.

HTTP/S traffic forwarding can simplify the transition from an on-premises SWGas the forwarder is a drop-in replacement for an appliance. Once the cutover to a cloud-based SWG is made and everything is working as it should, the forwarder can be removed and the on-ramping can be done directly through IPSec. 

Proxy chaining

As mentioned previously, cloud-delivered SWGs are the predominant deployment methods. However, for organizations that still operate on-premises appliances but are migrating to cloud-delivered security, cutting over can be a large change. 

To ease the migration, proxy chaining allows organizations to configure existing appliances to forward HTTP and HTTPS traffic to the cloud service. This allows them to test the new service, and when everything is working as it should, the appliances can be removed and IPsec or HTTP/S traffic forwarding can be activated.

Choosing the right method and approach

So, now that you know there are many different approaches to on-ramping traffic to a cloud-based SWG, you’d be wise to ask: Do organizations need to select a specific method? Are there advantages to selecting the right approach based on the use case and the level of protection needed? 

A use case example

Let’s answer those questions by using Acme Manufacturing as an example. Acme has more than 10,000 employees globally, and has large headquarters in Chicago and London, dozens of branch offices, and four large manufacturing plants. Acme employees can now work remotely if their role allows for that. Furthermore, while Acme has started to move to cloud, it still operates data centers in its headquarters.

Selecting a single, specific method would not be effective for this manufacturing company. The table below (see Figure 1) illustrates the appropriate methods for Acme, based on use case, and indicates the level of protection provided by each approach.