As companies increasingly move to cloud architectures, they’re looking for ways to increase security while also reducing complexity and operating costs. And of course the move to remote work – which boosts the need for hybrid cloud and Software as a Service – only accelerates the need for these requirements.
All of these requirements can be addressed by an emerging tech that’s high on the current hype cycle for enterprise security: Secure Access Service Edge, or SASE. The benefits are outstanding: SASE is an architecture that combines networking concepts like VPN and SD-WAN, along with security concepts like Zero Trust (another compelling but often over-hyped concept) and contextual access.
But at this point, SASE represents more of a goal or concept for most organizations than a product. Nevertheless nearly all the major vendors have seized on this concept (e.g., Cisco, Palo Alto Networks, Zscaler, Akamai, McAfee, etc.) and labeled many of their components as critical to achieving SASE.
But as attractive as the concept sounds, in practice there are many hurdles companies need to overcome in order to turn SASE hopes into reality.
Challenges of SASE Deployment
In broad terms, SASE is the integration of network services with security services to make user access, SaaS and multicloud functions fully secure. It includes capabilities inherent in SDWAN deployments, like path resiliency and redundancy. It also offers app routing, visibility and reporting, vendor-specific software defined capabilities, and VPN.
SD-WAN, which helps virtualize networks and their operations, is deployed widely, but does require that enterprises replace older single function switches and routers with new equipment. This virtualization of networking has been going on for several years, and the majority of enterprises have virtualized most of their networks, or at least a major portion.
This is a critical step, as SASE requires a virtualized network in order to be implemented. Further, the public cloud networks are all virtualized so heavy users of these services have a built-in advantage.
The more difficult part of realizing SASE is the need for a security architecture that can be fully integrated and managed, much like software-defined networks are. But the majority of enterprises currently have a hodge-podge of security products in place that are nearly always stand-alone.
In fact, some organizations have dozens, if not hundreds, of unique security apps running on everything from their data centers or cloud instances, to networks, to hardware endpoints, and to individual apps. Even the ubiquitous VPN necessary to securely connect over networks may not be cross-compatible with all the devices and servers within the organization. And with an increasing number of network options available (e.g., 5G, WiFi 6, broadband), this represents its own compatibility challenges.
SASE requires a uniform method of policy management, secure access, threat protection and device management in order to be fully implemented. And with so many security components in place that generally do not play well tougher, this is a daunting task.
One final obstacle to overcome is organizational. In most enterprises, networking and security operations are unique groups, not necessarily always in close contact. For SASE to be fully implemented, both network ops and security ops must be on the same page and working together. Without this interaction, implementing SASE isn’t possible.
Implementing SASE Requires Major Integration
Despite what many vendors promote when selling their products, achieving SASE is really a major integration challenge. And many smaller organizations do not have the resources to make this happen, even if they do have some components already in place (e.g., SD-WAN, cloud access gateways, etc.).
Even larger firms will have difficulty making sure their entire network and security tools and cloud management products are able to share information and be managed through a single interface. While it’s possible to have a SASE implementation without a universal control plane or single pane of glass console, the cost of such a solution is much higher in skills required, people required, and time spend compared to a single management interface. It’s also problematic in that it’s much easier for problems to arise due to a lack of visibility when non-compatible systems are manually managed.
For many companies, the best path forward to SASE is to find a systems integrator that can not only integrate the necessary tools but also can manage the day-to-day operations of their SASE architecture implementation. However, enterprises should be aware that SASE is a “moving target,” in that few companies have all the components in place, and even ones that do will likely face upgrades and changes to infrastructure over time as capabilities mature.
Network operators (e.g., Verizon) have created SASE practices that can provide “SASE as a Service” on top of their connectivity and security service operations, but enterprises will still need to manage the relationship and devote resources to ensure the latest updates in network and security are fully implemented as business needs and infrastructure changes take place.
Further, service providers will have their own set of preferred partners that may not be compatible with the vendor products the enterprise currently has in place. Still, this may be an advantageous path, as these operators can leverage both their ability to influence vendor apps, as well as their learned experience in making SASE work effectively.
Market Consolidation Needed before SASE Maturity
SASE as a concept has a lot of merit in that it can significantly improve the security posture of organizations, particularly in a cloud-heavy world in which we now reside. But achieving the realization of SASE is not as straight forward as many vendors’ hype makes it sound.
Indeed, we expect it will take at least 3-5 years before the SASE market settles on what the architecture really looks like and which vendors will be at the forefront (with market consolidation removing many players from the field in the interim).
Enterprises should definitely be evaluating the SASE architecture as a way to increase security, but must also be aware that current products may not be the end products in place in the future, and therefore deployment flexibility will be required.