In recent months, the term secure access service edge (SASE) has become prominent and has been promoted by numerous vendors. SASE stands for a concept that integrates a range of cloud-native security services including cloud access security brokers (CASB), firewall as a service (FWaaS), secure web gateways (SWG), and zero-trust network access (ZTNA), with wide-area network (WAN) capabilities for delivering both directly to any edge computing location.
In this context, the “edge” can be anything from a single user or device to whole branch offices or internet of things (IoT) fleets. This approach addresses the performance bottleneck issues of traditional networks that rely on traffic backhauling. Additionally, by integrating identity, business context and real-time risk assessment into every connection, SASE architectures promise to prevent multiple types of cyber attacks.
The idea of delivering SaaS-based security services with ZTNA and networking is definitely not new – some suppliers have been doing this for over a decade. Still, suppliers that deliver software-defined wide-area networks (SD-WANs), and other services listed above, find the sudden popularity of SASE appealing as a great marketing opportunity. However, for potential buyers there are a couple of aspects to look at.
SASE needs to go further than grouping various services
First, SASE is not a well-defined architecture in a narrow sense. It is more a part list of technologies, where vendors are increasingly filling the gap towards an architecture and to enable the various components to work together effectively.
Very few of these capabilities are prescribed by the definition or present in every solution offered under the SASE banner. In a sense, practically every security service delivered from a cloud infrastructure fulfils the basic criteria of SASE.
But just grouping various services will not be sufficient. Consistent policy management and enforcement across everything, security analytics spanning all the elements, and an integrated administration capability are mandatory for making SASE a holistic concept, instead of just being a set of disparate services. Yet none of these are included in the original definition.
Beware of supplier lock-in
A major challenge that comes with this need for integration is the risk of supplier lock-in. If SASE is a one-stop shop, then the risk of being locked into the approach of a single supplier – sometimes with few selected partners – is big. SASE needs to evolve to become an open, flexible, standards-based architecture, where different services from different providers can be easily combined. This is still a long way off.
Another aspect to consider is that, even while SASE solutions often include ZTNA as one of the capabilities, it may be debated whether the reliance on SD-WAN as the underlying infrastructure does not stand in contrast to the basic principles of zero trust. The risk is to assume that SD-WAN is always secure and can be trusted.
But trusting a single element in the multi-layered security stack is exactly what zero trust is not about. However, with the other elements such as CASBs and ZTNA for an identity-based access control to the network, there is no such conflict.
Consider single points of failure
The bigger risk might arise from having an overlay over the internet that might fail. While the internet was designed to withstand major disruptions, the recent incidents with edge providers such as Akamai or Cloudflare clearly show how the ongoing trend to reverse the internet’s decentralised nature can lead to massive outages. Similar challenges with CSPs have eventually led to the emergence of “multicloud” as a design concept. Should we plan for “multi-edge” architectures as well?
SASE comes with the promise of combining network access and cyber security services in one, and plays out its strengths as a single pane of glass, managed through a single set of policies. If you subscribe to such a service and need additional functionality beyond the initial use cases, it is highly likely that this is also available from the already chosen provider. Which brings you deeper into the dependency on a single supplier/service provider.
However, how will this impact the risk of rogue software attacks on this supplier? There is a price to pay, and buyers should be aware of the implicit risks that come with SASE.
Determine if SASE adds value or complexity
Last, but not least, buyers should first look at their use cases when considering SASE. Where does this approach add value, and where does it just add complexity? If office workers access SaaS services only, why add an extra layer of complexity?
On the other hand, for connecting factories, for use cases in commerce and logistics, and for areas that still run a lot of legacy IT such as many of the banks, SASE might provide a value. However, there are always alternatives for creating a secure, reliable infrastructure.
SASE is, as most concepts in IT, neither the one perfect solution for everything, nor is it sheer marketing buzz. Buyers should look carefully beyond labels, analyse their own use cases and requirements, and understand how they can be addressed by the capabilities of a particular SASE offering (don’t forget that capabilities may vary substantially between suppliers). They also have to think about the future – today’s requirements will inevitably change tomorrow, and a SASE platform must be flexible enough to adapt to them quickly.
Only once all these considerations have been taken into account will you be in a position to make an informed decision as to whether SASE is a good fit for your needs or not.
