Securing Private Access with SASE

ZTNA or SDP is a critical component of SASE to protect Private Access but also stands alone as identity-centric evidence-based access control that adheres to the Zero Trust principles. Our recent blog post on SASE, was about the importance of securing private access. In this installment we will focus on how ZTNA requires a different architecture than many other SASE components.

Appgate was listed as an example vendor offering SASE components in the Gartner report, “SASE Will Improve Your Distributed Security Everywhere” Published 8 December 2020 - By Analyst Richard Bartley. It introduces the concept of two types of SASE security components, that of egress and ingress. Gartner defines these as:

• "Egress SASE controls are those capabilities that help your users gain access to services anywhere on the internet in a secure manner."
• "Ingress SASE controls provide access from outside to internal applications within the extended enterprise."

The report goes on to list ZTNA as an ingress SASE component. This is a welcome area of clarification or distinction, because protecting private access is a fundamentally different problem than protecting internet traffic. Let’s explore why.

When we consider the networking side, SASE can be divided into 3 categories:

1. Ingress SASE - Secure Access to private applications, workloads, resources and internal networks (i.e., ZTNA/SDP)
2. Egress SASE - Secure Access to internet and internet-based SaaS applications (i.e., SWG, CASB)
3. Network Services - The network side of the SASE architecture (i.e., SD-WAN)

For the purpose of this blog we will define egress SASE as resources in the public domain that are accessible via publicly routable IP addresses. While ingress SASE concerning resources in the private IP space, which is non-routable, as defined by the IETF in RFC 1918.

1. Ingress SASE: Private Access

Private access is where most enterprise Intellectual Property (IP), Personally Identifiable Information (PII) and mission critical data are housed and therefore protecting it is of utmost importance. Settling for a sub-standard private access solution isn’t worth the risk.

Fundamentally different in architecture than internet access, Private Applications:

• Make use of many protocols and most TCP/IP ports including https/https. Unlike internet resources, there is no standard across all enterprise resources.
• Are often initiated by a user or user’s device but can also be server-initiated connections to user’s devices, or server to server connections.
• Are not easily categorized like internet content.
• Often are legacy or custom applications that don’t support modern web protocols or authentication mechanisms, or even require use of a thick client.
• Can be very dynamic and agile, sometimes delivered as code. Dynamic Devops processes inside an organization are all about private applications.
• Require Policy Enforcement Points (PEP’s) not PoP’s
• Rely on private controls where most still reside on trusted networks like AD connectivity, SSO, etc. that requires the user to be part of the trusted network to onboard a new device, set initial passwords etc. Immediately breaking that model poses a lot of issues within current enterprises and is the limiting factor for complete HTTP/HTTPS adoption. Outbound internet access control is much easier to shift away from traditional on-premises controls.
• Require the ability to enforce down rules- from resource to client devices, or network access when the user is not logged in to push software, passwords, group policies, etc.

Appgate SDP is a secure private access solution, providing fine-grained secure access to any private resource. A leader in the Forrester Zero Trust eXtended Wave, it is the most comprehensive, programmable and dynamic ZTNA solution on the market.

Appgate SDP:

• Is architected to support the complex and varied attributes that private resources require to secure both small and large enterprise.
• Provides both device (or system) based connectivity as well as user-based connectivity for all protocols and entitlements in either direction.
• Allows remote servers to securely talk with private applications and eliminates the need for an internally connected network in between.
• Creates just-in-time dynamic entitlements using metadata for highly agile environments.
• It performs a deep device risk posture check via local claims, a central management tool like CMDB, or utilizes existing endpoint protection tools to allow only protected and healthy systems connect to your network.
• Integrates with multiple Identity Providers (IdP) to provide the greatest flexibility possible.

2. Egress SASE: Internet Access and Internet-based SaaS applications

The two primary offerings to secure access to these resources are: Secure Web Gateway (SWG) – think internet, and Cloud Access Security Broker (CASB) – think public SaaS applications. Resources in this area are vast and include the World Wide Web and Software as a Service like Salesforce and Office365.

There are common elements for internet access:

• Almost all resources are initiated connections from the user or human being.
• Most of the time resources here use a common protocol standard HTTP or HTTPS. When accessing an internet-based resource via a browser you would navigate to http://www[.]duckduckgo[.]com (typical internet access) or https://login[.]salesforce[.]com (a public SaaS application) for instance.
• Public websites are categorized to provide high level filters for an enterprise.
• For accessing public addresses, the closer the “filtering point” is to the user’s device the better the performance and user experience.

These elements are vastly different from private access. This requires SWG and CASB vendors to build a large number of Points of Presence or PoP’s. These are locations where a vendor can hand-off internet bound traffic to the nearest carrier or ISP backbone. Appgate SDP isn’t an egress SASE component but is architected to help control egress traffic and integrates with other egress security tools.

Appgate SDP:

• Works with and tightly integrates with other egress SASE components with robust APIs, and extensible scripting capabilities to build a cohesive security ecosystem.
• Can proxy or tunnel non-private application traffic (internet-bound egress traffic) and assign geo IP based policies to direct it to the closest SWG/CASB location without the need to route it over internal network links. This can eliminate or greatly reduce inter network connectivity costs. Making it very easy to integrate them with your current or future egress SASE SWG and CASB solutions.
• Enables the ability to have a single unified policy model for inbound and outbound traffic. Unifies user, device, geo-IP, and even endpoint protection profiles to assign specific ingress/egress traffic policies.
• Controls and modifies your user’s DNS settings in a cohesive way, using a unified policy model.
• Enforces “trusted device” and ensure users are trusted before allowing access to SaaS applications providing an extra layer of security to CASB.

3. Network Services: Site-to-Site Network Connectivity

This area is becoming less and less critical as enterprises are undergoing a complete workplace transformation and creating a truly Café Style network where every user is treated identically whether remote, at HQ or at a branch office. Effectively replacing the WAN.

There are many ways to achieve Site to Site connectivity. Some are inexpensive, some costly, and some complex. The level of security varies by different methods and technologies used. Currently SD-WAN is the primary method to securely connect sites to each other and is one of the core components of the SASE framework. Appgate SDP isn’t an SD-WAN but is architected to provide secure network WAN connectivity and work with SD-WAN solutions to add granular access inside the network.

Appgate SDP:

• Works with any SASE provider on any type of connection: SD-WAN or DIA, broadband, private line, MPLS, etc.
• Is architected to create a complete enterprise-wide Café Style network.
• Extends Zero Trust into branch offices and creates ultra-secure site to site connections over inexpensive commodity broadband, reducing complexity and saving money on expensive circuits while providing improved security.
• Provides granular network connectivity and secure least privileged access to private resources across almost any connection.

Conclusion

This is the basis of why the private access component or ingress SASE is different than the other web-based mechanisms broadly supported by Internet and SaaS applications. This is why Appgate SDP is architected to support the broadest set of enterprise private access needs. It complements and tightly integrates with the other areas of SASE to create a cohesive security ecosystem.

Read analyst group 451 Research’s take on SASE and ZTNA.