on Posted on Reading Time: 4 minutes
As one of the contributors to the leading work underway in MEF to define standardized SASE-managed services (MEF W117), I am using this opportunity to introduce some key concepts that are being developed as part of this very important project. This blog delves into the role of subject actors and target actors in SASE Sessions, as part of the SASE framework.
The SASE Session is a central construct in the SASE (Secure Access Service Edge) service framework, as part of this project. The concept of the SASE Session describes the temporal association of a “subject actor” with a “target actor,” during which the subject actor operates or acts on the target actor. SASE Sessions are, in effect, IP packets flowing between subject actor and target actor in the context of a SASE service. A SASE service session, or “session,” can only result from the successful initiation of an action by the subject on the target and has a time dimension.
SASE Session: The flow of IP packets between the Subject and the Target in the SASE Service. A session has a start and an end. The start of a session changes the state of the session. The end of the session also changes the state of the session. Each session is unique and cannot be duplicated. (As defined in MEF W117.)
SASE Sessions
A SASE Session has a start and an end, both of which change the session’s state. Every session ID is unique and cannot be duplicated.
Management of the SASE Session is the responsibility of the SASE service provider. Before creating a SASE Session, the service provider must ensure that the subject actor is allowed to operate on the requested target actor. The SASE Session must be created in accordance with the subscriber policies for that specific subject-target pairing, taking into account both security and performance requirements.
Once a SASE Session has started, the subject, target, and the traffic flowing between them as a result of the session, need to be monitored to prevent security vulnerabilities and attacks. SASE Sessions need to be terminated any time conditions in the subscriber policies are not met. In other words, SASE Sessions have lifecycles that must be orchestrated by the SASE service provider.
SASE Subjects & Targets
At their highest level, SASE services are therefore treated as services enabling subjects to operate on targets, according to policies set by the subscriber of the service and enforced by the SASE service provider. Subjects may be human users, devices, or applications located anywhere within or outside the direct control of the subscriber. Similarly, Targets may be devices, or applications and may be located anywhere in the cloud, within the control of the subscriber or the SASE service provider or outside their control.
The status of subjects is not binary (e.g., good or bad, legitimate or illegitimate), but depends on factors like ‘context’ and ‘situation’ and can vary with time or activity (e.g., an authenticated and authorized user who keeps on trying to use an application that is not authorized, at times or from locations that are not permitted, by a subscriber policy may incrementally lose their authorized status in general).
Considering Secondary Subject Actors
For the purposes of monitoring a given SASE Session to ensure that it meets the criteria of the subscriber’s policies, the project contributors may, in future, consider the concept of a secondary subject actor, purely associated with a given SASE Session. Such a lifecycle session can be established leveraging the same security posture and session. The introduction of the construct of a secondary subject actor allows the SASE service provider to add secure monitoring and management, and prepares for a future AI-based solution to actively mitigate quality, performance, and security that falls below the service levels defined in the SASE service.
The addition of the concept of the secondary subject actor would be a radically new approach to ensuring security for an active session as opposed to reactive methods typically seen in the current generation of intrusion prevention systems.
The following are just some of the constructs being defined in the evolving MEF work in the context described above:
- Actor
- Application Flow Specification
- Buyer
- Credentials
- Identity Management
- Lifecycle Service Orchestration
- Policy Criterion
- Policy Endpoint
- Service Attribute
- Subject
- Target
Creating standardized abstract definitions for SASE-managed services offers an excellent opportunity for industry leaders to join this MEF effort, thereby growing the market, reducing market fragmentation, and enabling different stakeholders to maximize innovation in their respective areas of strength.
Learn More
Learn more about MEF’s work in SASE.
Learn more about MEF W117 SASE Services Definition; our current SASE initiatives are available in the MEF 3.0 SASE Hub on the MEF Members’ Wiki.
All employees of active MEF-member companies are authorized to access MEF Members’ Wiki. Don’t have a login? Register. Not a member? Join MEF. Not sure? Contact Us.
