Methodology and platform for federated security orchestration

Abstract

Title: Method and Platform for Federated Security Orchestration. The invention relates to a distributed, federated, and dynamic multi-domain security orchestration solution enabling the automatic translation of an effective Security Level Agreement (SSLA) in the case of multi-domain interoperability, based in particular on the automatic creation of a federation of selected domains via the federation controllers of the selected domains and the dynamic selection of a master domain for said federation. Figure for the abstract: Figure 3

Description

Title of the invention: Method and platform for federated security orchestration technical field

[0001] The invention lies in the application of a set of security rules (also called a security policy), derived from, or parameterized by, SSLAs (Security Service Level Agreements), which are part of a service level agreement or SLA (Service Level Agreements) when implementing end-to-end services composed of computer applications and / or networks distributed across several different operator domains and exposing different administration and orchestration interfaces, situations encountered in particular in 5G / 6G mobile telecommunications networks. Previous technique

[0002] In this document, 'domain' means a domain as defined by the ETSI MANO NFV group: "administrative domain: a set of systems and networks operated by a single organization or administrative authority; infrastructure domain: an administrative domain that provides virtualized infrastructure resources such as compute, networking, and storage, or a composition of these resources via service abstraction to another administrative domain, and is responsible for the management and orchestration of these resources [...] infrastructure network domain: a domain within NFVI that includes all networks that interconnect the compute / storage infrastructure." These terms correspond to what is described in the document "GR NFV 003 - Vl.5.1 - Network Functions Virtualisation (NFV); Terminology for Main Concepts in NFV (etsi.org)."

[0003] Network platforms and cloud providers belong to different administrative domains and offer functions from different vendors. In this context, it is becoming increasingly difficult—and generally impossible—for previous orchestration techniques to meet the security needs of the various stakeholders and to guarantee the required level of security throughout the lifecycle of a slice in networks that employ network slicing. A slice is a physical network segmentation into several logical networks operating independently with their own network performance and quality of service to meet the specific needs of a customer or business.

[0004] It is difficult to consistently apply an end-to-end security policy or SLA for a service provided to the end customer that relies on several different domains / operators / interfaces.

[0005] The difficulties encountered include the following:

[0006] - horizontal difficulty: information exchange between orchestrators: technologies different, different APIs, different communication protocols and different data formats;

[0007] - vertical difficulty: the descent of the expression of the need for security in terms of SLA from a service management layer to each security domain in the form of security policies and the derivation of this policy on cloud platforms in the form of security controls;

[0008] - multi-domain difficulty: applying and maintaining a security requirement expressed by SLAs on devices, cloud platforms with different technologies and different network providers: see multi-domain 5G definition by the ETSI NFV MANO working group relating to the management and orchestration of network function virtualization (NFV acronym for "Network Function Virtualization");

[0009] - difficulties related to centralization: the prior technique uses an orchestrator centralized global that interacts with each domain and orchestrates the end-to-end service alone, which poses a problem of service resilience, in case of loss of connection between the central orchestrator and one of the orchestrated domains, and / or in case of failure of one of the domains.

[0010] - end-to-end difficulty: applying and maintaining an expressed security requirement by SLAs across an entire system involving different orchestration zones through a chaining of security functions (e.g., SSLA propagated across several security domains);

[0011] - Vertical orchestration difficulty: applying and maintaining a security requirement expressed by SLAs across numerous hierarchical orchestrators on a single domain. Summary of the invention

[0012] To this end, according to a first aspect, the present invention describes a multi-domain security orchestration method by an orchestration system in a service implementation platform comprising a plurality of computing, network or storage resource domains for the implementation of services;

[0013] each domain being associated with: - a security-oriented service orchestrator, known as SASO, which is autonomous and performs service orchestration and security orchestration in said domain. - a catalogue of functions, including security functions, that can be deployed in the field, - a federation controller, - a security policy manager,

[0014] according to which each service to be orchestrated is associated with a digital contractual security level agreement, called SSLA, and with a topology descriptor of the orchestration of said service, called SOD, the process includes the following steps implemented by a service management module of the orchestration system:

[0015] depending on the SSLA and the SOD associated with the service, selection of some of the domains for the implementation of the service selectively from said selected domains, triggering the automatic creation of a federation of the selected domains via the federation controllers of the selected domains, and dynamic selection, from among the domains of the federation, of a master domain of said federation;

[0016] provision of the SOD and SSLA to the master domain security policy manager;

[0017] according to which the master domain security policy manager then automatically creates, based on said SOD and SSLA, a security-enhanced service orchestration topology descriptor, named SASOD, describing the end-to-end topology of the service as it is applied to the federation domains, including the SSLA associated with the service, and transmits it to the SASO of the federation master domain, which in turn transmits the SASOD to the SASO of each other federation domain created for said service;

[0018] in each domain: - the SASO of each domain of the federation enriches said SASOD, according to the catalog of functions, including security, of said domain, in a description of service orchestration, specific to the domain and respecting the SSLA associated with the service; - the orchestration of the service in accordance with the SSLA on the domain is carried out according to said orchestration implementation.

[0019] The invention thus proposes a distributed, federated and dynamic multi-domain security orchestration solution enabling the application (by automatic translation) of an effective contractual security level agreement (called SSLA) in the case of multi-domain interoperability.

[0020] In embodiments, such a method will further comprise at least one of the following features: - in at least one of the federation's domains, at least part of said orchestration implementation is distributed by the SASO of said domain to a domain orchestrator separate from the SASO and dedicated to one aspect among {network, applications, platform}; the deployment of the service in accordance with the SSLA is carried out according to said orchestration implementation by at least said domain orchestrator separate from the SASO; - the process implements at least one of the following provisions:

[0021] in at least one of the federation's domains, the SASO is duplicated on a plurality of nodes hosting the resources, only one of said SASOs being active at a time in said domain, another of said SASOs being activated in said domain in case of failure of the SASO previously active;

[0022] in at least one of the federation domains in which at least part of said orchestration implementation is distributed by the SASO of said domain to an orchestrator of the domain distinct from the SASO, said orchestrator of the domain distinct from the SASO is duplicated on a plurality of nodes hosting the resources, only one of said orchestrators being active at a time in said domain, another of said orchestrators being activated in said domain in the event of failure of the orchestrator previously active;

[0023] in at least one of the federation domains, the federation controller is duplicated on a plurality of nodes hosting the resources, only one of said federation controllers being active at a time in said domain, another of said federation controller(s) being activated in said domain in case of failure of the federation controller previously active; - said other element of a given type among SASO, orchestrator of the domain distinct from SASO and federation controller, which is to be activated, following a failure of the element of the same type active until then within the same domain, is identified, among the elements of the same type, by a dynamic and distributed election mechanism; - the process implements at least one of the following provisions:

[0024] following the detection that a domain of the federation is failing, selection of another domain in the plurality of domains to replace, in the federation, the failing domain, for the implementation of the service selectively from said selected domains;

[0025] following the detection that the federation's master domain is failing, implementation of a dynamic and distributed election mechanism for a new master domain from among the other federation domains; - The compliance of the security level of the service's operation with the SSLA on each domain is controlled by the SASO of said domain, and in the event of detection of non-compliance, the SASO of said domain notifies the SASO of the master domain, which triggers, where applicable, at least one of the following measures:

[0026] modification of the orchestration of said SASOD implementation;

[0027] SASOD implementation modification.

[0028] According to another aspect, the invention describes an orchestration system for a service implementation platform comprising a plurality of computing, network, or storage resource domains for service implementation, said orchestration system comprising, associated with each domain: - a security-oriented service orchestrator, known as SASO, which is autonomous and performs service orchestration and security orchestration in said domain. - a catalogue of functions, including security functions, that can be deployed in the field, - a federation controller, - a security policy manager,

