We can think of SSE as a scaled-down, purely secure version of Secure Access Service Edge (SASE). SASE includes a large number of security and networking services that may be too onerous for many enterprises in practice.
SSE offers the same three main security technologies as SASE:
- Cloud Access Security Broker (CASB)
- Secure Web Gateway (SWG)
- Zero Trust Network Access (ZTNA)
SSE scales back SASE’s other functions, especially its WAN-related services. By deploying SSE instead of SASE, enterprises can realize many of the same security benefits while migrating easier and faster.
Consider the following three practical tips for getting started with SSE.
1. Staged Secure Service Edge Migration
Deploying SSE requires first deploying CASB, SWG, and ZTNA technologies, each of which involves its own significant planning and migration efforts. Organizations should plan to migrate users, devices, data, and applications to SSE in stages, and a staged approach can be used for any major technology updates. Start by designing and deploying a small pilot to identify and resolve any major issues. Then, gradually expand the pilot to cover more users, devices, data, and applications.
One caveat: Often, businesses need to migrate their users’ on-premises and cloud-based services and applications before they can enjoy the full security benefits of SSE. One of the main benefits of SSE is that users do not have direct access to services and applications. Instead, users access them through the SWG, which acts as an intermediary for applying security policies and monitoring threat activity. CASB and ZTNA provide further security benefits such as authentication, access control and behavioral analysis.
However, until all users migrate to SSE, the services and applications they access will be more exposed and at higher risk of compromise. Therefore, if possible, it is important to keep migration cycles relatively short to achieve stronger security faster.
2. Monitor first and then enforce policy
SSE components (especially ZTNA) tend to be more restrictive than the traditional security technologies they replace. For example, SSE may frequently check device health, user behavior, and other usage characteristics. Overall, this is very beneficial for the security posture of the enterprise, although at first it can lead to some unpleasant surprises and operational disruptions.
When feasible, especially in initial pilots, run SSE in monitor-only mode, without enforcement, to see what the technology blocks and why. This often uncovers existing security policy violations, and in some cases points to where SSE policies may need to be relaxed (at least temporarily) to address real-world behavior.
3. Determine which controls to add to SSE
Depending on the CASB, SWG, and ZTNA technologies it contains, SSE may have one or more vulnerabilities in its security controls. Fortunately, businesses can usually fix these vulnerabilities relatively easily by acquiring additional cybersecurity services. Any SASE security control that is not yet part of SSE, such as Firewall as a Service or Data Loss Prevention, is a worthy candidate for consideration.
If an enterprise’s SSE requires multiple additional controls, it’s best to take a step back and consider whether a full SASE deployment would be better. There are definitely advantages to a single SASE platform rather than integrating several different SSE and SASE components. However, if the SASE is too large or expensive, adding a separate control to the SSE is often still a preferable approach.
