Security teams within organizations have grown keen on adopting the Secure Access Service Edge (SASE) architecture as business data, applications, and workforces “left the building” during the pandemic and moved into the cloud. Security solutions have reluctantly followed along during the digital transformation of the last two years or so. And it’s true that SASE promises to underpin the “work anytime, anywhere” model that competitive companies and their digital workforces are seeking.
Turning SASE from a trendy acronym into an architecture that supports and secures the modern distributed work environment, though, rests on the implementation of two familiar tools in the security toolkit—the secure web gateway (SWG) and the cloud access security broker (CASB). These tools work hand in hand to eliminate security blind spots and ensure that employees have access to the digital assets and applications they need without the risk.
What is SWG?
The SWG (pronounced swig) is the foundational security element for SASE and the first piece of the puzzle that any organization should implement when planning their SASE adoption framework. SWGs are proxies that block unsecured malicious traffic from coming out of or going into an organization’s network, shielding users from web-based threats. The web gateway is nothing new—in fact, it has been around for years. When it first emerged, though, it was basically just like a URL classification appliance, identifying whether a website was, say, a news site or a sports site, and lacking any real smarts for how policies were enforced with any additional context. There was a productivity use case for that kind of gateway, not a security use case. But when the security use case finally came around, it largely centered on adding another category, which determined if a site was malicious or not.
With the advent of Facebook, LinkedIn, Twitter, and other social media sites that allowed users to upload pictures and share posts, the web gateway took on more of the traffic cop role. In the last few years, in a great rush forward, nearly everything digital—from storage to Dropbox to email—has made its way to the cloud, and with that has come the need to control what’s going to and from the cloud.
This shift in work patterns is combined with a shift in traffic patterns. The rapid increase in remote workers has pushed legacy VPN deployments beyond their performance maximum, resulting in poor user experience. With the option of having traffic go directly from end users’ devices to the Internet, security is compromised and visibility is lost. As we look at trying to protect the perimeter of an organization, the traditional perimeter is gone. People are the new perimeter.
More recently, even financial services organizations are starting to embrace the notion of cloud-based SWGs to replace their on-premises web gateway infrastructure and deployments. It’s not a shift to be taken lightly, because the on-prem architecture has been the bedrock of these companies’ networks for so long that a number of features must be developed to meet the requirements needed to go fully to the cloud.
What is CASB?
The CASB does exactly what its name implies—it serves as a broker in a cloud-based environment. It sits between the user and the cloud—monitoring and managing traffic, and applying an organization’s security policies. The CASB typically has three types of deployment, but the two main ones are inline and forward proxy deployment. Agent-based CASBs require proxy agents on each endpoint. Deployment is quicker and easier when companies use agentless CASB, which covers both the devices managed by the companies and those brought in by end users. But real management capabilities come with those CASBs that use APIs to examine cloud traffic, apps, firewalls, and proxy logs for suspicious activity.
The API deployment mode is where the CASB functions and where policies and controls are applied through integration via API into the cloud app. So, for instance, if an organization runs Office 365, then Microsoft provides API integration through the Graph API. That then provides necessary and much-sought-after visibility into everything happening within that environment to third-party vendors’ security products.
How do SWG and CASB work together?
The intersection of the SWG and the CASB is a central aggregation point through which all traffic flows, whether to the web or to SaaS and cloud applications. From a technology perspective, it’s a very good control point. It’s the perfect place for an organization to add granular deep visibility and policy into cloud apps, in order to apply more nuanced policies and more granular policy controls that go beyond just allowing or blocking applications or traffic. And where there is potential risk—risk of data loss, risk of downloading malware, risk of oversharing—security teams can implement deeper controls around that cloud app usage from the SWG, since it’s providing visibility into all of that traffic.
Are SWG and CASB converging?
Much of the conversation around SASE centers on the synergy between SWG and CASB and whether the two tools will eventually converge. After all, they do have similar capabilities, with CASB enhancing SWG’s ability to manage traffic and enforce security policies. But CASB could simply remain an add-on to an existing SWG foundation. From an underlying technology point of view, the two are natural allies. CASB added to the underlying SWG, or proxy, provides an extra layer of security that helps determine whether traffic is risky or malicious, which traffic goes to certain applications, and what policy is in place to dictate what is done with it.
Inline CASB deployment is very effective because if you have the SWG in place that’s the core of everything, then all the other security capabilities—such as data loss prevention (DLP), remote browser isolation, filtering, and content inspection—are built on top of that.
What role does isolation play?
A SWG is even more powerful when its foundation is built on isolation. Through isolation, all active and risky web content is kept away from the target device. The same tactic is taken for all documents, resulting in safe viewing for users and no risk posed on the endpoint. Isolating all web traffic—instead of isolating just a subset of traffic or bolting on some solution as an afterthought—is integral to securing an organization’s traffic.
Utilizing an integrated isolation core can ensure that organizations get a better security outcome across web security, email security, data loss prevention, and CASB, An isolation core provides a consolidated security platform that delivers on the promise of Zero Trust.
Using the same approach to extend this core functionality out to a CASB can feel like the next natural step for many organizations, ensuring that the content and documents accessed through cloud applications are also secure.
Organizations looking for an easier move to SASE through a full suite of security solutions will benefit from the closer integration of key security elements. Regardless of whether SWG and CASB actually converge or remain discrete tools working in concert, there’s no doubt that the dynamic duo makes SASE a very powerful security framework indeed.
Enterprises today are securing work where it happens, without disrupting the user experience. Discover how isolation-powered SWGs protect productivity.
*** This is a Security Bloggers Network syndicated blog from Menlo Security Blog authored by Mark Guntrip. Read the original post at: https://www.menlosecurity.com/blog/the-convergence-of-swg-and-casb