SSE

What They Won’t Tell You (But I Will)

Part 1 of 3: You haven't identified all your requirements

Welcome to my latest blog series where I provide an insider's perspective on SSE (security service edge) adoption in the enterprise and commercial segments. Why? Glad you asked.

The algorithm of a popular professional networking site (I’ll let you guess which one) recently served up a prompt, asking me for my thoughts. "A vendor's software demo falls short of your enterprise needs. How do you respond?"

I responded—even though I'm a vendor (take that, AI).

The demo is just the beginning. Now say it back.

For as many commonalities as enterprises share, they have just as many differences, so deployments will always require customizations. It’s a learning process for both SSE vendors and potential buyers. The demo is just the beginning of that process, where both parties have the opportunity to learn more about each other and begin to understand what success could look like.

All that to say, a demo with gaps or even some misses is not the end of the world. In fact, it’s the first chance to improve the product—and the outcome.

So here’s my totally biased but very experienced advice for SSE buyers in the demo stage of their buying cycle.

Uh oh—you haven’t identified all your requirements

In many ways, the demo stage is almost more work for buyers. You must effectively communicate your needs, goals and expectations, and ask all the right questions. Easy, right? (Points deducted from anyone nodding.)

But too many arrive at demo day with a fledgling understanding of their actual must-haves, limitations or desired outcomes. Identifying these requirements beforehand can tip the scales and define a positive trajectory for the relationship.

A few key factors will make it a whole lot easier.

Embrace the mess

The truth is, cloud transformation is messy—and the bigger you are, the messier it is. My top tip? Embrace the mess (and make sure your SSE vendor is a willing participant).

Your journey to the cloud will be a collaboration with your vendor, whether you want it to be or not. Along the way, you will discover new problems that will require engineering problem solving, and your ability to succeed depends on this collaboration extending past the point that your check clears. And if your vendor is not up to this task, you will be one of the many organizations who end their journey with a different vendor than the one they started with.

Get everyone on board

Integral to this collaboration is your stakeholders. Preparing stakeholders to embrace a messy, fail-forward approach is paramount to your success. Hey, I never said this was easy. But nothing worth doing is ever easy.

