# ZSM Framework for Autonomous Security Service Level Agreement Life-Cycle Management in B5G Networks
## 3 Security Framework Overview
### Intent-Driven Security Model  
Automated systems require motivations that lead to decisions, ultimately flowing into actions. Intents provide a concrete specification of the desired goals to drive these decisions. The level of accuracy in intent definition can vary. On the one hand, a client with no knowledge of the underlying system only needs to specify the wanted system state. In contrast, a security manager must define specific actions to take in a precise and standardized format. In this context, intents simplify the security management of the underlying hardware and technologies by abstracting their complexity, providing a flexible and comprehensible approach. For our work, we define three distinct levels of intent specification, ranging from high-level abstraction to detailed configurations: SCLA, MSPL-OP, and final configuration (as illustrated in Figure 2). Figure 1: ZSM security framework architecture. The SSLA serves as the entry point to the evolved ZSM architecture as explained in [42] inspired by the work in [43]. The SSLA is a formal agreement between a service requester, such as an over-the-top (OTT) or other operator, and the provider. The SSLA is the first intent: it defines security and service level objectives (SSLOs), spanning from the QoS requirements (throughput, latency, resource usage, etc.) to the security requirements (confidentiality, privacy, authentication, specific attacks protection, etc.). SSLOs define the genuine system's status for a concrete service. The ZSM framework uses SSLOs to drive decisions toward their fulfillment. During this process, monitoring probes and analytic engines are deployed to predict and detect SSLA violations, and finally prevent or mitigate the threats. Therefore, the final step for an SSLA enforcement process is the appliance of specific actions to continuously maintain the system's status specified by the SSLOs. The SSLA enforcement process usually covers cross-domain coordination. Final actions cannot be taken directly; however, the SSLOs require proper refinement to map their objectives with a domain-related intent. In this regard, the refinement transforms the SSLA into an orchestration policy, named MSPL-OP (see Figure 3 and Figure 4 step 1). To bridge the gap between the SSLA and actionable deployments, the MSPL-OP serves as an intermediate abstraction. It establishes the means to achieve every SSLO but does not specify concrete actions. In fact, the refinement process maps SSLOs to security capabilities. Every MSPL contains one or more capabilities, while an MSPL-OP contains one or more MSPLs. The MSPL-OP model is specified in Figure 3. SSLOs are categorized to be covered by one or more capabilities. This is precisely what the refinement process entails: transforming SSLO categories into a set of defined security capabilities. For this work, the MSPL-OP model has been extended in several ways. Relevant to this section is the incorporation of 5_GSecuritySlice_, allowing the specification of a 5G slice. A 5G slice is composed of a set of intertwined 5G services with security capabilities associated with those services. The 5G slice also differs from the regular MSPL-OP, as it requires multi-domain coordination. Intertwined services and security must be deployed to cover every 5G domain. In summary, the MSPL-OP model has been extended to address the requirements of a 5G slice deployment. To deploy a 5G slice, this work also considers domain selection and customization. This means that once the MSPL-OP has been created, security capabilities and services must be assigned to their corresponding domains. These domains are where the respective components and services will be deployed. We address this challenge with a straightforward and logical approach. If only one solution is possible, the decision is straightforward. However, if multiple domains can implement the same capability, then _orchestration requirements_ come into play. Orchestration requirements define the driving factors for selecting one domain over another.