Realizing Identity-aware SASE with Identity based Policies

Why Identity awareness in SASE?

My previous blog on Deciphering SASE talked about identity awareness in various security components of SASE. This post describes the various methods for realizing identity-aware SASE.

Access controls in traditional perimeter-centric security are defined using IP addresses and services. Clients are represented as IP addresses in access policies, and services are defined either with domain names & IP addresses along with TCP/UDP ports such as Port 80 for HTTP and 443 for HTTPS, etc. Since there are different types of clients – Human users accessing services via PCs/Laptops/Mobiles, client applications, IoT devices, and various human user categories, segmentation approach with each segment representing various types of clients is invented. Each segment is given its own subnet or IP address range. That makes it possible to define access controls for different types of clients.

Though it addressed some challenges in defining the access controls for various clients, it introduced another set of complexities – Segment management. Quickly, many organizations started to see the explosion of segments. Organizations started to see the need for creating various segments for defining differentiated QoS, WAN link selection, and various types of security access controls.

Another big challenge with segmentation is related to “work from anywhere.”  That is, the user IP address keeps changing based on where the user is working from. In this case, user association with a segment quickly becomes a big challenge. Users working from designated offices, from home, from coffee shops, from another office, or from partner offices shall be treated the same way, irrespective where the user is working from.

Identity-aware SASE makes segment management simpler by taking away the need for creating segments for differentiating clients, at least for human users. You may not completely get rid of segments for clients such as IoT devices, though.

Identity-aware SASE is also required for ‘Digital Forensics.’  When there is any data breach, it is important to know what happened during the attack to understand the approach used by attackers, weak points exploited, and to identify the overall impact. According to the “2022 Verizon Data Breach Report”, 82% of data breaches involved the human element.  Hence, the identity of each connection/session becomes super important to understand the access patterns, sites visited, devices & applications used by the user that resulted in the first infection. Then, that further can help in finding out the lateral attacks that ultimately result in the breach.

In summary, identity awareness in SASE helps in:

• Defining differentiated access policies across firewall, SWG, CASB and ZTNA for various users
• Defining differentiated network policies across QoS, Routing for various users
• Digital Forensics
• User behavioral analysis

Identity in SASE policies

SASE components control access to various services/sites at different granularity. Firewall of SASE control access at the L3/L4 layers. SWG controls access at the level of URLs. ZTNA and CASB control access at the level of APIs. SWG, ZTNA and CASB with DLP can control the access at the data level. All these controls are required with the user as one of the selectors for the reasons explained above and to meet zero trust guidelines specified by NIST.

Any access control policy contains a set of rules, mostly ordered rules. These rules are checked for every traffic session. If the rule matches, actions specified at the matching rule are taken. Typical actions include allowing the traffic, denying the traffic, or just monitoring & logging the traffic. Matching of any rule is with a set of attributes. Each rule is specified with values of these attributes. Those attributes traditionally include 5-tuples (source IP, Destination IP, Protocol, Source Port and Destination Port), Zones and locations. Upon a new traffic session, values are extracted from the packet and the context (zone, location) and matched with rule attributes’ values. If they match, the rule is said to be matched.

With identity awareness SASE, rule matching attributes include user attributes. User attributes can be a set of individual usernames, user groups, user roles, client certificate subject names, or certificate subject alternate names. Policy matching shall include matching with the user context for identity-based SASE.

Typical policy matching on a new traffic session is as follows:

• Extract 5 tuples (Source IP address, Destination IP address, IP Protocol, Source Port and Destination Port) from the packet.
• Get the source zone and location from where the traffic session originated from.
• Get the information of the user (name, user group and user role) that initiated the traffic session.
• Get device posture of the machine from where the traffic session originated.
• Walk through the rules from top to bottom of the policy by matching the above extracted information with rule matching attribute values. If there is a match, take action specified in that rule. If not, go to the next rule.
• If there is no matching rule, take action configured for that policy table level.

User identification and authentication

Since a user needs to be identified before any policy checks on the traffic sessions, a few questions that arise are:

• How does SASE authenticate the users?
• How does SASE identify the user when it receives the traffic?

Before going there, let us see some of the considerations SASE solutions shall take care of. SASE needs to consider the following types of clients:

• Human users using browsers to access services
• Human users using non-browser applications to access services
• Non-browser applications that work with no human intervention to access services
• Non-browser applications with CA certificate pinning
• IoT devices accessing services