[0029] in which each service to be orchestrated is associated with a digital security level agreement, referred to as an SSLA, and with a topology descriptor of the orchestration of said service, referred to as an SOD,

[0030] wherein a service management module of the orchestration system is adapted to, depending on the SSLA and SOD associated with the service, select some of the domains for the implementation of the service selectively from said selected domains, to trigger the automatic creation of a federation of the selected domains via the federation controllers of the selected domains, and to dynamically select, from among the domains of the federation, a master domain of said federation;

[0031] in which the service management module of the orchestration system is adapted to provide the SOD and the SSLA to the security policy manager of the master domain;

[0032] wherein the master domain security policy manager is adapted to then automatically create, based on said SOD and SSLA, a security-augmented service orchestration topology descriptor, named SASOD, describing the end-to-end topology of the service as it is applied to the federation domains, including the SSLA associated with the service, and to transmit it to the SASO of the federation master domain, which is adapted to then in turn transmit the SASOD to the SASO of each other federation domain created for said service;

[0033] in which for each each domain: - the SASO of each domain of the federation is adapted to enrich said SASOD, according to the catalog of functions, including security, of said domain, into a service orchestration implementation, specific to the domain and respecting the SSLA associated with the service;

[0034] and in which the orchestration of the service in accordance with the SSLA on the domain is performed according to said orchestration implementation.

[0035] In some embodiments, such an orchestration system will further include at least one of the following features: - in at least one of the federation's domains, at least part of said orchestration implementation is distributed by the SASO of said domain to a domain orchestrator distinct from the SASO and dedicated to one aspect among {network, applications, platform];

[0036] wherein the deployment of the service in accordance with the SSLA is carried out based on said orchestration implementation by at least said orchestrator of the SASO separate domain; - in at least one of the federation's domains, the SASO is duplicated on a plurality of nodes hosting the resources, only one of said SASOs being active at a time in said domain, another of said SASOs being activated in said domain in case of failure of the SASO previously active; - in at least one of the federation's domains in which at least part of said orchestration implementation is distributed by the SASO of said domain to an orchestrator of the domain distinct from the SASO, said orchestrator of the domain distinct from the SASO is duplicated on a plurality of nodes hosting the resources, only one of said orchestrators being active at a time in said domain, another of said orchestrators being activated in said domain in case of failure of the orchestrator previously active; - in at least one of the federation domains, the federation controller is duplicated on a plurality of nodes hosting the resources, only one of said federation controllers being active at a time in said domain, another of said federation controller(s) being activated in said domain in case of failure of the federation controller previously active; - said other element of a given type among SASO, orchestrator of the domain distinct from SASO and federation controller, which is to be activated, following a failure of the element of the same type active until then within the same domain, is identified, among the elements of the same type, by a dynamic and distributed election mechanism. Brief description of the drawings

[0037] The invention will be better understood and other features, details and advantages will become clearer from the following description, given by way of non-limiting reason, and from the accompanying figures, given by way of example.

[0038] [Fig-1] The [Fig.1] is an illustration of the SOMC and SDC clusters in a domain;

[0039] [Fig.2] The [Fig.2] is a representation of the control plan of a SOMC;

[0040] [Fig. 3] Figure 3 represents the architecture of an orchestration solution for the safety in an embodiment of the invention;

[0041] [Fig.4] The [Fig.4] represents the steps of a security orchestration process in one embodiment of the invention.

[0042] Identical references may be used in different figures when they refer to identical or comparable elements. Description of the implementation methods

[0043] Fig. 3 represents the architecture 10 of a multi-domain security orchestration solution in one embodiment of the invention.

[0044] The architecture 10 comprises three layers that extend over several domains: an end-to-end service management layer 11, an orchestration layer 12, and a resource platform layer 14.

[0045] Platform layer 14 represents the target layer of the orchestration, on which the services will be deployed end-to-end; it offers heterogeneous physical and / or virtualized resources such as computing, network (telecommunications), or storage resources hosted by software and / or hardware nodes. These resources and associated nodes are provided by various operators of different types in different domains. In the example shown, four domains are considered as examples in [Fig. 3]:

[0046] - a domain providing an open radio access network platform 14_1 that can be managed by several operators (“OPE RAN 1, .. .,nR”),

