SSE solution series: value realization in a production environment pilot

When considering security service edge (SSE) vendors, understand the steps required to run a pilot. For the right SSE vendors, the process should be finding a way to forward traffic to the SSE service edge, and then the SSE vendor’s own cloud takes over. There should be minimal steps for the SSE admin to take, other than establishing a forwarding mechanism, configuring basic policies, authentication, and reporting. Of course, advanced policy configurations will take more time.

The pilot should address a set of business outcomes and involve members of various teams, including security, network, and desktop (for the installation of the endpoint agents, for example). However, the active involvement of these teams should be minimal—they are, after all, looking to acquire a SaaS solution. SSE vendors that require deep involvement, particularly from networking teams to handle complex routing scenarios in a pilot, should be a red flag.

Take a sequential approach that reflects your business goals when planning for a comprehensive SSE solution pilot:

1. Review existing security posture, existing policies, network infrastructure and application requirements, authentication technology, traffic-forwarding options, and capacity.
2. Identify a set of source users/services and a set of destination applications on which to run the pilot.
3. Enable traffic forwarding for those users, most commonly with a single agent, but creating tunnels from a branch location can also be done; deploy virtual machine(s) in front of the chosen private applications.
4. Set up user authentication by provisioning Identity Provider integration.
5. Set up threat and data loss prevention using standard templates, including threat protection, sandbox policies, browser control policies, URL policy, cloud app policy, file type control, and API integration for SaaS and firewall policies.
6. Set up server discovery for private applications and access policy for those apps. This can be a *.* policy for the purposes of the pilot.
7. Set up SSL/TLS inspection, advanced policies, and additional capabilities like CBI, DEM, or CSPM.

All of the steps above should be straightforward and achievable by the SSE vendor in a short amount of time (most likely days) and without any major routing or configuration overhauls. While actual full deployment will require further steps, advanced policy settings, dealing with various types of applications and endpoints, and integrations and co-existence with other agents/technologies, the SSE vendor should be able to show the value of the platform through a straightforward yet well-executed pilot.

During the pilot, the SSE vendor must be able to prove the following, aligning with the six previous practices detailed in this document:

• Global cloud infrastructure with minimal latency to the end user that operates with high availability and performance. The vendor should demonstrate their ability to operate this cloud at scale and demonstrate the effect of failover.

• Zero trust for every user session, from protecting private applications, public applications, and even work- load-to-workload communications (if the pilot calls for this).

• Advanced threat protection and advanced DLP by peering into encrypted traffic. Certificate management may require some additional steps in the pilot, but proving the vendor’s ability to do SSL/TLS inspection with minimal latency added is an excellent way to differentiate one SSE vendor from another.

• Flexible deployment options. While this may not be part of the pilot, the SSE vendor must provide a plan to protect all users, regardless of location or application. It may require an understanding of deploying private service edges or CBI for contractors. The key point to verify is that the SSE vendor can meet the requirements of a distributed workforce and applications with their deployment models.

• Optimal user experience. This metric ranges from ease of use (how does the end user interface with their agent, for example), to the general user experience of accessing both public and private applications over their SSE platform. The vendor should be able to measure and diagnose a broad set of end-user performance issues (Wi-Fi, ISP, CPU, etc.). This ability to measure/diagnose should be built directly into the SSE platform without the need to deploy any new agents.

• Third-party vendor integration. While this also may not be part of the pilot, the vendor must supply methods to integrate log data into an external SIEM tool or integration with an EDR tool in place. The SSE vendor should analyze the tool ecosystem in place and provide recommendations to integrate once the actual deployment begins.

Give preference to SSE vendors that require the least amount of overhead, given the skill and personnel shortage faced in the industry.

Outcomes

A worthwhile pilot will prove the SSE solution is easy to deploy, performs in your production environment, and achieves your objectives:

• SSE vendors that can seamlessly pilot their solution bode well for full deployments. With the goal of low TCO, a single unified agent, access to a global set of service edges, and a centralized and easy-to-use UI all make the ongoing maintenance of the solution straightforward. Any large-scale deployment will require time and effort, but the goal should be to work with the vendor that minimizes it.
• An SSE’s architecture and design should make it easy to add on features with minimal additional deployment requirements (like additional agents or VMs). This way, buyers can take a phased approach to SSE, knowing that moving between phases will not require heavy lifts.
• Ultimately, the goal is to have confidence that the SSE vendor will deploy smoothly in a production environment and be by your side during unavoidable hiccups. Customer-focused vendors with proven architecture are your best clues that your security and network transformation investment will succeed.

Part 1: SSE solution series: why a global, scalable cloud platform matters
Part 2: SSE solution series: the criticality of a zero trust architecture foundation
Part 3: SSE solution series: choose SSL/TLS inspection of traffic at production scale
Part 4: SSE solution series: virtues of broad blanket protection
Part 5: SSE solution series: the user experience imperative 
Part 6: SSE solution series: the power of 3rd-party ecosystem integration

Editor's note: This content is adapted from The 7 Pitfalls to Avoid when Selecting an SSE Solution