Anticipate the need for, and acquire, top-down support for your transformation. You may be the driver, but everyone will contribute. The compliance team is likely needed to offer up some exceptions, and the endpoint team may be helping with a few more agent deployments than they would prefer. But get their buy-in and support (you'll need it).

Sprint to your MVP with blinders on

This might sound obvious, but I can’t tell you how many relationships have withered on the vine because of it. Make sure you have clearly defined the MVP (minimum viable product), and that everyone is driving towards it. Be careful not to scope creep yourself into blowing past your deadline for frivolous pursuits. There's always a shiny roadmap item just around the corner. Don't chase it if it’s not necessary to achieve the MVP.

My advice: Sprint to your MVP with blinders on. Get the transformation win against the MVP definition of success. Your board of directors probably doesn’t care about a few oopsies, but they definitely care about avoiding a seven-figure renewal of the incumbent technology that you are about to throw away.

Take the win, then iterate your way to the shiny objects. Say it with me: Decide, adopt, optimize. In that order.

Vendors, listen up

Vendors, this one’s for you. That first demo is a chance to display your willingness to really listen to customer needs and execute the SDLC (or “software development lifecycle” for anyone without brain space left to untangle acronyms). And this ongoing cycle of listening and improving continues through deployment and beyond, because of course, not all requirements will be fully understood on Day 1. You're the other half of this collaboration and have to give just as much as you're getting for long-term success.

Part 2 of 3: You’ll need SSE to deliver more than security

Listening to customers pays off big time

Symantec and Carbon Black get hundreds of stellar new feature requests every year (our customers are the best, after all). These great ideas help drive our customer-centric innovation, and also underscore one of the hardest parts about being a product manager: When all the ideas are great, how do you decide what to build?

The good news is that we’ve gotten pretty good at picking the right new features and building a lot of them into releases. (Hey, it’s not bragging if it’s true). When SGOS 7 for Edge SWG shipped, we closed over 100 customer feature requests. On the cloud side, we recently launched Agent Traffic Manager (ATM), addressing 20 unique feature requests in one fell swoop. I recently dropped a post on LinkedIn (where our marketing overlords can’t control me) showing the pace of Network Security feature request delivery over the past year. Spoiler alert: That team alone delivered 129.

But the pace of delivery only tells half the story. The real test is if your features get adopted and I’m happy to say that ours usually get adopted by customers in production even before we remove the “Preview” badge. When we say we listen to our customers, we mean it.

And this is paramount to uncovering less apparent (but still important) pain points.

What may surprise you is that these feature requests are not always as traditionally security-focused as you might think. If you talk to an analyst about SSE or zero trust platforms, they will spend 95% of the time talking about the security capabilities of the various vendors. And that’s not necessarily a bad thing; security is why we’re here after all.

But what we’ve seen over the last 10 years of fielding customer-generated ideas and building Cloud SWG is that the highest concentration of customer SSE pain doesn’t stem from security efficacy—it’s from the data path. If you’ve deployed SSE, you know exactly what I’m talking about.

Data paths: IYKYK

Analysts dislike talking about the data path. It’s very messy. It’s much easier for them to point out some new “shiny security object” that you don’t have, and help you find where to purchase it (they undoubtedly have a very nice chart for that). You also think the chart is very nice and decide to purchase. Fast forward to a few months after multiple attempts and you still haven’t hit your deployment targets, you’re unhappy with your vendor and you’re left wondering how such a fantastic chart could have steered you wrong.

Unfortunately, this is all too common. The data says a pretty large percentage fail to adopt the vendor’s solution from the chart. Why? My hypothesis: Customers don’t account for challenges in the data path, the topic the analyst conveniently left out of their presentation and off their chart.

Data path, connectivity … tomato, tomahto

Outside the vendor sphere, the more common term for “data path” is “connectivity.” Way back in the olden times, when network security all lived within the confines of the corporate network, connectivity to the security stack was easy.

But this is not the case with SSE. With SSE, you have to move all the flows that previously terminated in your data center to the SSE stack (someone else’s data center). And depending on exactly how your network is built and how much traffic you have, the job of moving that data can be the single most important challenge of the SSE adoption journey (hence the demand for features that improve the ease of implementing the SSE data path—and our obsession with making it happen).

Features that make your SSE journey easy (well, easier)

Thanks to our customers' brilliance, our Cloud SWG roadmap has focused primarily on three key features. Simply knowing about these can help you understand more about your own environment, and will hopefully help you avoid the pain of selecting a vendor with more regard for their location on "the chart" rather than for your SSE connectivity needs.

Premium Routing. Thousands of content providers wall their apps off to certain source IPs or geolocations (or both). Odds are, your users already have registered your corporate IPs with SaaS apps for this reason. You also probably have unhappy line-of-business teams that struggle to gain access to business-critical applications hosted in other countries, thanks to geofencing. Moving to SSE can break access to these apps if you don’t have something like Premium Routing in place to compensate.
Agent Traffic Manager. Before the pandemic, 75% of SSE connections came from site-to-site tunnels. During the pandemic, those numbers flipped and 75% of SSE traffic was redirected to the cloud using an agent. With so many hybrid work scenarios, customers needed more granular and flexible agent traffic intercept policies. Luckily, with ATM, even the most complex hybrid work scenario can be accommodated by our agent.
Cloud SWG Express Connect. Connecting large, multi-gigabit workloads to SSE is extremely difficult using traditional site-to-site tunnels. A 10gig workload connected via IPsec or GRE would require 5-10 tunnels with a load balancer to evenly distribute the traffic across the tunnels. It’s very complicated to build, very fragile and very static. But with this new high bandwidth connectivity capability (realized through a partnership with Google and currently in preview, so stay tuned), customers can connect massive workloads (100 Gbps or faster) securely to our SSE without the need for a single tunnel.

Here’s your homework assignment

If these feature concepts are not familiar to you, spend some time with your team digging a layer deeper into your data path needs. Make sure you're taking into account the inconvenient but very real corner cases that could derail your SSE adoption.

And pro tip: If you operate virtual desktop infrastructure (VDI), make sure you've completely worked out how you will connect those systems to your SSE vendor before signing.

As Technovera Co., we officially partner with well-known vendors in the IT industry to provide solutions tailored to our customers’ needs. Technovera makes the purchase and guarantee of all these vendors, as well as the installation and configuration of the specified hardware and software.

SSE: What They Won’t Tell You (But I Will)

Source