SSE solution series: why a global, scalable cloud platform matters

SSE can be a catalyst for change in an organization just by securing the business in a remarkably comprehensive way. But not all solutions are created equal. If you are looking to adopt SSE, evaluate and select the right solution by understanding your options including the services, architecture, and functions available across alternatives. Done right, this journey will be a path away from the “old ways of working,” such as anchoring to networks or allowing blanket access to services, which limits the ability to transform and meet the needs of the business.

In this first installment of pitfalls to avoid on the enterprise digital transformation journey to SSE, we'll explore how to stay clear of a solution that lacks a proven track record of operating a global cloud platform that scales for performance and availability.

The case for a multi-tenant, SSE platform

Building and running a multi-tenant, SSE platform for billions of transactions is much more than the level of compute and is not a simple thing. The SSE solution will be entrusted with the protection, connectivity, and enablement of your enterprise, and therefore it must deliver the set of SSE services uniformly and timely to all parts of the organization.

The correct SSE solution will deliver services to your enterprise through a globally distributed service. Architecturally, the most effective way of delivery is through a proxy-based service. Not anchored to the network state, a proxy service focuses on delivering SSE to the application access, allowing for greater comprehension without offloading to additional platforms for insights like inspection at scale.

Note that true proxy architecture takes significant R&D effort and many years of refinement to achieve the scale requirements of the modern enterprise. The right SSE solution will have scores of examples of large deployments where the proxy architecture was shown to scale. This service must be delivered through a uniform set of policy edges where any and all data transmission functions of your enterprise are protected and it should not just be the number of nodes, but rather the number of SLA guaranteed sites that offer services needed by the customer. The SSE provider should not provide public PoPs if it cannot guarantee the SLA in that region due to poor peering or other reasons.

Adopting SSE means you’ll consolidate, invigorate, and share the responsibility of your enterprise security, connectivity, and control with a trusted security vendor. This shared model will simplify the means by which you deliver protection and connectivity for your users, workloads, services, and branches, amongst others. The SSE provider must deliver on a set of defined, proven SLAs to ensure the function of your enterprise, while also delivering protection.

When your enterprise service connects, it needs an effective path to consume the destination function. This can only be achieved through an SSE solution with highly effective peering within carrier-neutral data centers. Therefore controls must be applied in-line, between the source and destination—regardless of the location of a source and/or destination.

Solutions that host the security service within central compute clouds, often within hyperscalers and have ingress gateways (often referred to as on-ramp services), rely on distributed ingress edges, but process policy control and application centrally, thus introducing unwanted latency and resulting in poor user experiences.

SSE vendors must have a demonstrated complete, massive, and scalable cloud platform. Beyond SLAs, the SSE platform should also provide evidence of scalability, stability, availability, geographic deployment, etc. To validate this review, consult publicly provided historical data and speak with existing customers to understand their experiences.

Uniform Edge Policy Enforcement

An SSE vendor´s set of service edges must deliver policy enforcement. They cannot be edges of connectivity to a larger, cloud-based network, solely to route or “on-ramp” your traffic to the central enforcement infrastructure. Such schemes defeat the purpose of providing highly effective, low latency services. The vendor needs to address the following design considerations, ensuring that the edges must:

• Be hosted in vital peering locations within carrier-neutral data centers, thus ensuring minimal latency between the source and destination. When assessing an SSE vendor, review the statistics from public references like PeeringDB and partner deployments.
• Be supported with a valid SLA. This will reassure the stability of the business functions and indicate that the SSE vendor is working in regions to guarantee the SLAs.
• Be deployed privately on a per-customer basis in locations where local conditions require more nuanced deployments, such as on-premises or within an edge compute node.
• Demonstrate a historical path of throughput growth.
• Deliver fault tolerance deployed in active-active mode to ensure availability and redundancy. (The vendor monitors and maintains its public service edges to ensure continuous availability.)
• Promote data privacy to ensure that customer traffic is not passed to any other component within the infrastructure and no data is ever stored to disk.
• Provide uniform controls for enterprise resources at all edges and not route or “on-ramp” traffic from remote edges to central locations.
• Enforce global scale protection to protect all enterprise services once a threat is detected.

Selecting an SSE solution that scales for your business today and, more importantly, for your future goals is a critical investment. Scalability is not simply the mechanism to build out, but more importantly, address your enterprise needs without sacrificing your business's function, stability, and protection. Consider the following additional solution criteria:  

• Evidence and transparency of its global and diverse deployment
• Documented and validated SLAs for the loss of or degradation of SSE services
• Proven deployment of a large number of customers of similar size and complexity as your enterprise
• Publicly available information for each PoP using public tools (e.g., PeeringDB)
• Delivery of all critical functions at all sites without hairpinning traffic
• In-line protection between the source and destination
• Infrastructure operational and functional resilience
• Consumable in multiple forms across multiple sites

In the next installment, we'll examine how to tell if an SSE solution is based on a zero trust architecture foundation. 

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