[0047] - a domain providing a "multi-access edge computing" platform 14_2 which can be managed by several operators (OPE MEC 1, ..., nM"),

[0048] - a domain providing a core / transport network 14_3 that can be managed by several core network (CN) or transport network (TN) operators (“OPE CN / TN 1,2,..., nT,” and

[0049] - a domain providing a 14_4 cloud that can be managed by several operators ( OPE Cloud 1,..., nc") ...

[0050] One (or more) resources of a node on which part of a service is deployed following orchestration is thus used during the implementation of the service.

[0051] In one embodiment, these domains use virtual network functions (VNFs) and / or cloud network functions (CNFs).

[0052] The different domains benefit from collaborative knowledge sharing via an exchange module 15.

[0053] The orchestration layer 12 includes, for each domain, a security-oriented service orchestrator 122, named SASO 122 (SASO for "Security-Augmented Service Orchestrator"), which is autonomous from the other domains. The SASO 122 secure service orchestrator performs two functions: a service orchestration function and a security orchestration function. These two functions can, in practice, depending on the embodiment, be implemented in the same orchestrator or in two interacting orchestrators.

[0054] The purpose of orchestration is to automate complex tasks and workflows (sequences of operations) to coordinate and manage the components necessary for the operation of an application or network service. This may, for example, involve deploying, configuring, and chaining software components necessary for the service and allocating them platform resources implemented by these components, as well as coordinating resources from multiple domains configured to perform tasks necessary for service delivery in accordance with the SLA and SSLA associated with said service.

[0055] The security orchestration functionality consists of orchestrating end-to-end (i.e., across all domains involved in implementing the service) the software and hardware security components required by a service in accordance with an SSLA throughout the service lifecycle. This involves dynamically deploying (and optionally removing and / or redeploying), configuring, and chaining security functions together and to the service's business components, which can in turn be dynamically deployed by SASO 122 or pre-deployed in the platform layer 14 (e.g., hardware security modules, key management systems, etc.).

[0056] In each domain, the SASO 122 has a catalog of 65 domain-authorized security and business functions and applications that can be deployed in the domain (compatible with the domain infrastructure), so that the SASO can dynamically select and deploy those that meet the security policies of both the domain and a service to be orchestrated as described below.

[0057] In addition to a SASO 122, several types of dedicated orchestrators can be supported by each domain. For example, the orchestration layer 12 further includes, for at least some of the domains, a network orchestrator 123 and a Application orchestrator 124. Each type of domain orchestrator is also autonomous from that of other domains.

[0058] A network orchestrator 123 is adapted to orchestrate the telecommunications network functions of the domain, and an application orchestrator 124 is adapted to orchestrate the application functions of the domain. All of these security, network, and application functions of the domain are provided by domain resources in resource layer 14.

[0059] For each domain, the orchestration layer 12 further includes a federation controller 120, enabling the domain's SASO to operate in a federation, and further includes a security policy manager 121 (Sec_Pol Mng 121) in order to orchestrate security policies (the latter can alternatively be placed in the service management layer 11; this depends on the use case, for example, the computing capacity in the domains when the nodes are on an edge).

[0060] The security policy manager 121 is adapted to provide service orchestration descriptors enriched with security policies taking into account the SSLAs (“Security Service Level Agreement”) associated respectively with the services.

[0061] SASO 122 also incorporates a security orchestration lifecycle management functionality, which plays an important role in the resilience of the solution.

[0062] In a domain, a SASO 122 is, in the considered embodiment, replicated across several nodes of the same domain. The same applies to other types of orchestrators (for example 123, 124), federation controllers 120, and security policy managers 121.

[0063] Only one orchestrator of a given type is active at a time in a domain. Another orchestrator of the same type in the same domain can be activated in the event of a failure of this orchestrator (see Intra-Domain Resilience section). Similarly, only one federation controller and one security policy manager are active at a time in a domain.

[0064] The set of elements of the orchestration layer 12 described above and dedicated to domain i, i = 1 to 4 here, is referenced 12D0Mi.

[0065] Between the orchestration layer 12 and the resource layer 14, a set of application programming interfaces 13, called APIs 13, is arranged: these APIs 13 are adapted to perform service configuration, controller configuration, and security function configuration. Among these are virtual or "cloud native" functions (VNF / CNF) that will apply processing to network packets, messages, and even application data exchanged in the data plane (user / data plane), either between different service components or between Service consumers / users and the service components exposed to those consumers. Certain functions in particular, known as security functions – Virtual Security Functions (VSFs) and Physical Security Functions (PSFs) in the ETSI NFV-SEC standards – are configured by the SASO according to security policies (and therefore indirectly the SSLAs). They are declared in a format compatible with the APIs of lower-level orchestrators such as network, application, and / or cloud-native orchestrators so that the VSFs and PSFs can be deployed by these orchestrators.

[0066] The service management layer 11 (also called the service management layer and indicated in [Fig. 3] as "MNGT Service" 11) is responsible for managing end-to-end services to meet the functional and non-functional needs of the entities providing the orchestrated services. These entities belong to different sectors of economic life, each called a "vertical" (see [Fig. 3]: "vertical 1", ..., "vertical n"), and are extremely diverse: transportation, media, energy, industry of the future, augmented reality, or defense. The service management layer 11 includes the following software components to ensure dynamic security orchestration in each service according to customer requirements: - a service orchestration descriptor manager, (“Orch Desc Mng”) adapted to create service orchestration descriptors (SODs) - and manage the lifecycle of these SODs: an SOD describes the topology of a service to be orchestrated in terms of network topology, nodes, software components, relationships between them and actions to be carried out end to end to orchestrate this topology; this manager also makes it possible to create an archive deployable at the SASO level, that is to say which includes not only the SOD but also all the files used or referenced by the SOD (imported definition files, scripts, VNF / CNF images, etc.) which would not otherwise be accessible by the SASO; - a 112 cross-domain federation manager adapted to create a federation (associated with a service) between the domains involved to make the service end-to-end; - a 110 SSLA (Security Service Level Agreement) manager adapted to manage the lifecycle of security SLA descriptors for the various end-to-end services; - a set of additional managers, here 113, 114, 115... resources necessary for security orchestration and establishing trust between security domains. This could be a cryptographic key management infrastructure (CKI) to distribute keys encryption from a certification authority (Root_CA 113), or from a Security Information and Event Management (SIEM 115) to collect and analyze federation information logs, or finally an Incident Response Management (IRM 114) which defines remediation strategies on a federation, in case of unforeseen security events or in case of violations of the security policies in place.

[0067] Service orchestration description formalism

[0068] The end-to-end service orchestration descriptors (SODs), considered in one embodiment of the invention, are formalized according to standard orchestration descriptor formalisms such as TOSCA (TOSCA, Committee Specification Draft 07 (2024)), thus representing TOSCAs.

[0069] The topology descriptor of an SOD service will be enriched into a SASOD as described below according to the invention by security policies that take into account the SSLAs by the security policy manager.

[0070] The SASOD can be specified according to a formalism which is based on an extension of a standard orchestration descriptor such as TOSCA.

[0071] We describe below an example of implementation of this extension of an SOD descriptor to a SASOD by showing how SSLAs are derived in this kind of descriptor in order to orchestrate security in an end-to-end service.

[0072] A TOSCA SOD must be extended by new TOSCA Node Types - corresponding to the different types of PEPs (Policy Enforcement Points or security enablers) and Supporting Security Services - and new TOSCA policies that correspond to the security controls specified in the SSLA.

[0073] In practice, for each type of security control requirement in the SSLA, a security policy must be defined (e.g., data access policy, secrets management policy, etc.). For this purpose, a new TOSCA policy type is defined (TOSCA Policy Type).

[0074] For each possible type of security policy, it is necessary to model the different types of nodes (TOSCA node type) that will need to be deployed, i.e. added to the topology, to apply this policy: - Protection PEPs (component that concretely applies the protection measures in accordance with the security policy): Protection PEPs apply various data protection mechanisms required by the data access policy in transit: user authentication, authentication and authorization of traffic, encryption / decryption of traffic, digital signature (and validation), filtering, content validation; - Detection PEPs: detection sensors have one of these two roles: a. Detection / monitoring role (Monitoring PEP) of SLOs: apply a security monitoring policy explicitly defined in the SSLA SLOs, e.g. monitor the access logs of a Protection PEP for the purpose of collecting data access metrics or for alerting purposes (detect too many denied access attempts, or too many authentication failures on a given account, when the monitoring policy defines a threshold above which the account must be temporarily locked, for example); b. role of compliance verifier (of the security policy): monitor the integrity of the protection PEPs to ensure compliance with the security policy (detect potential policy violations by unauthorized falsification); - security services supporting PEPs (PKI, IAM, Directory, PDP, Secrets Management Service, SIEM), and generally any security service with which PEPs will interact.

[0075] These new node type definitions are defined in TOSCA models which are separate from the final orchestration descriptors, to be reused in different final orchestration descriptors in the domains.

[0076] Some examples of policy types extracted from an SSLA: - Network layer (L3) communication security: - IPsec - Wireguard - Transport layer (L4) communication security: TLS DTLS - Authorization (RBAC, ABAC, etc.)

[0077] For example, an IPsec policy for protecting data in transit between two site-to-site VPN domains might look like the following YAML:

[0078] # Site-to-site VPN policy used for inter-domain network communication

[0079] interdomain-vpn-policy:

[0080] type: thales.tosca.policy.IPSec.SiteToSiteVPN

[0081] properties:

[0082] credential:

[0083] # Mutual authentication with pre-shared secret key (PSK)

[0084] token_type: PSK_BASE64

[0085] # Value of the PSK shared between IPSec gateways

[0086] key: mv7K9r8k68KfJBMBxQvPh / SVN2u01GJ / VriljDPyjLY=

[0087] # Domain name (FQDN registered in DNS) of the gateway belonging to remote domain, with which the connection must be established

[0088] remote_gateway: gwl.foo.com

[0089] # IKE (Internet Key Exchange) settings

[0090] # For each IKE parameter below, it is assumed that IKE v2 is systematically used, in accordance with best practices

[0091] ike_port: 555

[0092] ike_cipher_suites: [aes256gcml6-sha384-ecp384]

[0093] # ESP (Encapsulating Security Payload) Algorithm Suite

[0094] esp_cipher_suites: [aes256]

[0095] targets: # The TOSCA node (element of the topology) to which the policy applies - interdomain_net

[0096] The final SASOD generated by the SASO of a domain represents a descriptor that includes (illustration using TOSCA): - a node template for each type of security service node defined in the SASOD model and to which it has associated a concrete security service; - policy models based on the policy types defined in the SASOD model; - a specification of node models or groups to which security policies are associated, for example, if the "token_type" property has the value "PSK_BASE64": • Add a “Node template” of type (Node Type) for the protection PEP of domain 1 that implements an IPsec VPN gateway function, for example an IPsec gateway as a node of Domain 1, having a configuration corresponding to the previous interdomain-vpn-policy template, in which certain properties are automatically generated by the SASO, such as: the “key” property of the Base64-encoded PSK (Pre-Shared Key), which is a randomly generated AES key, the public IP address - or domain name - X of this gateway (taken from the group of available public addresses of domain 1), and an IP address - or domain name - Y (and possibly a non-standard port for the remote gateway) taken from the group of available public addresses of domain 2; • Add a "Node template" - functionally equivalent - as a node of domain 2, knowing that this domain 2 may not support / offer the same IPsec implementation as domain 1 but a different implementation, for example Stormshield SNS, having similar configuration properties, the same PSK and a public address (exposed to the outside) identical to address Y above, and the remote gateway address ("remote_gateway") identical to address X above; • Add a "Node template" for the Key Management Service (KMS) or more generally for Secrets Management, which will manage the update of the PSK(s); • Add the “Node Templates” for detection PEPs (monitoring SLOs) associated with protection PEPs (policy / SSLA compliance); • The TOSCA of the relationships between protection PEPs, the resources protected by them, and the security services on the one hand; between detection PEPs and the monitored resources including protection PEPs on the other hand.

[0097] SASOD is subsequently distributed and used by the different types of orchestrators of the domains of the federation linked to the service, and can be translated into other formalisms depending on the platforms orchestrated specifically in each domain and by each type of orchestrator (e.g. TOSCA to Terraform topologies, TOSCA to Kubernetes manifests, etc.).

[0098] Formalism for describing SSLAs managed by an SSLA manager

[0099] In order to automate security orchestration (for a 6G service for example), it is considered, in an embodiment of the invention, that a machine-interpretable format is adopted for SSLAs according to the SPECS model (cf. V. Casola, AD Benedictis, M. Rak and U. Villano, "SLA-Based Secure Cloud Application Development: The SPECS Framework," 2015 17th International Symposium on Symbolic and Numeric Algorithms for Scientific Computing (SYNASC), Timisoara, 2015, pp. 337-344, doi: 10.1109 / SYNASC.2015.59).

[0100] The SSLA's role is to define the level of service quality in terms of security in a contractual manner between a customer and the end-to-end service provider or the security provider whose role is to guarantee the security of the end-to-end service throughout the entire service lifecycle.

[0101] An SSLA specifies more specifically the following elements: - security capabilities required in a service to be orchestrated, a capability being defined as a set of security controls that come from one or more repositories such as NIST SP 800-53, Cloud Security Alliance's CCM, ISO 27005 or an internal enterprise repository; - a specification of metrics related to each security control, such as the name and definition of the metric, its measurement scale and the expression used to calculate its value; - a specification of Security Service Level Objectives (SSLO) defining the level of metrics required for each security controller.

[0102] An example of an SSLA for a 5G "slice" service for connected objects could specify required security controls based on standards such as NIST SP 800-53 or the Cloud Security Alliance CCM:

[0103] - encryption of data in transit

[0104] - authentication and authorization

[0105] The security metrics associated with these controls may be respectively: - the level of Confidentiality & Integrity (TLS or IPsec)

[0106] 1 (TLS 1.2 & 1.3), 2 (TLS 1.2 & 1.3 with PFS only), 3 (TLS 1.3 only), 4 (TLS 1.3 without AES_128) - the level of Authentication (Assurance) (see NIST SP):

[0107] 1 (none), 2 (PSK), 3 (PKI certificates).

[0108] The SSLOs associated with them are respectively (for example)

[0109] - Confidentiality & Integrity Level >= 2

[0110] - Authentication Level >= 3

[0111] A multi-domain orchestration method 200 for the security of a service is now described, in one embodiment, with reference to Figures 3 and 4.

[0112] For each service to be orchestrated, in step 201, the cross-domain federation manager 112 receives as input the service orchestration descriptor, the SLA and SSLA associated with the service, provided by managers 110 and 111, and creates a federation between domains to meet the functional, non-functional, and security requirements of a given service, as defined by service management layer 11. More specifically:

[0113] - depending on the service orchestration descriptor, the SLA and the SSLA, the Manager 112 of cross-domain federations selects:

[0114] - the domains involved in the federation among all the domains available (in the example shown in [Fig.4], the domains selected from the available domains DI to D5 are DI to D3) and

[0115] - in addition, among these selected domains, a domain which will play the role of " master” in the federation (here D2).

[0116] In a step 202, the cross-domain federation manager 112 subsequently requests the master domain, through the master domain's federation controller 120, by sending it the SOD and the SSLA, as well as the list of domains involved in the federation in order to initiate the service-related federation.

[0117] In step 203, the federation controller 120 of the master domain initiates the federation by informing the federation controllers 120 of the other federation domains, which must in turn pay their federation contribution. The federation controller 120 of the master domain sends a failure notification to the inter-domain federation manager 112 if one of the federation domains does not pay its contribution, that is, if it does not respond for a given (predefined) time or responds with an error message that provides more details about the nature of the error. In this case, the master domain notifies those of the other (federation) domains that have already paid that the operation (creation of the federation) is canceled.

[0118] In a step 204, the master domain federation controller 120 then distributes the SOD and the SSLA to the master domain security policy manager 121, which supplements, based on the SSLA, the SOD of the end-to-end service with security policies and the security services / functions that need to be orchestrated in the end-to-end service and that derive from the SSLA.

[0119] The updated SOD is called the Security Augmented Service Orchestration Descriptor (SASOD).

[0120] In step 205, in order to initiate the orchestration process within the federation: - The SASOD is delivered to the active SASO 122 of the master domain, which in turn distributes it to the SASO 122s of the other domains in the federation; the SASO 122 of the master domain can distribute the entire SASOD descriptor or it can distribute to a domain only the parts of the descriptor that concern that domain (this is an implementation choice: in the first case, it promotes the distribution and autonomy of the different domains and facilitates changes of role between domains in the master domain; the second case adapts to a policy that limits the sharing of information between domains). - Each SASO 122 of a federation domain initiates a search at the security catalog level for that domain to find the functions that pertain to the domain and that comply with the SSLAs expressed as policies and nodes in the SASOD; once these security functions are found, the SASO 122 generates a final SASOD for its domain that describes all the security applications and functions. which will be orchestrated as part of the implementation of the service in question. The SASO 122 of each domain transforms the SASOD into a service descriptor compatible with each lower-level orchestrator (123, 124) in each domain. The orchestrators (123, 124) of each domain acknowledge the success of the service deployment to their domain's SASO 122. Each SASO 122 in the federation informs the master domain's SASO of the successful implementation in their domain once the deployments are complete. This allows for the services to be updated when a solution is updated and ensures they remain as close as possible to the implementation.

[0121] All exchanges take place via exchange module 15.

[0122] The SASO 122 of each federation domain orchestrates the selected security services and configures them according to the SASOD generated for its domain. The SASO 122 of domain Di, i = 1 to 3, does not execute orchestration tasks that are not relevant to its domain if they are included in the SASOD distributed to it.

[0123] In addition to security service orchestration, each time the SASO 122 of domain Di, i = 1 to 3, encounters a specific orchestration task from a business orchestrator 123, 124 of the domain infrastructure, in step 206, the SASO 122 delegates this task to the corresponding business orchestrator 123, 124 of Di (e.g., network, application, etc.). The latter sends an acknowledgment of all orchestration tasks performed to the SASO 122, which in turn sends an acknowledgment of all orchestration tasks performed to the security policy manager 121 of the master domain (D2) by sending it the orchestrated SASOD (i.e., a SASOD as described above, except that this one represents what was actually orchestrated). The 121 security policy manager verifies the consistency of end-to-end orchestrations as well as their compliance with the SSLA.The master domain D2 handles the end-to-end orchestration of the service to federation manager 112.

[0124] Each SASO 122 compares, in non-critical real-time, the state of the orchestrated system in its domain with the SASOD in its domain to verify the satisfaction of the security policy locally. This enables the dynamic maintenance of the security policy.

[0125] The controllers 120 of the domains of a federation share the same sub-certification authority (sub-CA) which is derived from the root certification authority Root_CA 113 present in the service management layer 11. This makes it possible to maintain a relationship of trust between the domains of a federation, based on the generation of cryptographic keys through this sub-CA.

[0126] The federation manager 112 creates a federation between several domains for each service to be orchestrated end-to-end by selecting these domains based on their business properties, quality of service and security as indicated respectively in the SOD, SLA, and SSLA of the service to be orchestrated. For example, a domain that does not meet the necessary requirements for robust encryption algorithms for a given federation cannot join it. The selection of a master orchestration domain can also be based on these business properties, quality of service, or security and trust.

[0127] The creation of a federation allows two or more domains to manage the orchestration process collaboratively without relying on centralized orchestration management at the end-to-end service management layer 11. Unlike existing reference orchestration architectures that rely on a centralized orchestrator to coordinate orchestration across multiple domains, this decentralized approach not only avoids the single point of failure of a centralized architecture but also grants autonomy to the domains. This autonomy is particularly useful in certain use cases, such as defense, where domains can represent armored vehicles and / or drones that collaborate autonomously during certain periods of their lifecycle. This is generally the case for use cases that integrate connected objects and edge computing, even in a civilian context.

[0128] A domain can belong to multiple federations. In particular, a master domain can belong to multiple federations and be elected as master in multiple federations. In this case, three levels of isolation are possible for the federations according to the security and resource requirements expressed in the SLA and SSLA.

[0129] These three distinct levels of insulation are as follows:

[0130] - level "isol_l": nodes participating in different federations are part of different clusters (a cluster is defined as a set of nodes that allow a given application to run); each federation then benefits from its own SOMC (Security Orchestration Management cluster) and its own SDC (Service Deployment Cluster) on these nodes (see the section "Architecture of intra-domain orchestration plans and their initialization" below). Isolation is maximized in this case but requires more resources on the nodes.

[0131] - "isol_2" level: federations can share a SOMC and each have its own SDC; This ensures maximum isolation for the security of deployed services, but pools orchestration management within a single cluster. In this case, orchestration management isolation for each federation within the same SOMC is still ensured, logically through access control, which is therefore less robust than in the previous case (level "isol_l"). On the other hand, it allows for a lower consumption of computing resources for each SOMC node, which is more suitable for edge environments;

[0132] - "isol_3" level: federations can share the same SOMC and the same SDC for all federations; this solution is better suited to the Edge; it ensures logical isolation through access control.

[0133] The SOD is thus a descriptor containing information, including topologies but also additional resources required for these topologies (e.g., source files). The SOD is then enriched by the Policy Manager in the master domain to generate the SASOD. The SASOD is then interpreted by the SASO, which will execute the actions necessary to orchestrate the topology described in the SOD.

[0134] The SASOD template (extended TOSCA in the example) is generated by the master domain's security policy manager (121) and distributed to the security orchestrators of all federation domains by the SASO. It is up to each orchestrator in each domain to determine the local implementation for the SSLAs translated into the SASOD templates and to inform the master domain's SASO of the successful implementation in its domain.

[0135] Each Node Type (enabler) was determined based on the security functions (PEPs / Enablers) supported by each domain (available in their respective catalogue), their metadata and the policy requested.

[0136] Deployment of a service secured by a SASO 122 orchestrator, and resilience of intra-domain security orchestration

[0137] Architecture of intra-domain orchestration plans and their initialization

[0138] With reference to [Fig. 1], for each domain, we consider 2 clusters: - a security orchestration and management cluster ("Security Orchestration & Management Cluster" - SOMC), in which SASO 122 is hosted; - a secure service deployment cluster ("Service Deployment Cluster" - SDC), in which the service components and associated security functions are deployed / hosted - and generally orchestrated.

[0139] In the SOMC: between Node 1 (NI: SASO) and Node 3 (N3: orchestration data "orchestration_data") is the internal control plane of the SOMC; between Node 2 (N2: orchestration data) and Node 3 is the data plane of the SOMC.

[0140] A VIM (Virtualized Infrastructure Manager) is a service orchestrator, specific to the execution platform and instantiated in the SDC for a given federation (tenant). It is a low-level orchestrator, specific to the SDC technology.

[0141] In the SDC: between Node 1 (NI: VIM) and Node 2 (N2: service) is the internal control plane of the SDC; between Node 2 and Node 3 (N3: services) is the service data plane.

[0142] Between Nodes 1 of the SOMC and SDC is the intra-domain orchestration control plane network.

[0143] The SOMC and SDC control plans have similar components (see [Fig.2]), except for the SASO in the SOMC, and divergent data plans depending on the SASO / VIM purpose.

[0144] The SOMC control plan 50 therefore includes the following functionalities: - an API 51 for service management and orchestration on a SOMC node which implements all the necessary interactions between the orchestrator components; - a replicated database 53 on each node of the SOMC for the persistence of control plane data for orchestration management; - a 52 orchestration management controller on a SOMC node that checks the status of the control plane, data plane and security policy and ensures their resilience; - an agent 54 replicated on each node of the SOMC in order to perform the tasks of orchestration management; - a 55 monitoring probe replicated on each node of the SOMC in order to monitor the orchestration management tasks.

[0145] Similarly, the SDC control plane includes the following features: - an orchestration API on an SDC node that implements all the necessary interactions between the components of the VIM orchestrator; - a replicated database on each node of the SDC for the persistence of data relating to the control plane of service orchestration; - an orchestration controller on an SDC node that checks the status of the control plane and the data plane of the security services and their resilience; - an agent replicated on each node of the SDC in order to execute the services; - a monitoring probe replicated on each node of the SDC in order to monitor the services.

[0146] This separation ensures a level of resilience for both management and orchestration (SOMC) and for deployed services (SDC) while separating the different data planes and control planes.

[0147] In this separation, it can be noted that only the intra-domain orchestration control plane network is external to the two clusters. Four other subnetworks are noteworthy: - the WTO control plan, - the SOMC data plane, - the SDC control plan, - the SDC data plan.

[0148] None of these subnets are public; they are only local subnets at the nodes of the clusters.

[0149] At initialization, the deployment of SOMC and SDC clusters depends on the isolation configuration associated with the federation (see chapter describing the three levels of isolation above).

[0150] During initialization and in the case of maximum cluster isolation (corresponding to the "isol_l" level described above), each initial federation 120 controller receives the order, from layer 11 and transmitted by the initial federation master 120 controller, to deploy a new SOMC and a new SDC dedicated to the new federation. Subsequently, each federation 120 controller deploys the necessary orchestration management services in the new SOMC, namely a new federation 120 controller dedicated to this new federation, a SASO 122, and all other lower-level orchestrators. The new federation 120 controller is configured to communicate with the new SASO 122 and all other new federation 120 controllers. The new SASO 122 is configured to communicate with the new lower-level orchestrators.The new, lower-level orchestrators are configured to communicate with the VIM of the new SDC. Finally, the original federation master controller 120 delegates its role to the new 120 controller in its domain, which then becomes the master of the new federation. This new federation master controller informs layer 11 of its new role and acknowledges the successful creation of the new federation.

[0151] During initialization, and in the case of SDC cluster isolation only (corresponding to the "isol_2" layer described above), each 120 controller in the new federation receives an order from layer 11, transmitted by the federation master 120 controller, to deploy a new tenant in its SOMC to logically separate the management services from the orchestration of the new federation, as well as a new SDC dedicated to the new federation. Subsequently, each federation 120 controller configures the lower-level orchestrators to communicate with the VIM of the new SDC. Finally, the federation master 120 controller acknowledges the successful creation of the new federation to layer 11.

[0152] During initialization, and in the case of minimum cluster isolation (corresponding to the "isol_3" level), each 120 controller in the new federation receives an order from layer 11, transmitted by the federation's master 120 controller, to deploy a new tenant in the SOMC and the SDC in order to logically isolate all services of the new federation. Finally, the federation's master 120 controller acknowledges the successful creation of the new federation to layer 11.

[0153] Intra-domain resilience

[0154] - Intra-domain resilience of orchestration and security services

[0155] Since SASO and all other orchestrators are services, intra-domain orchestration resilience will be governed by the same mechanisms in SOMC and SDC. The resilience of service orchestration services is the responsibility of the SOMC control plan. The resilience of services is the responsibility of the SDC control plan.

[0156] A controller of a control plan ensures the resilience of a service by: - updating the cluster status - applying a control loop to: • determine if service replicas exist and on which nodes they are installed; • calculate the instantiation of new replicas if there are not enough compared to the demand by selecting appropriate nodes and according to availability and quality of service criteria; - deploying missing service replicas on selected nodes.

[0157] For these control loops, and in the event of a node failure, the node's new state is declared as unavailable. The service states on that node will thus be affected, and the control loop for service replication will trigger the migration of these services to the remaining available nodes to ensure resilience.

[0158] - Intra-domain resilience of the data plane of orchestration and services security

[0159] To support the resilience of an application, it is necessary to ensure the resilience of its data. To achieve this, two control loops are used: - a loop in the control plane to ensure the resilience of storage service replicas (for a service) on the nodes; storage replicas are services, so this operation is the same as the control loop for service replication; - a loop in the data plane to ensure data replication in read / write mode across nodes for a service.

[0160] Node selection refers to an algorithm whose purpose is to choose a node from among all those available in one or more clusters. This node is selected based on selection criteria such as its resource consumption or its network properties: - available CPU units; - available RAM memory; - available disk space; - available network interfaces and bandwidth; - ports available.

[0161] These criteria allow for an initial selection of nodes from among all those available using a simple approach. If any one of the criteria is not met for a node, that node is automatically disqualified from the rest of the selection algorithm. If none of the nodes are available, the algorithm returns an empty set.

[0162] Among the first nodes selected, a second calculation is performed to determine a score. Each criterion will be normalized according to the availability of the following resources: - cpu_norm = available CPU units / total CPU units - mem_norm = available RAM in bytes / total RAM in bytes - disk_norm = Available storage in bytes / Total storage in bytes.

[0163] Then a normalized scoring algorithm is applied:

[0164] score_node = (cpu_norm + mem_norm + disk_norm) / 3

[0165] All nodes are compared by score, and the one with the highest score is selected. In case of a tie, one of the nodes is selected randomly. An alternative is to take the node with the smallest (or largest) identifier in the cluster, by lexicographical or numeric comparison depending on the implementation choice, knowing that this identifier is unique for each node in the cluster (typically based on the FQDN in the node's PKI certificate).

[0166] Therefore, in addition to the initial application deployment steps described in the section above, "Resilience of Orchestration and Security Services": - the controller:

[0167] - detects the absence of storage replicas of a service;

[0168] - calculates the creation of storage instances;

[0169] - calculates the installation of a storage controller on the service node;

[0170] - selects the nodes where to install them (according to the selection algorithm described below) above, in one embodiment);

[0171] - notifies the API; - The API requests agents to deploy: a replica of the storage on the selected nodes • a storage controller on the service node - The storage controller monitors the service's read / write actions on the local storage replica, and synchronizes any operations on the other replicas in the data plane.

[0172] Thus, if there is a failure of the storage replica on one of the nodes, or a failure of one of the nodes, data persistence is ensured through replication of the data across all nodes. In the event of a failure of the node hosting the service instance and the storage controller, the control plane API can redeploy these two instances to an available node, which will then access the local storage replica containing the latest updated state of the persisted data. This behavior is identical to the scenario of a node failure and the replication of its services, described above.

[0173] - Intra-domain resilience of the control plan

[0174] Database for the control plan

[0175] The resilience of the control plane is ensured by the replication of all its components across multiple nodes of a cluster.

[0176] The storage required for the control plane is replicated across all nodes and operates as an independent cluster. The members of this cluster are statically configured by specifying, for each member, the access points of the other members. Subsequently, high availability of the cluster data is achieved using the RAFT protocol (In search of an understandable consensus algorithm, Diego Ongaro and John Ousterhout, 2014, in Proceedings of the 2014 USENIX conference on USENIX Annual Technical Conference) between the cluster members. Thus, storing data via one member of this cluster will trigger data synchronization on the other members to ensure resilience.

[0177] This ensures the resilience of the SOMC and SDC control plan data.

[0178] API

[0179] The API and controller replicas operate independently; that is, only the instance being requested at any given time will run independently of other instances. Thus, only one access point to an API is used for each request. This API only uses local storage, which will replicate the data from that node across the entire storage cluster.

[0180] API requests will be determined by a load balancer upstream of a request. Since the load balancer is itself an application, its resilience is ensured in the same way as for an application in the data plane (see section above, "Resilience of Orchestration and Security Services").

[0181] Agents and Probes

[0182] The agent and the probe are installed on each node.

[0183] In the event of a failure of one of the nodes, the resilience of the cluster control plane is therefore ensured.

[0184] - Intra-domain resilience of security policy

[0185] The resilience of security services is well ensured by the VIM, but the resilience of security policies is ensured by the SASO.

[0186] To enforce a security policy, the SASO communicates with the SDC control plane through the intra-domain orchestration control plane subnetwork to ensure that the correct security services are deployed and that the security policy is monitored. The SASO then collects metrics from the probes to monitor the status and resilience of a policy using its controller.

[0187] The implementation of the policy then relies on specific resilience mechanisms:

[0188] a / a client sends a SASOD to the SASO API;

[0189] b / the SASO orchestrator queries the SOMC data plane database to check if there is already a version of SASOD in the database;

[0190] c / The SASO thus detects whether it is a new state of the SASOD, in which case it performs the following tasks: • compare with the current implementation of the policy; • detects the absence of security services implementing the policy on the SDC nodes; • selects the appropriate security services according to the security policy • enriches the SASOD with the selected security services, then returns this descriptor to the API;

[0191] d / the SASO saves the SASOD update in the SOMC data plane database, translates it into specific language and sends it to a lower level orchestrator, then updates the SDC probes to monitor the new policy.

[0192] e / the deployment of services to implement the security policy on the SDC is done as described in the section "Intra-domain resilience of orchestration and security services".

[0193] In parallel, the SASO monitors the state of the policy implemented on the SDC nodes via the probe installed on them. Each new state implemented on the SDC nodes is detected by the API and triggers a new action from the controller to ensure its resilience.

[0194] This new control loop can have several consequences depending on the difference between the SASOD enrichment transmitted to the SDC service orchestrator and the actual state of the services on the SDC: - reconfigure security services; - Redeploy security services; - Uninstall security services; - Deploy a new security service.

[0195] Intra-domain election of the master orchestrator of a domain

[0196] For SASO as for lower-level orchestrators, only one orchestrator of each type in each cluster is active at a time.

[0197] By exploiting the control plane replication functionality of each cluster described in the "Intra-domain Resilience for the Control Plane" section above, the resilience of these orchestrators is ensured by applying a replication of one (1) on all nodes.

[0198] The selection of this node by the control plane of each cluster is governed by the same mechanism as defined previously for node selection within the framework of intra-domain data plane resilience. Indeed, the control plane of a cluster knows the state of the nodes at all times (see section "Cluster Resilience"). It can therefore use these criteria to elect a node for the deployment of an orchestration service (SASO or VIM).

[0199] If none of the nodes are available, the request to deploy an orchestrator is rejected.

[0200] Example: Deployment of an end-to-end encrypted communication service in tactical communication bubbles

[0201] The goal in this example implementation is to secure data plane communications between two access points in two domains, which we will call "domain A" and "domain B," represented by communication bubbles. The communication protocol will be TCP, and encryption will be provided by the TLS security protocol. Each bubble represents a domain and consists of several computing nodes that communicate with each other.

[0202] In the initial conditions of the example, no communication takes place between the two domains on a data plane, but each domain has compute nodes, a federation controller, a SASO, and functional business orchestrators (network, applications). Communication via the control plane is only possible between the federation manager and the federation controllers of each domain, but no communication takes place between the two domains on the control plane.

[0203] The expression of the need on this example translates, via the federation manager of the service management layer, into the generation of a SOD which describes domains A and B, the end-to-end TCP communication service (i.e. via domains A and B) and a certificate authority for federation, as well as an SSLA, which describes the TLS encryption capability on the service.

[0204] Here, we will consider the master domain to be domain A, designated in the SOD. The initial master federation controller is therefore the federation controller of domain A. The initial master SASO is therefore the SASO of domain A.

[0205] The federation manager transfers the SOD and SSLA to the master federation controller (domain A) via the control plane. The master federation controller then establishes communication with the federation controller of domain B through the federation control plane so that they can form a federation of domains. The federation controller of domain B communicates the success of the federation joining to the master federation controller, which can then attest to the successful creation of the federation at layer 11 of the E2E (End-to-End) service management.

[0206] The security policy manager for domain A enriches the SOD, based on the TLS security requirement expressed by the SSLA, with a security policy specific to the federation of the associated service, in order to generate a SASOD. The SASOD therefore includes both the topology description of the end-to-end TCP service in the federation and the description of the security policy ensuring TLS encryption in the federation, on this service.

[0207] The master federation controller transmits the SASOD to the SASO of its domain (domain A), which is then the master SASO of the federation. The master SASO transmits this SASOD to the SASO of domain B through the federation control plane.

[0208] Each SASO contacts its function catalog, which is then managed by its domain with its own virtual security and business functions. The security and business functions are selected based on the SASOD in each domain and are linked to the service and security policy to be implemented. In our example, the SASOs of each domain select virtual network, IT (infrastructure), and application functions to establish a dedicated communication channel between a TCP client in domain A and a TCP server in domain B, and security functions to ensure the confidentiality and integrity / authenticity—with mutual authentication—of the communication channel.

[0209] The SASODs are translated, according to the functions selected in the catalog, by SASO application modules into a specific implementation for business orchestrators (network, IT (infrastructure), applications) in their domain. The deployment of the virtual functions is then delegated to these orchestrators, who attest Finally, the successful deployment of functions on the compute nodes of each bubble is verified. The SASO of domain B can then attest to the master SASO of domain A that encrypted communication is possible on its domain via the dedicated communication plan. The master SASO can subsequently attest to the federation that the orchestration of end-to-end encrypted communication is successful, once all SASOs have attested to the success of their own deployment.

[0210] In the living conditions of this example, communication is end-to-end encrypted for the service deployed between domains A and B. It is also dynamically terminated.

[0211] The conformity of the operation of the service on each domain is controlled by the SASO of the domain and in case of detection of non-conformity, the SASO of said domain notifies the SASO of the master domain, which triggers where appropriate a modification of the deployment of said SASOD implementation or a modification of the SASOD implementation.

[0212] For example:

[0213] In the event of a failure of one of the compute nodes belonging to domain B, the resilience and security of the functions implementing the service are ensured by the business orchestrators of domain B. They simultaneously alert the SASO of domain B and operate in quorum with it to repair the failure. The SASO of domain B also alerts the master SASO of domain A as soon as possible, so that the SASOs can operate in quorum to repair the failure end-to-end if necessary.

[0214] In the event of a security policy violation, for example, when encryption algorithms are modified on domain B, the SASO of domain B detects and calculates deviations from the policy in real time. This is done by comparing the data reported by the business orchestrators regarding the deployed functions with the policy contained in the SASOD that is normally applied to the domain. In our case, the SASO of domain B instructs the business orchestrators, as soon as a deviation is detected, to reapply the correct TLS configuration (the correct encryption algorithms, the correct protocol version, etc.) to its domain. The SASO of domain B also alerts the master SASO of domain A as soon as possible, so that the SASOs can operate in quorum to repair the security policy violation end-to-end if necessary.

[0215] In the event of a failure of a node hosting the SASO or the federation controller, in domain B for example, its resilience is ensured by its replication on all the compute nodes of domain B, but only one SASO and one federation controller are active at the same time for the orchestration and federation tasks in domain B. In the event of a failure of one of the active nodes, the replicas of the other nodes They detect the failure and act as a quorum to elect a new active SASO or federation controller in domain B, activating its orchestration or federation functions. The new active SASO or federation controller contacts the master SASO or federation controller in domain A to update them.

[0216] In the event of a failure of the node hosting the master SASO in domain A, its resilience is ensured by the same process described above, as well as for its master function.

[0217] In the event of a failure of the node hosting the master federation controller in domain A, the same process is activated with respect to the master function of the federation controller, but across all domains. Thus, the master functions of the SASO and federation controller are transient within a federation and can change domains in case of failure. In our case, the federation function of the federation controller in domain A is first restored on a new node in domain A. Then, if the new master federation controller is elected in domain B, the SASO in domain B becomes the new master SASO of the federation. Finally, the new master federation controllers and SASOs in domain B inform the SASO and federation controller in domain A to update them.

[0218] In the worst-case scenario where the entire domain A fails (that is, all nodes in domain A fail), the federation controllers of the other domains—here, domain B—detect this, and domain B assumes the role of master domain. If there is a third domain C, a protocol to elect the new master domain is triggered between B and C. Domains in a federation exchange live signals between federation controllers using a gossip-based protocol (or gossip algorithm), such as those described in Gossip-based Protocols for Large-scale Distributed Systems, Mark Jelasity, 2013. When a domain is unreachable for a certain period of time, it is considered lost.

[0219] In all cases where there is a change of master domain for a given federation, the new master domain must inform the E2E service management layer of the change.

[0220] In this application of the invention, for example:

[0221] - security requirements are defined by SSLAs;

[0222] - Service orchestration descriptors (SOD and SASOD) are denoted in TOSCA;

[0223] - the features and services (orchestration, applications, security, network) are software objects, for example, of the "container" type, i.e., a software package containing executable code that distributes an application with all its elements, including It needs the following to function: source files, configuration files, libraries, dependencies, etc.

[0224] - the SOMC and SDC nodes are virtualized into VMs ("Virtual Machine") ARM64 or x86_64;

[0225] - inter-domain communication protocols and between the management layer of Services and federations are provided via TCP, and communication security will be ensured by TLS.

[0226] - the communication APIs between orchestrators are implemented in REST;

[0227] - the asymmetric cryptography used is RSA 4096-bit or ECDSA 384-bit or other post-quantum algorithms following the recommendations of ANSSI or NIST (failing that) in force;

[0228] - the resilience of SOMC and SDC data is ensured by the RAFT protocol;

[0229] - the symmetric encryption keys used are AES-256 keys.

[0230] The present invention thus proposes a method (and a protocol) for interaction between the security orchestrator and other orchestration levels within and between domains. It is implemented, for example, in 5G or 6G networks. Orchestration is decentralized through the implementation of a federation. The described security orchestration solution is resilient within and between domains. It enables automation and elasticity specific to security, which has the same automation and elasticity requirements as network functions and applications (softwareization, virtualization, cloudification, and the same pace of evolution).

[0231] Security is injected as early as possible into the orchestration process at the level of all domains.

[0232] Security orchestration is implemented end-to-end based on SSLAs.

[0233] The solution relies on an enrichment of topology descriptors for orchestration with security policies (for example using TOSCA), as well as a dynamic and distributed selection of security functions.

Claims

1. Demands A multi-domain security orchestration method using an orchestration system (10) of a service implementation platform (14) comprising a plurality of computing, network, or storage resource domains for service implementation; each domain being associated with: - a security-oriented service orchestrator, known as SASO (122), autonomous, performing, in said domain, service orchestration and security orchestration, - a catalogue of functions (65), including security functions, that can be deployed in the field, - a federation controller (120), - a security policy manager (121), according to which each service to be orchestrated is associated with a security level digital contractual agreement, called SSLA, and with a topology descriptor of the orchestration of said service, called SOD, the process includes the following steps implemented by a service management module of the orchestration system: depending on the SSLA and the SOD associated with the service, selection of some of the domains for the implementation of the service selectively from said selected domains, triggering the automatic creation of a federation of the selected domains via the federation controllers of the selected domains, and dynamically selecting, from among the domains of the federation, a master domain of said federation; provision of the SOD and SSLA to the master domain security policy manager; according to which the security policy manager (121) of the master domain then automatically creates, based on said SOD and SSLA, a security-enhanced service orchestration topology descriptor, named SASOD, describing the end-to-end topology of the service as deployed across the federation's domains, including the SSLA associated with the service, and transmits it to the SASO of the federation's master domain, which in turn transmits the SASOD to the SASO of each other domain of the federation created for said service; in each domain: - the SASO (122) of each domain of the federation enriches said SASOD, according to the catalog of functions, including security, of said domain, into a service orchestration implementation, specific to the domain and respecting the SSLA associated with the service; - the orchestration of the service in accordance with the SSLA on the domain is carried out according to said orchestration implementation.

2. A multi-domain security orchestration method according to claim 1, wherein in at least one of the federation domains, at least a portion of said orchestration implementation is distributed by the SASO (122) of said domain to a domain orchestrator separate from the SASO (122) and dedicated to one aspect among {network, applications, platform}; the deployment of the service in accordance with the SSLA is performed based on said orchestration implementation by at least said domain orchestrator separate from the SASO.

3. A multi-domain security orchestration method according to any one of the preceding claims, implementing at least one of the following provisions: - in at least one of the federation's domains, the SASO (122) is duplicated on a plurality of nodes hosting the resources, with only one of said SASOs being active at a time in said domain, and another of said SASOs being activated in said domain in case of failure of the previously active SASO; - in at least one of the federation's domains in which at least part of said orchestration implementation is distributed by the SASO of said domain to an orchestrator of the domain distinct from the SASO, said orchestrator of the domain distinct from the SASO is duplicated on a plurality of nodes hosting the resources, with only one of said orchestrators being active at a time in said domain, and another of said orchestrators being activated in said domain in case of failure of the previously active orchestrator;- in at least one of the federation domains, the federation controller is duplicated on a plurality of nodes hosting the resources, only one of said federation controllers being active at a time in said domain, another of said federation controller(s) being activated in said domain in case of failure of the federation controller previously active.;

4. A multi-domain security orchestration method according to the preceding claim, wherein said other element of a given type among SASO, SASO distinct domain orchestrator and federation controller, which is to be activated, following a failure of the element of the same type previously active within the same domain, is identified, among the elements of the same type, by a dynamic and distributed election mechanism.

5. A multi-domain security orchestration method according to any one of the preceding claims, implementing at least one of the following provisions: - following the detection that a domain of the federation is failing, selection of another domain from the plurality of domains to replace, in the federation, the failing domain, for the implementation of the service selectively from said selected domains; - following the detection that the federation's master domain is failing, implementation of a dynamic and distributed election mechanism for a new master domain from among the other federation domains.

6. A multi-domain security orchestration method according to any one of the preceding claims, wherein the conformity of the security level of the service operation with respect to the SSLA on each domain is controlled by the SASO of said domain and in the event of detection of non-conformity, the SASO of said domain notifies the SASO of the master domain, which triggers, where appropriate, at least one of the following actions: - modification of the orchestration of said SASOD implementation; - SASOD implementation modification.

7. Orchestration system (10) for a service implementation platform (14) comprising a plurality of computing, network or storage resource domains for service implementation and a (12), associated with each domain: - a security-oriented service orchestrator, known as SASO (122), autonomous, performing, in said domain, service orchestration and security orchestration, - a catalogue of functions (65), including security functions, that can be deployed in the field, - a federation controller (120), - a security policy manager (121), in which each service to be orchestrated is associated with a digital security level agreement (SLA) and a topology descriptor for the orchestration of said service (SOD),

8. in which a service management module of the orchestration system (11) is adapted to, depending on the SSLA and SOD associated with the service, select some of the domains for the implementation of the service selectively from said selected domains, to trigger the automatic creation of a federation of the selected domains via the federation controllers of the selected domains, and to dynamically select, from among the domains of the federation, a master domain of said federation; in which the service management module (11) of the orchestration system is adapted to provide the SOD and the SSLA to the security policy manager of the master domain; in which the master domain's security policy manager is adapted to then automatically create, based on said SOD and SSLA, a security-enhanced service orchestration topology descriptor, named SASOD, describing the end-to-end topology of the service as it is applied to the federation's domains, including the SSLA associated with the service, and to transmit it to the SASO of the federation's master domain, which is adapted to then in turn transmit the SASOD to the SASO of each other federation domain created for said service; in which, for each domain: - the SASO of each domain of the federation is adapted to enrich said SASOD, according to the catalog of functions, including security, of said domain, into a service orchestration implementation, specific to the domain and respecting the SSLA associated with the service; and in which the service orchestration in accordance with the SSLA on the domain is performed based on said orchestration implementation. Orchestration system (10) according to claim 7, wherein in at least one of the federation domains, at least a part of said orchestration implementation is distributed by the SASO of said domain to a domain orchestrator distinct from the SASO and dedicated to one aspect among {network, applications, platform}; in which the deployment of the service in accordance with the SSLA is carried out based on said orchestration implementation by at least said orchestrator of the SASO separate domain.

9. Orchestration system (10) according to claim 7 or 8, wherein: - in at least one of the federation domains, the SASO is duplicated on a plurality of nodes hosting the resources, only one of said SASOs being active at a time in said domain, another of said SASOs being activated in said domain in the event of a failure of the previously active SASO; and / or - in at least one of the federation domains in which at least part of said orchestration implementation is distributed by the SASO of said domain to an orchestrator of the domain distinct from the SASO, said orchestrator of the domain distinct from the SASO is duplicated on a plurality of nodes hosting the resources, only one of said orchestrators being active at a time in said domain, another of said orchestrators being activated in said domain in the event of a failure of the previously active orchestrator;and / or - in at least one of the federation domains, the federation controller is duplicated on a plurality of nodes hosting the resources, only one of said federation controllers being active at a time in said domain, another of said federation controller(s) being activated in said domain in case of failure of the federation controller previously active.;

10. Orchestration system (10) according to the preceding claim, wherein said other element of a given type among SASO, orchestrator of the SASO distinct domain and federation controller, which is to be activated, following a failure of the element of the same type previously active within the same domain, is identified, among the elements of the same type, by a dynamic and distributed election mechanism.

Images