The implication is that SASE solutions can’t assume that there are always human users initiating the traffic sessions. There can be programmatic entities and devices initiating the traffic sessions. SASE is expected to serve both kinds of clients, and hence SASE solutions support multiple authentication methods.

SASE needs to consider the following user experience challenges:

• User experience where human users are shown no or fewer pop-up screens for taking user credentials
• User experience where human users are informed of why a particular access is denied
• Users using their own devices for accessing services
• Users using Employer managed devices to access services
• Uniform experience for users, whether they are working from home or the office

With those above requirements & implications, SASE solutions implement various authentication modes. Most of the authentication modes supported by SASE solutions are listed here.

• Reverse Proxy Authentication
• Forward Proxy Authentication
• Portal-based Authentication
• Tunnel Authentication
• Client Certificate Authentication
• API Key based Authentication

Once clients authenticate to SASE via the above, SASE shall have a way to associate the user-initiated traffic sessions with the right user. Two identification mapping approaches are used. They are:

• Token mapping: SASE solutions identify the user from Authentication/Identity/Bearer token in request headers of HTTP/HTTPS traffic sessions. Clients are given tokens as part of authentication and the same is presented by clients in the traffic sessions.
• Representative IP mapping: In this approach, the IP address is representing the user. SASE solutions use the source IP address of the traffic session to identify the user. When a user first authenticates with the SASE successfully, SASE records the user IP address for that user. Any traffic sessions, at a later time, coming from this IP address are then associated with the user.

Tokens are only valid for HTTP/HTTPS traffic sessions. Since tokens are present in every HTTP session either directly or indirectly via cookies, it is considered more secure than the ‘Representative IP.’ For non-HTTP/HTTPS traffic sessions, ‘Representative IP’ mapping is used by SASE solutions. Note that the ‘Representative IP’ mapping method has a few challenges as the IP address is used by all applications in the machine. That is, even though a browser user is authenticated to the SASE solution, not only the browser but also all other client applications running on the machine will have the same access. In the case of multiuser systems, all users of that system will get access even if one user successfully authenticates with the SASE solution. Even more dangerous is if the system used to authenticate to the SASE system is behind a NAT device. All users behind that NAT IP address will get access. Hence, it is particularly important to use the ‘Representative IP’ feature only when necessary and try restricting this mapping only to non-HTTP/HTTPS sessions.

Since the token (via proxy-authorization header or authorization header or via cookie) is part of each HTTP request, only the client application that is authenticated with the SASE solution can send the token. Other web-based client applications that require access are expected to authenticate themselves to the SASE solution to get access. Due to the security benefits, it is highly recommended to use the token mapping approach for all HTTP/HTTPS sessions.

User Authentication and Identification by various SASE components

Many SASE components that provide security for web-based applications/services tend to identify and associate users to traffic sessions via tokens in HTTP request headers, client certificates, or API keys.

The following sections provide a mapping of relevant and best authentication modes to various SASE components.

ZTNA

ZTNA, as discussed in this previous blog, is meant to protect the Enterprise applications from malicious and infected clients. ZTNA, by front-ending application services, provides the following features.

• TLS/SSL Security for non-TLS/SSL applications and for applications that don’t support strong cryptography algorithms
• RBAC / Least Privilege access support for applications that don’t support any RBAC and for applications that require second-level RBAC
• Privilege access management with one more level of MFA
• Load balancing of traffic across multiple application instances
• WAF and API level threat protection security to applications

ZTNA is increasingly becoming a necessity as it is taking the security responsibility away from the application services. The resulting benefits include an increase in the productivity of Enterprise application development, uniform security configuration across multiple application services, and lesser attack surface.

ZTNA is mainly meant for securing web-based applications. Application developers are not only creating new applications with web protocols but also existing applications are being webified to take advantage of innovations that are happening on web protocols. Even the traditional administration protocols such as SSH are being webified using projects such as Apache Guacamole. That said, there will always be non-web applications. A firewall as part of SASE provides access control and threat protection security for Enterprise instantiated non-web services. Please see the firewall section for further details.

How does ZTNA get access to the traffic?

ZTNA gets access to the traffic in two ways – via the DNS method and the transparent proxy method.

