7
SASE Session
A SASE Session is the core function of any SASE solution. Connecting the target actor to the subject actor, regardless of the connection type, in a secure session, based on identity and context, is why SASE exists. The SASE session must be established correctly and any violations or gaps in the policy will prevent any new session from being established. Any violation of the policy, while a session is active, will result in the session being terminated. In the future, the life cycle session will police sessions in motion for active security, as well as heal session performance without terminating the session. At the time of writing, the Zero Trust Framework (ZTF) ensures no session is established if it doesn’t meet all the criteria for secure communications. The User Network Interface (UNI) provides a service inspection and monitoring point, as well as various services. The SASE Application Flow Specification serves as an enhancement for understanding behavior on a per-application basis.
In this chapter, we will cover SASE Session, UNI, Actors, Flow, and the SASE Lifecycle Session. This chapter will be your key to delivering continually secure SASE services.
In this chapter, we will cover the following topics:
- SASE Session – what is an effective session
- SASE UNI – what is a UNI and is it required
- SASE Actors – what are the SASE actors and what are their functions
- SASE Flow - what is the flow of secure session establishment
- SASE Lifecycle - what is the lifecycle functionality of SASE
SASE Session
According to the MEF Forum, “A SASE session, or session, is the ephemeral flow of IP packets between two actors.”
The SASE session starts when one actor attempts to communicate across the network with another actor. Before establishing an active session, the authentication process must be completed. No data plane communications will occur without valid authentication to create a secure session.
The SASE Managed Service Provider (MSP) is responsible for managing the overall service to ensure no communications take place without all the security requirements being satisfied. When a secure session is established, the mission also includes quality monitoring to ensure all the communications meet the Service-Level Agreements (SLAs) that have been contracted for the subscriber.
In the process of building a session, the following steps occur:
- The session receives a unique session ID
- The session ID must be unique within the service
- The SASE policy is applied to the session ID
- Every actor in the session gets a unique ID
- The actor ID gets associated with a provider ID
- A session specification is developed to classify the session
- Actor lists are created and maintained
- Tables are built and maintained for session state tracking
Each step is necessary to break down the SASE session into smaller pieces that can be independently managed, validated, tracked, and leveraged for comprehensive service performance.
The SASE service must be secure from a ZTF perspective, must provide consistent performance, and must provide consistent quality.
Overall, the SASE service ensures that all the minor components are being independently managed correctly at their lowest level, which is compounded in the SASE session. This is further compounded into a SASE service that can then be combined with other SASE services for an overall SASE solution that meets the needs of the organization.
In the past, all the functions in a single, prescriptive WAN solution would have been scrutinized to try and achieve the perfect solution. Unfortunately, the more prescriptive a service implementation became, the more the configuration had to be adjusted to match the rate of changing conditions within the environment where the solution had been deployed. The solution could not evolve at the pace of change due to financial and human limitations. Moving to a disaggregated control plane model, we can leverage a policy to effect change at the speed of the operating environment’s change. This policy defines standards of expectation, and the control plane interacts with the environment to effect changes that are within the expectation of the policy. For this reason, the policy should be written to provide as much control to the controller as possible and only prescript where necessary.
Successful security must be Zero Trust, but a successful network function is least prescriptive in a controller-based, software-defined solution set.
“A SASE Edge is a set of network functions (physical or virtual) that are located between the SASE UNI(s) and the underlay connectivity service UNI(s).”
– The MEF Forum
In summary, the SASE session is the heart of the SASE service. By breaking it down into its smallest parts, each part may act independently and the whole solution, when aggregated, becomes a living, breathing, effective solution.
In the next section, we will explain SASE UNIs.
SASE UNI
The User Network Interface (UNI) is where the service provider’s network touches the customer’s network. This is typically on the provider’s router. With the SASE UNI, the touchpoint is per service and is generally a logical construct, though it might be a physical interface since the SASE UNI lies on another service, such as SD-WAN, and the underlay UNI may be provided via MPLS or another service for the physical touchpoint.
The underlay is the actual circuit from the service provider, such as MPLS, Switched Ethernet, LTE, 5G, or other circuit types. The UNI for the underlay is the handoff point from the Provider Edge (PE) to the Customer Edge (CE). This leverages the Permanent Virtual Connection (PVC), as established for the subscriber organization.
The SASE UNI is a logical point of demarcation from the overlay service, such as SD-WAN, when connecting to the customer’s SASE Edge, which may be physical or virtual. The SASE UNI provides much the same value as the underlay UNI. Both serve as a monitoring point for SLA management by validating contracted service attributes such as uptime, errored seconds, quality, throughput, and other metrics. The SASE UNI generally uses multiple, diverse underlay platforms.
In summary, the UNI is the handoff point between the provider and the subscriber.
In the next section, we will discuss the actors in the SASE session.
SASE Actors
As per the MEF Forum, “An actor is a user, device, or application that either wants to access another actor or allow themselves to be accessible.”
Actors generally come in pairs in this generation of SASE services. In every SASE session, there is a subject actor and a target actor. The subject actor is at the “A” end of the relationship and does something based on the target actor at the “Z” end.
Regardless of their role, all actors are denied access using the ZTF until they are fully authenticated by leveraging a Multi-Factor Authentication (MFA) Identity and Access Management (IAM) system. IAM leverages factors such as risk, reputation, role, privilege, capability, and physical or virtual attributes such as a serial number or Media Access Control (MAC) address.
Once the actors have been authenticated, the subject actor and target actor for each SASE session are tracked, managed, monitored, and controlled so that they can be applied to that actor’s SASE policy.
Identity is a known, fixed, constant attribute for a device, service, or user. The context in which a specific identity is accessing the service may be used as a condition for permitting access. The context of the authentication request may allow access. In the ZTF model for security, all access is denied by default and many conditions must be met to establish each new SASE session.
The following are some examples of context:
- Time of day/session start time
- Risk/trust assessment of the access device
- Presence (location, historical patterns, and so on)
- Authentication strength (weak, strong)
- Level of assurance (NIST levels, X.509 certificates)
- Risk assessment (pattern analysis)
- Federation (partner attributes)
- Device characteristics (fingerprint, device health, device protection, trusted data, and so on)
- Assertions from trusted partners (SAML tokens and more)
- Single Sign-On (SSO) sessions (session timeouts)
- Location, as defined by the SASE service, so that it matches the zones and policy (this applies to both target and subject actors)
In summary, SASE sessions begin and end with an actor in a role that may change per session. Each actor must be validated to retain access on a per-session basis; otherwise, the next session is never established. This is a major departure from earlier network communication systems. This departure is a ZTF foundational differentiator that is necessary for secure communications. Context acts as an added condition that allows access.
In the next section, we will follow the flow of secure session establishment.
SASE Flow
A SASE session flow is a decision-making matrix that allows packets to flow across the secure network connection in the SASE session. If an answer isn’t provided for any of the interrogation process decisions, the packet is blocked and the session is ended. When the session is terminated, the authentication process is required for the next session, which ensures security measures are not violated.
MEF 70.1 defines an Application Flow Specification (AFS) as “A named set of application flow criteria.” The AFS is a key attribute for the SASE service to use in determining specific application behaviors. Via pre-identification, the SASE service creates an understanding of any predicted behavior that may be analyzed in flight to understand when non-predicted behavior occurs. Non-standard or non-predicted behavior triggers a security response to terminate bad actor communications. By terminating the session, good actor communication may reestablish communications through a new session, while bad actor communication will fail the reauthentication process.
Each SASE session may have multiple AFSs included in the session, but there must be at least one to establish the session. During the setup of the session, the AFS is compared to IP addressing as part of the validation process. When you’re using SASE and SD-WAN, both the AFS and IP will be compared from both services to only establish the session when the common attributes are matched in both service policies. This is part of the least privilege model and supports both security and performance/quality goals.
To summarize, the flow of a SASE session is tied to the SASE session flow, which confirms communication pre-flight and monitors it for the intended behavior while in flight.
In the next section, we’ll describe the life cycle functionality of SASE.
SASE Lifecycle
The SASE life cycle idea is one that Neil Danilowicz, while working on the MEF W117 project, came up with to allow AI-based security to be inserted into an active SASE session.
Once the SASE session is in place, the subject actor, the target actor, and the traffic flowing between them in the SASE session need to be monitored. This monitoring needs to be active to prevent security vulnerabilities and attacks.
SASE sessions are terminated as soon as the conditions in the subscriber policies are not being met. In other words, SASE sessions have life cycles that are orchestrated by the SASE service provider.
By creating a third wheel mechanism, a life cycle session can be established by leveraging the same security posture and session. This allows you to insert secure monitoring and management and prepares you for a future AI-based solution to actively mitigate quality, performance, and security that falls below the service levels defined in the SASE service.
In conclusion, the SASE life cycle session is a future-looking concept that will allow active, AI-based security to interact with an active session and dynamically fight cybersecurity threats in real time.
Summary
In this chapter, we looked at SASE sessions, alongside UNIs, actors, the session flow, and the SASE life cycle. The SASE Session is the lifeblood of the SASE Service; without it, no communications can take place in SASE. Many of the service components in the SASE Service exist to ensure no session is established without every individual component matching the requirements. In other words, each service component serves as a key to unlock another lock that prevents the service from working in a less than secure fashion. Once all the locks have been unlocked, the SASE Service functions as intended with great precision.
In the next chapter, Chapter 8, SASE Policy, we will explain the policy components of the SASE Service while covering SASE Policy, SASE Quality, SASE Dynamic, SASE Trust, and SASE Effective. The Policy is the key to all the factors in terms of security, quality, performance, resilience, path selection, and almost every control plane decision.