Cloud Security Web Gateway or Secure Access Service Edge (SASE)

In this article, I suggest architectural improvements using modern SaaS (Software/Security as a Service) based solutions to route traffic directly to the internet or and using the architecture described in Part 1 to route traffic to Data Centre.

(Access control to the internet via DNS Firewall is a secondary option — stay tuned for that description in Part 4)

So what are Cloud Security Web Gateways (CSWG), and how will they help you protect/ inspect traffic to the internet and to co-operated SaaS applications?

In 20xx, tech companies developed a cloud-native technology with no on-premise presence by developing a multi gateway infrastructure residing around the world. This means that the user gets the same look and feel, not to mention the same security controls, regardless of their location.

Let’s look underneath the user interface:

The user device checks for the closest CSWG in the region and routes that traffic to their location. Since CSWG’s are managed centrally, the same policy and inspection controls apply. Some of CSWG’s vendors use private connections and can route traffic internally to access a variety of locations on the web. This architecture significantly improves the connection to SaaS vendors with decreased latency. Connectivity to Office365 is a good example of where such architecture helps. For an end-user, there are two options:

1. Use the same mechanics as on-premise proxies and route the traffic using a PAC file (this steering method is slowly becoming obsolete as its being replaced with a user agent); or
2. Use the endpoint agent, which offers multiple ways to steer the traffic, better control on traffic steering, and broader control on protocols, user identification, and health information.

In both cases, there should be a mechanism to distribute the agent or to configure the PAC files.

NOTE: I am deliberately not going down the path of describing how companies can use CSWG to replace NGFW for remote offices and headquarters in this article, this will be a separate topic.

List of Security Inspections on CSWGI — (I Have not provided an in-depth explanation but that is probably something that needs to be done, especially the SSL inspection)

• URL Filtering
• Application Control
• SSL inspection
• Traffic shaping
• Sandboxing/ATP (Advance Threat Prevention)
• Data Loss Prevention (DLP)
• Intrusion Prevention Systems (IPS)

Protocols

For the last decade, we saw a significant shift in the number of computer applications that need access to the internet. The majority of applications began using HTTP as their primary transport protocol. This shift happened because companies started to block most outbound traffic to the internet. The change resulted in NGFW differentiating applications that use HTTP/S. Why is this important? Because nowadays, most of the popular internet outbound protocols from the end-user device are “DNS, HTTP, HTTPS “.

So the question is, what does CSWG need to inspect? This post is not to debate what is better, but to indicate what is there. All the vendors will check HTTTP/S protocols, but not all of them will provide inspection on all the outbound ports.

For all the people that want to scream, “but there are C&C (Command and Control) traffic and other traffic that potentially need to be blocked!”, you are absolutely right. This is why every business needs to reference their business and technology requirements to see how they can compensate for what is missing with other security controls.

User Identification for policy creation

The majority of organizational policies related to source IP in traditional firewalls has moved to the next generation approach of defining strategy based on users and groups. When a user is not in the office, his source IP becomes absolute, so creating any browsing policy based on the user IP is irrelevant. This is why CSWG has to know or have a way of identifying users and user groups.

For small companies, there is a way to use local users and groups (not really recommended), but the majority of companies will use Active Directory or SSO/SAML (I will tackle SSO and IAM architecture suggestions in later posts).

Logging to SIEM (Security Information and Event Management)

Companies that have a more mature security program, and/or regulatory requirements, are logging traffic passing through their devices. While those devices are located on-premise, the logging is relatively easy to achieve and, in most cases, uses the SYSLOG protocol to forward traffic to the SIEM.

CSWG is located in the cloud, and therefore the logging becomes a bit more complicated. Without going into the weeds, there are two primary methods to achieve logging. One is

1. Rest API — the SIEM product will access the CSWG Cloud via API and will fetch the logs
2. Build an on-premise device that will fetch the logs from the CSGW and then forward the logs locally to SIEM via SYSLOG

Conclusion

Pros

• Secure outbound connection when the user is not in the office, business travel, 5G work from home.
• Replication of the same in-line security controls as on-premise
• Faster access to the Internet and SaaS applications
• Better protection from malware
• In-line DLP inspection

Cons:

• Customer doesn’t own all the parts of the architecture and depends on Vendor SLA
• Logging to SIEM can be complex
• Dependant on the geographical location of the Data Centre of the CSWG (a user may not see webpages in their language)
• Poor support for Bring Your Own Device

Popular Vendors in the space

• Native Cloud Security Web Gateways: Zscaler, Iboss, BitGlass, Netskope
• Leading Firewall vendors: Cisco, PaloAlto, CHKP, Fortinet
• Leading Web Proxy Vendors: McAfee, Symantec (Based on Bluecoat technology), ForcePoint

Next articles:

Part 3: Traffic Steering and SSO for CSWG

Part 4: DNS Firewall as Simple Access Web Gateway