Administrators of Enterprise applications configure the authoritative domain servers to point to the ZTNA for the applications. That is, administrators configure DNS servers to respond with ZTNA IP addresses to DNS queries on applications’ FQDNs. In the transparent proxy method, ZTNA is expected to be in the line of traffic, or an entity in the line of traffic is expected to intercept the traffic and send the traffic to ZTNA. Application administrators also configure ZTNA with TLS/SSL Certificate/private key pairs on behalf of application services.

How does ZTNA authenticate users and map traffic sessions to users?

ZTNA supports reverse proxy authentication, client certificate, and API key authentication modes to authenticate various types of clients – Human users as well as programmatic entities. It works as follows:

• ZTNA terminates the TLS/SSL connection
• If the client certificate is negotiated, then it validates the client certificate. If it is valid, then it extracts the certificate subject name and SAN (Subject Alt Name). Those are identities of the client user. If any user group or role is provisioned, it extracts the group and role information from the provisioned database.
• If the client presents the API key, it refers to the internal database (provisioned) to extract the user identity. If any user group or role is provisioned, it extracts the group and role information from the provisioned database.
• If the HTTP request has an associated authentication/identity token, it means that the user was authenticated before. It also means that the user context (username, user group, and user role if any) is known to the ZTNA.
• If the token is invalid or if there is no token, it asks the user to identify and authenticate via OIDC. The OIDC broker of ZTNA may, in turn, use various authentication protocols to let the user authenticate with Enterprise authentication services. For privileged accounts, ZTNA performs its own MFA to ensure that the user is indeed a genuine user.
• If the user is authenticated successfully, the OIDC component of ZTNA sets up the identity token. It also notes down the user information (username, user group, if any, and user role, if any)
• ZTNA then establishes a connection to one of the application service instances.
• It performs user-based access control decisions per HTTP transaction.
• If ZTNA is configured for advanced threat protection, it also scans the traffic for any exploits, malware and for sensitive data leaks.

A User is presented with a screen to provide credentials only once until the identity token is expired. Because of the same-origin policy of the clients, they always present the right identity token in the HTTP transactions towards application services. If the identity token is valid, ZTNA would use that information to map the session to the right user.

SWG and CASB

The SWG component protects the users from visiting malware, phishing, and insecure sites. It also protects client applications from contacting C&C botnet sites upon infection. In addition, SWG provides a way to provide differentiated access to various sites based on the users’ role in the organization and the group the users belong to. SWG also records the traffic session metadata along with the user information that can help in various analytics and digital forensics. CASB component protects the Enterprise data maintained by SaaS providers by ensuring that only the right users access & modify the data using API-level access control for various SaaS applications. CASB, just like SWG, also records the API metadata with the user information for various analytics and digital forensics.

Both SWG and CASB components require inspection of HTTP/HTTPS traffic going from users to Internet sites. SWG and CASB terminate client connections, do SSL interception if allowed, and do deeper content inspection to detect and prevent malware and stop any sensitive data leaks.

How do SWG and CASB get access to the traffic?

SWG & CASB proxy get hold of traffic via two methods – proxy/PAC method and transparent method.

In the Proxy/PAC method, client machines/applications are either manually configured with proxy settings or client applications auto-configure via auto-discovery of proxies. Once the client applications know the proxies, client applications use HTTP CONNECT method to tunnel the data sessions, which would normally be HTTP & HTTPS transactions. HTTP CONNECT URI indicates the intended destination of the internal HTTP & HTTPS transactions. The proxy uses this URL to make the connection to the destination site. Proxies perform any access control and threat protection services before allowing the data to pass from clients and servers and vice versa.

In the transparent proxy method, clients don’t know about the proxies. It is the expectation that proxies are in the line of traffic to get hold of the traffic.

How does the SWG/CASB proxy authenticate users and map traffic sessions to users?

If proxy/PAC method is used to reach the SWG/CASB proxy, then proxies get a chance to authenticate users as part of HTTP CONNECT transaction. This is called “forward proxy authentication.” HTTP CONNECT based forward proxy authentication is described here very well.  Though this link describes the NTLM authentication, a similar flow is equally applicable for Kerberos authentication too. Since HTTP CONNECT precedes every HTTP/HTTPS traffic session, the user is known to the proxy at each session. One good thing about this method is that the majority of native client applications, in addition to browser applications, also honor proxy settings and can authenticate with the proxies, thereby covering most of the Internet Access use cases.

