Security Service Edge (SSE) is an emerging network security model that rolls up technologies like zero trust network access (ZTNA), cloud access security broker (CASB), secure web gateway (SWG), and next-generation firewalls/firewall as a service (FWaaS) into a cloud-centric security stack.

With these cloud security services, you can provide secure access to the cloud and software as a service (SaaS) resources for both on-premise and remote workers. This blog will dive into the essential technologies to achieve security service edge. We’ll also discuss the benefits these technologies can provide to your enterprise, as well as tips and best practices for streamlining your SSE implementation.

SSE implementation guide for enterprises

Enterprises may choose to implement SSE by purchasing an all-in-one solution that includes the core components of security service edge. Other teams prefer to buy each security technology separately so they can select the best vendor for their particular use case, or because they already have some SSE capabilities with their existing security stack and only need to supplement with one or two additional solutions.

Let’s take a look at the key security service edge technologies that you need to implement to achieve SSE for your enterprise.

Zero trust network access implementation

ZTNA, or Zero Trust Network Access, is a remote access security solution based on the zero trust security model and follows the principle of “never trust, always verify.” Unlike a VPN, which gives authenticated remote users full access to an enterprise network, ZTNA only allows remote users to access specific resources one at a time. With ZTNA, you can create contextual access control policies that limit a user’s privileges depending on the relative risk of that specific request. So, for example, a user connecting at 1 PM from their home office may get more ZTNA privileges than a user connecting at 1 AM from their mobile device in another country.

A ZTNA solution needs identity and access management (IAM) capabilities to authenticate users and dynamically assess their trustworthiness. For instance, ZTNA typically uses multi-factor authentication (MFA) to provide an extra layer of verification before a user can access enterprise resources. User and entity behavior analytics (UEBA) are also commonly used by ZTNA because these can track account and device behavior on the enterprise network to spot anomalous behavior and provide analyses of a user’s trustworthiness.

ZTNA can be deployed as physical appliances in data centers, or you can choose an entirely cloud-based solution. Using ZTNA as a cloud service will save you from needing to purchase, configure, deploy, and manage more physical hardware, plus you’ll be closer to achieving an ideal SSE implementation by keeping more infrastructure in the cloud. In addition, purchasing IAM and ZTNA capabilities as one solution is not needed if you already have an existing IAM (or a particular vendor you wish to use)—just make sure your ZTNA and IAM support integrations with each other. Implementing ZTNA for SSE helps you bring zero trust security to your cloud and remote traffic.

Cloud access security broker implementation

A CASB, or Cloud Access Security Broker, is essentially a software gatekeeper that sits between enterprise users and cloud services. It provides visibility into how enterprise users interact with your cloud services, using technology like UEBA to detect unusual behavioral patterns and assess risk.

CASB serves numerous vital cloud security functions, including:

• Implementing enterprise policies to cloud resources to enforce the same level of security on all your on-premises and cloud infrastructure equally.
• Auto-discovering all cloud applications, data, and services in use so you can identify risk factors and prevent shadow IT (technology in use by your enterprise that your IT teams might not know about).
• Extending data loss prevention (DLP) and data governance policies to your cloud data, to prevent the exfiltration of sensitive and proprietary data, and ensuring your enterprise complies with data privacy regulations.

As part of an SSE implementation, there are two CASB deployment modes to choose from, depending on your enterprise’s unique needs. You can use a proxy-based CASB, which is an HTTP proxy that sits between remote users and the cloud to monitor and direct traffic. Or you can use an API-based CASB, which interfaces directly with cloud and SaaS providers to inspect traffic.

Each deployment has pros and cons that need consideration with your enterprise’s goals and requirements in mind. Generally, a proxy-based CASB may cause network slowdowns because all your remote, cloud-destined traffic is funneled through a single device. Regardless, it’s still flexible considering it can work with any vendor or application. On the other hand, An API-based CASB often suffers from vendor lock-in since it integrates with a specific provider (like Microsoft 365 or Salesforce), but it causes less latency. It doesn’t require any physical or hosted hardware. Either way, deploying CASB for your SSE implementation helps monitor and protect traffic to and from your cloud services.

