Gartner recently released a new Magic Quadrant for SSE – Security Service Edge for 2022 in addition to the Critical Capabilities Guide for SSE. Yes, it’s SSE and it’s not a typo – we didn’t forget the “A”. So, what about SASE – and why the need for another IT acronym? While the differences in the two may seem subtle, the application of technologies that fall into this space are distinct with the COVID Pandemic serving as the backdrop and impetus for the need in re-classification.
For starters, let’s look at a quick definition of both:
SASE: Secure access service edge connects and secures users, devices and locations accessing applications. Software-defined wide-area network (SD-WAN) products replace traditional branch routers. SASE does not make SD-WAN obsolete. Instead, SD-WAN is a foundational component of SASE. SASE offerings converge multiple networks and “Security as a Service” capabilities, such as SD-WAN, SWG, CASB, NGFW and zero trust network access (ZTNA).
SSE: Security service edge secures access to the web, cloud services and private applications. Capabilities include access control, threat protection, data security, security monitoring, and acceptable-use control enforced by network-based and API-based integration. SSE is primarily delivered as a cloud-based service and may include on-premises or agent-based components.
In evaluating the difference between the two, the timeline is important. For SASE, its emergence was preceded with the push to make access to infrastructure resources – namely compute, storage, and network – more flexible and agile. The growth of the Software-Defined Datacenter (spawned by virtualization) allowed for access to resources in a new way that essentially ushered in cloud computing. With these resources more readily available, developers could innovate at a pace that previously relied on more rigid enterprise IT processes. The rise of shadow IT forced Enterprise IT to re-evaluate how they designed and architected the datacenter, but with the democratization of resource access, new “born-in-the-cloud” organizations offered LOBs the same agility and flexibility as developers. Increasingly business apps and workloads move to SaaS and PaaS services. Data sources and services became increasingly diverse and distributed. The only hindrance? Connectivity. More specifically, secured and compliant connectivity. Traditional DMZ networks and full access to telemetry data for QOS and compliance auditing were no longer applicable – since more of the business workloads now resided outside of the internal business network. SASE served as the new modern approach to how we design and deploy the modern, cross-connected, compliant and secure network. SD-WAN, SWG, CASB, NGFW and even ZTNA were geared toward securing the data and application services with less emphasis on the securing access at the remote user.
And then COVID-19 happened.
The explosion of remote work exponentially expanded the use of technology in every aspect of our lives – both personal and professional. Organizations rushed to deploy remote technologies – in some cases sacrificing security in the rush to provide data and application access to knowledge workers so that business could just, frankly, continue. Now, the unmanaged, under secured, and un-monitored Work-From-Home network became the new attack vector for threat attackers – and that’s not including the millions of deployed (exploitable) IOT devices like doorbells, cameras, wi-fi appliances, TVs – that also traverse that same WFH network that is now BUSINESS CRITICAL.
SASE wasn’t built to address that. And with the volume of attacks increasing and the sheer amount of telemetry data that is now produced from all of the connections, devices, data, and apps, no number of point-solutions and manual threat monitoring can be counted on to protect your most critical IT assets. Extensibility to integrate, in some cases, competitive solutions, and do so rapidly was paramount. Integrating AI for threat analytics and utilizing Cybersecurity meshes deployed as external service fabrics was necessary. Distributing these constructs at all resource points – on-premises, public/hybrid/multi cloud, and at the edge – is now table stakes. Focusing security effort at the WFH user identity was no longer just an option.
Thus, the need to define a new category and approach – SSE.
Generally speaking, if SASE has a focus around primarily prevention (specifically around data/app services in the “new” extended network), SSE has a focus on Identity Access Management with security by optimizing Detection, Isolation, and Remediation – the key components of MDR. It’s also important to note that SSE is not a replacement for SASE – both are needed to build a modern security strategy.
NOTE: SSE in many cases is covered by SASE, but in larger enterprises (or organizations that have segmented network and security teams) implementation of SSE maybe necessary as a separate component in order to accelerate deployment of security initiatives – not doing so could result in gaps for potential exploit.
Our field CISO Dave Trader did identify challenges:
“The challenge that needs to be addressed is around the privacy and ownership concerns around data and control. Because WFH networks also carry personal data traffic, it will be problematic to get agreement from remote knowledge workers and may also have potential legal ramifications for the organization. The ability to route the traffic to an MDR and access to remediate for a WFH user may be the most feasible way to successfully deploy SSE. Aside from IAM, there isn’t the ability to take action on notifications and alerts that require the capability to respond as dependency on WFH users to patch and update – as well as provide remedial efforts – is slim.”
This most likely will pave the way for new technology tools and platforms to solve this challenge as making anything “simple to use” is in actuality, very complex to design.
The final piece to building the modern security strategy is what to do when you are breached – the ability to ensure recoverability. But that’s a discussion for next time :).