In the transparent proxy method, there is no HTTP CONNECT transaction. Hence, forward proxy authentication is not possible. Any user authentication needs to happen with regular HTTP authentication schemes, such as redirecting the HTTP request to SASE portal, which in turn use OIDC and SAML methods to authenticate users. This kind of authentication is called “Portal-based Authentication.”  Once the user successfully logs in, the portal can set the cookie, but this is not visible to the proxy when the user browses Internet sites due to the same-origin policy in browsers. Because of this challenge, once the user logs in successfully, the portal creates the mapping between the username and the source IP address of the user authentication session and informs the proxy of this mapping. The proxy at a later time uses this mapping to map the traffic sessions to the user. If there is no mapping available, then the proxy redirects the traffic session to the portal for login. This ‘mapping’ is called “Representative IP mapping.”  As described earlier, this mapping method shall be used carefully as this method might open access to unintended parties.

Transparent proxy methods depend on redirecting the incoming HTTP transactions. It means that it needs to get hold of clear traffic via SSL interception. There are cases where SSL/TLS interception is not allowed or not possible. As redirection is not possible in these cases, it is the expectation that the user is authenticated to SASE via other mechanisms, such as proactive authentication with the portal or via ‘Tunnel Authentication.’

Firewall and L3/L4 based functions

Firewall and associated NAT, routing, QoS functions work on packets at L3/L4 layers level. These functions need to be in systems that are in the line of traffic. More often, SASE systems with these functions are gateways to the traffic coming from sites and remote users.

Since firewall deals with all kinds of protocols beyond HTTP & HTTPS with respect to access control, reverse proxy and forward proxy, on-demand portal authentication mechanisms are not possible. There are two modes predominantly used to authenticate the users – Explicit portal authentication and Tunnel Authentication.

In the explicit portal authentication mode, users are expected to authenticate to the SASE portal by pointing the browser to the SASE portal. The SASE portal, along with OIDC, authenticates the users. In this case, too, SASE uses the ‘representative IP’ mapping method. The SASE portal sends the IP address vs. user mapping to the firewall upon successful user authentication. Firewall and L3/L4 functions use these mapping records to associate the traffic sessions with the users.

Tunnel authentication mode requires special software installed on the client devices. Clients make tunnel sessions with SASE proactively. Part of that tunnel is authenticated with the SASE. If IPSec based tunnels are used, Tunnel authentication is taken care of by the SASE/IKEv2 component. SASE/IKEv2 component advertises the user (Initiator ID) and virtual IP address mapping to the SASE security and networking services. Firewall and L3/L4 functions use the ‘Representative IP’ mapping method to map the traffic sessions to the user.

Even though those two authentication modes are explicitly mentioned here, IP address to user mapping can come from proxies too, when a user authenticates to proxies in ‘Reverse Proxy,’ ‘Forward Proxy’ modes.

One point to note here is that user authentication is expected to happen if user-specific rules are to be effective. If the user is not authenticated, policy match logic assumes that the user is unknown. Due to this, user-based policies at the firewall and L3/L4 level are considered opportunistic. To incentivize/remind the users to login proactively, SASE solutions tend to generate browser notifications to inform users to log into the SASE portal.

Unified SASE and Identity

Unified SASE was discussed here, and that post provided various advantages Enterprises get from “Unified SASE” offerings.

If the SASE is built from various discrete components, user authentication might happen multiple times, which is not a great user experience. With ‘Unified SASE,’ users are expected to be authenticated only once for the entire SASE. This is one additional benefit of ‘Unified SASE.’

Unified SASE offerings add user information to relevant log messages in a uniform & comprehensive way to a common observability platform. It helps in various analytics and anomaly detection by monitoring the user behavior across SDWAN and Security services.

Summary

Micro-segmentation approach is needed but extending micro-segmentation to categorize various users is not a scalable solution. SASE solutions are increasingly enabling identity-based policy definition and enforcement. SASE solutions do this by authenticating the users and then mapping traffic sessions to users. SASE solutions provide various ways for users to authenticate to SASE. This post described some of the methods. Aryaka started the journey of ‘identity aware SASE’.  Aryaka SWG solution supports the enforcement of user-specific policies. Learn more about Aryaka SWG solution here: https://www.aryaka.com/secure-web-gateway/

• CTO Insights blog

  The Aryaka CTO Insights blog series provides thought leadership for network, security, and SASE topics. For Aryaka product specifications refer to Aryaka Datasheets.