kras99 - stock.adobe.com
In the last decade, organizations have mainly focused on network perimeter defense and protecting their users inside that perimeter. Meanwhile, on the remote side, a VPN was a key way to connect to internal assets and, in most cases, forced remote users to send all their traffic through the company's next-generation firewall when they were in the office. When organizations shifted toward accelerated digital transformation to the cloud, the VPN became a bottleneck that was impossible to scale.
In this massive shift to cloud applications and digital transformation, cloud access security brokers (CASBs) emerged. CASBs aim to mitigate risks around cloud assets when users access those assets from inside the organization's perimeter.
Sometimes, it's easy to look at CASBs as a collection of technologies or features to discover and protect data access. Interestingly, when CASBs were introduced, their focus was encrypting data in rest and transit. In contrast, the user still resided inside the organization's perimeter. CASBs provided the cloud perimeter with a similar level of inspection and security as the local perimeter.
Many organizations used CASB log analysis capabilities to identify shadow IT. Next, CASB vendors evolved their products by adding data loss prevention (DLP), secure web gateway (SWG) and other capabilities.
Cloud, remote work spawn new network model
Toward the end of the last decade, cloud transformation accelerated. In 2020, the COVID-19 pandemic sparked a tectonic shift, forcing end users to vacate their traditional local network perimeters in office settings in favor of work from home. This reality created a need for a more mature architectural model.
The new model needed to protect users from accessing cloud services and the assets inside the organizational perimeter, regardless of users' physical location, while providing the same network security services and controls. Gartner named this model Secure Access Service Edge (SASE), pronounced sassy.
When seen this way, CASB and SASE are not necessarily pitted against each other. Instead, SASE is a natural process of CASB together with other capabilities maturing into an architectural framework. The SASE security model is a blueprint of end-to-end security. It combines perimeter security with cloud security, incorporating strict network access controls following zero-trust concepts, including CASB as a component of the model.
Considering this model and envisioning a diagram of SASE architecture, we see the relationship not as CASB vs. SASE but as CASB within SASE.
Cloud access security broker features
The commonality between CASB and SASE is the A for access. Let's examine the definition of access, separating it between publicly available resources and private resources:
- access to an organization's SaaS applications, such as Microsoft 365, Salesforce, code repositories or other assets, that might run in the cloud, be consumed as a service and require user identity validation;
- access to IaaS resources for operations, maintenance and deployment purposes in cloud environments, like AWS, Google Cloud Platform and Microsoft Azure; and
- access to company data center assets, HR systems and accounting software, including third-party or contractor remote access.
One of the primary goals of CASB is to reduce the risk of unauthorized access to information stored in the cloud and leakage of this data. We can refer to it as risk control compared with pure security control.
When CASB was developed, it had three goals: shadow IT prevention, encryption and blocking the upload of confidential information to nonapproved cloud apps. On the other hand, it also tries to control access to the authorized application for nonauthorized users. Another CASB feature is to identify sensitive information and use company-defined policy to restrict access to this data, in some cases, using user and entity behavior analytics.
Secure Access Service Edge features
When looking at the benefits of SASE, one of the most critical capabilities is zero-trust network access (ZTNA). Remote workers use it to access company resources. At the same time, they have been authenticated and gain access to the application level, supporting and promoting the idea of NIST Special Publication 800-207.
In SASE's early days, software-defined WAN (SD-WAN) devices were tightly coupled to SWGs. This enabled fast onboarding for businesses with multiple offices and a more straightforward way to control and optimize ISP links.
With a shift to working from anywhere, many SWG vendors developed an end-user client that runs on the computer and enables traffic to route to the closest point of presence of the SWG vendor in a secure way. In this configuration, end users can benefit from the same security level, regardless of location. The only requirement is an internet connection. When the users return to the office, they don't have to shut down the client and maintain the same security levels.
Today, the function of SD-WAN devices is mostly to connect company locations; secure servers and other devices where the client cannot be installed; and provide access to legacy systems that can't be moved to the cloud.
It makes sense to have SASE security features such as CASB, DLP, SWG and ZTNA, under one vendor. Such vendors provide better traffic routing, less exclusion, better monitoring and troubleshooting, and -- most crucially -- a single pane of glass for security policy creation. Such consolidation can reduce the number of clients installed on customer devices. It can also enable easier policy creation, troubleshooting, overall better metrics for the security program and visibility for upper management.
Therefore, Gartner defined a new market called security service edge (SSE). SSE has all the security components under one umbrella and excludes the network-related elements, such as SD-WAN. SSE and SD-WAN together will result in the SASE model.