Secure web gateway implementation

An SWG, or Secure Web Gateway, is precisely what it sounds like—a secure gateway between your enterprise and the web. It filters malicious content from the internet and blocks dangerous user activity (like clicking unsafe links or downloading files from untrusted websites). Enterprise IT teams have been using traditional SWGs for years in physical appliances or as software running on proxy servers.

For SSE, an SWG is a cloud-based solution that can route all remote and branch office traffic to bypass your data center altogether. That means you don’t need to backhaul remote traffic through the SWG at a data center. However, you still get to apply enterprise web filtering, acceptable use policies, and internet security. Implementing an SWG for SSE allows you to treat your remote web traffic the same way as your on-premises traffic, providing consistent security across the board.

Next-generation firewall/Firewall as a service implementation

An NGFW, or next-generation firewall, improves the capabilities of a stateful firewall by providing features like cloud threat intelligence, integrated intrusion prevention, and application awareness plus control. An NGFW can be a physical appliance you deploy at the data center. Still, for an ideal SSE implementation, you should look for NGFW technology as a cloud-based service known as FWaaS or firewall as a service.

FWaaS delivers all the functionality of an NGFW, including:

• Breach prevention, which uses technology such as integrated intrusion prevention, URL filtering, and built-in sandboxing to analyze viruses and other malware.
• Complete network and cloud visibility with monitoring, UEBA, and automated threat analysis and remediation.
• Deep packet inspection (DPI) to comprehensively analyze every data packet that passes through your network.

One of the most significant benefits of FWaaS for SSE implementations is that you won’t need to deploy many physical appliances to branch offices and data centers. Plus, you can route remote and cloud-destined traffic through a cloud firewall instead of backhauling it through a physical device, which reduces network latency. FWaaS for SSE provides all the security functionality of a physical next-generation firewall, but as a convenient cloud service.

Zero trust network access, cloud access security brokers, secure web gateways, and firewall as a service are the four key technologies needed to deploy and achieve the SSE model. However, to use SSE technology, you need to route the remote and branch office traffic to those services. This is what’s known as an access onramp, which turns SSE into SASE—secure access service edge.

Access your SSE implementation with Nodegrid

It would be best to have an access solution that seamlessly integrates with your security service edge implementation and simplifies the management of your remote network architecture, like ZPE Systems’ Nodegrid. The Nodegrid SR family of edge routers delivers vendor-neutral orchestration of your remote infrastructure so you can easily spin up and manage your SSE solutions from anywhere in the world.

Learn more about how to access your SSE implementation with Nodegrid.

Contact ZPE systems online or call 1-844-4ZPE-SYS.

Contact Us

Modern network management involves a wide variety of distributed technologies. Because of this, enterprises have progressively moved towards the Security Access Service Edge (SASE) model to provide remote users with secure cloud-based services. Even though these services came together to form a comprehensive network and security stack, several providers made inaccurate claims that their products offered an all-in-one solution.

Consequently, the SASE model has undergone a rebranding. The new and improved focus on Security Service Edge (SSE) programs has confused those interested in transitioning to a remote structure. This article will help you understand SSE, its components, and how SSE differs from SASE.

In addition, we will discuss how you can implement SSE into networks and start your journey towards the SSE architecture suited for your enterprise.

What is Security Service Edge (SSE)?

SSE is a combination of cloud-based security technologies designed to protect your edge network. With all its programs combined, it forms half of the SASE framework. SSE provides cloud-based security and SaaS programs to the edge network perimeter, allowing remote users to access these services without being in the office.

What are the key SSE components?

To understand how SSE works, you need to understand its components and how they come together to form a more cohesive edge computing architecture.

Let’s dive deeper into each SSE component to understand them better.

Zero Trust Network Access (ZTNA)

Zero trust is one of the most important aspects of a robust SSE architecture. Zero trust is a security framework that operates on the central principle that “no device is trustworthy.” This includes devices within a company’s perimeter, which traditional “castle and moat” models ignore.

