Whistleblowers of a Fake SASE are IT’s Best Friends 

Listen to post: Getting your Trinity Audio player ready...

History taught us that whistleblowers can expose the darkest secrets and wrongdoing of global enterprises, governments and public services; even prime ministers and presidents. Whistleblowers usually have a deep sense of justice and responsibility that drives them to favor the good of the many over their own. Often, their contribution is really appreciated only in hindsight.  

In an era where industry buzz around new technologies such as SASE is exploding, vendors who are playing catch-up can be tempted to take shortcuts, delivering solutions that look like the real thing but really aren’t. With SASE, it is becoming very hard for IT teams to filter through the noise to understand what is real SASE and what is fake. What can deliver the desired outcomes and what might lead to a great disappointment.  

Helpfully for IT teams, the whistleblowers of fake SASE solutions have already blown their whistles loud and clear. All we need to do is listen to their warnings, to the red flags they are waiving in our faces, and carefully examine every SASE (true or fake) solution to identify its’ real essence. 

The Fragmented Data Lake Whistleblower 

As more and more legacy products such as firewalls, SWG, CASB, DLP, SD-WAN and others are converging into one SASE platform, it can only be expected that all the events they generate will converge as well, forming one unified data lake that can be easily searched through and filtered. This is still not the case with many vendor’s offerings. 

Without a ready-made, unified data lake, enterprises need a SIEM solution, into which all the events from the different portfolio products will be ingested. This makes the work of SIEM integration and data normalization a task for the IT team, rather than a readily available functionality of the SASE platform. 

Beyond the additional work and complexity, event data normalization almost always means data reduction, leading to less visibility about what is really happening on the enterprise network and security. Conversely, the unified data lake from a true single-vendor SASE solution will be populated with native data that gives rich visibility and a real boost to advanced tools such as XDR. 

Think carefully if an absence of a ready-made unified data lake is something you are willing to compromise on, or should this red flag, forcefully waved by the data lake whistleblower, be one of your key decision factors. 

The Multiple Management Apps Whistleblower 

One of the most frustrating and time-consuming situations in the day-to-day life of IT teams is jumping between oh so many management applications to understand what is happening, what needs attention, troubleshooting issues, policy configuration and even periodic auditing. 

SASE is meant to dramatically reduce the number of management applications for the enterprise. It should be a direct result of vendor consolidation and product convergence. It really should. 

But some vendors (even big, established ones) offer a SASE built with multiple products and (you guessed it) multiple management applications, rather than a single-platform SASE with one management application. 

With these vendors, it’s bad enough having to jump between management applications, but it can also mean having to implement policies separately in multiple applications.  

The management whistleblower is now exhausting the air in her lungs, drawing your attention to what might not be the time saving and ease of use you may be led to expect. Some might like the overflow of management applications in their job, but most don’t.  

Multiple managements applications can be hidden by a ‘management-of-managements’ layer. It might be a good solution in theory, but in practice – it means that every change, bug fix, and new feature needs to be implemented and reflected in all the management applications. Are you sure your vendor can commit to that?  

Making Sure SASE Projects Are a Success | Watch the Webinar

The Asymmetric PoPs Whistleblower 

This one is probably the hardest one to expose, but once seen – it cannot be unseen. 

Vendors who did not build their SASE from the ground up as a cloud-native software often take shortcuts in the race to market. They create service PoPs (Points of Presence) by deploying their legacy point products as virtual machines on a public cloud like GCP, AWS or Azure. This is an expensive strategy to take on, and an extremely complex operation to build and maintain with an SLA that fits critical IT infrastructure requirements. 

Some may think this is meaningless, and that as long as the customer is getting the service they paid for, why should they care. Well, here is why. 

To reduce the high IaaS costs and the operational complexity, such vendors will intentionally avoid offering all their SASE capabilities from all of their PoPs. The result of this asymmetric PoP architecture is  degraded application performance and user experience, due to the need to route some or all traffic to a distant PoP for processing and inspection. So, when users come in complaining, do you think that saying you are supporting the cost saving of the SASE vendor will be a reasonable explanation? 

The asymmetric PoPs whistleblower recommends that you double check with every SASE vendor that all their PoPs are symmetric, and that wherever your users and applications are, all the SASE services will be delivered from the nearest one PoP.  

Epilogue 

Whistleblowers are usually not fun to listen to. They challenge and undermine our believes and perception, taking us out of our comfort zone. 

The three whistleblowers here mean no harm, only wanting to help minimize the risk of failure and disappointment. They blow their whistles and wave their red flags to warn you to proceed with caution, educate yourself, and select your strategic SASE vendor with eyes wide open.