While zero trust exists as a general security architecture involving a variety of principles, zero trust network access (ZTNA) is the practice of applying zero trust principles to a  comprehensive SSE security stack. When applied correctly, ZTNA uses features such as:

• Uniform security policies
• Identity-based authentication
• Centralized visibility
• Granular access
• Threat monitoring following access

ZTNA emphasizes “granular” access since it limits who can access and to what. In this way, it helps prevent the possibility of cyberattacks and minimizes their effects if they happen.

Cloud Access Security Broker (CASB)

CASB works as a form of cloud-based security. Whereas ZTNA focuses on the granular task of monitoring individual points of access, CASB focuses on tracking data transference from one cloud environment to another. When we talk about CASB, it is essential to specify that we mean integrated CASB instead of traditional CASB, which only offers piecemeal security protocols that solely cover data already in the cloud.

Integrated CASB uses an API-based security system that communicates between various SaaS applications commonly used by SSE networks. The significant advantage of taking this approach towards cloud security is updating and automatically possessing integration capabilities as new SaaS programs are introduced. With the rise of SaaS usage by large and small enterprises alike, CASB is undoubtedly a central need for any strong SSE network.

Secure Web Gateway (SWG)

As SSE networks exist almost entirely on the premise of edge computing, it makes sense that users want to emphasize a well-secured access terminal. The purpose of SWG is to provide this terminal in a remote location that exists on the edge of the security perimeter. Secure web gateways protect user access by:

• Limiting website access once accessed
• Enforcing security policies
• Protecting data transfer

By limiting and restricting access, remote users will be less likely to access materials that could contain malware or ransomware, for which Palo Alto cites the ransom amounts having climbed by 82% in the first half of 2020. SWG makes up an integral part of the SSE security stack, providing the access terminal through which users begin to interact with the other programs.

Firewall as a Service (FWaaS)

FWaaS uses a SaaS service structure to provide firewall services for clients. FWaaS offers large and small enterprises with cloud-based firewalls, which they can customize to work around company applications or cloud-based services; without needing to route traffic through a physical firewall appliance at a data center.

The main advantage of FWaaS is adaptability—since it is constantly updated to integrate with new and existing services commonly used in SSE networks. With FWaaS, you avoid all the hassle of deploying and managing hardware at every branch office or the performance issues that come from backhauling remote traffic through a single appliance at the primary data center.

SSE vs. SASE: What is the Difference?

The transition to SSE networks might seem confusing for network administrators who have been working on the SASE model in recent years. This is an understandable confusion, but the differences between them are significant and merit some studies. The basic breakdown is as follows:

• SASE = Secure Access Service Edge
• SSE = Security Service Edge

This distinction seems odd on its face. The difference between the two is just the element of access. That essentially means SASE=SSE+Access. The access portion of SASE is also a collection of several components itself. SD-WAN, routers, and gateway all play essential roles in granting remote users access to the programs offered by the SSE stack. Together, the two create the comprehensive SASE architecture, which has become the benchmark for remote access over the last few years.

Why Does “Access” Matter as an SSE Component?

It’s easy to look at the equation above and think that enterprises are losing something with the move to SSE, since SASE seems to have something (access) that SSE does not. This is why it’s important to remember that SASE is a collection of programs and is not offered as an all-in-one system anywhere. This has not stopped various SD-WAN network providers from claiming to provide a SASE connection, confusing the market and necessitating the move in distinction to SSE.

What SSE components can do for your organization

Whether you plan on switching over to an SSE network entirely, the fact remains that many SSE components are good tools to have in your security stack. Even if your company has not gone remote and operates using a traditional “castle and moat” model, things like ZTNA, CASB, and SWG still have a lot to offer in making your business more secure.

For enterprises wishing to switch over to a SASE framework, ZPE’s Nodegrid series of routers offers options for both SD-WAN solutions and Zero Trust Network Access, making it the perfect start on your SASE journey.

Want to learn more?

Contact us for more information on how we can help get your enterprise on the right track.

Contact Us