Compliance verification in a distributed system

Abstract

A method performed by a distributed node in a distributed system, for facilitating formal verification of compliance of a security property in the distributed system is disclosed. The method comprises determining whether a distributed dataset represents a horizontal distribution of datapoints in the distributed system or a vertical distribution of datapoints in the distributed system, wherein a plurality of datapoints forming a distributed dataset are distributed amongst a plurality of distributed nodes in the distributed system, wherein each datapoint represents an instance to be verified as to its compliance to the security property, and wherein the distributed node has access to a local subset of the distributed dataset; iteratively performing a number of operations, for a predetermined number of iterations N, to form a training dataset comprising a number of datapoints of the local subset, and to obtain a Machine Learning, ML, model for predicting violation of the security property; forming a modified local subset comprising the datapoints of the local subset that are absent from the training dataset; classifying, using the ML model, each of the datapoints of the modified local subset into one of a first subset and a second subset, wherein the first subset includes datapoints that are predicted as having violating characteristics with respect to the security property, and the second subset includes datapoints that are predicted as having non-violating characteristics with respect to the security property; and responsive to determining that the distributed dataset represents a horizontal distribution of datapoints: formally verifying whether each datapoint in the first subset violates the security property, and generating a list of datapoints in the first subset that violate the security property; or responsive to determining that the distributed dataset represents a vertical distribution of datapoints, transmitting the first subset to a central node in the distributed system, wherein the central node is configured to formally verify whether each datapoint in the first subset violates the security property and to generate a list of datapoints in the first subset that violate the security property.

Description

[0001] COMPLIANCE VERIFICATION IN A DISTRIBUTED SYSTEM

[0002] TECHNICAL FIELD

[0003] The present disclosure relates to a method performed by a distributed node in a distributed system, for facilitating formal verification of compliance of a security property in the distributed system. The present disclosure also relates to a computer program and a computer program product configured, when run on a computer to carry out such a method. The present disclosure also relates to a method performed by a central node in the distributed system, for facilitating formal verification of compliance of the security property in the distributed system. The present disclosure also relates to a computer program and a computer program product configured, when run on a computer to carry out such a method. The present disclosure also relates to a distributed node, and to a central node.

[0004] BACKGROUND

[0005] Microservice-based architecture

[0006] 5G and 6G networks are expected to provide virtually unlimited gigabit and ultra-reliable connections to people and objects when and where it matters, supporting diverse use cases. Building such networks requires the support of flexibility, agility, dynamic reconfiguration, and scalability, in addition to complying with a range of demanding requirements in terms of latency, throughput, reliability, coverage, security, cost targets, and more. To address these challenges, a microservice-based architecture is a software engineering paradigm that allows dividing a single application into loosely coupled, small autonomous microservices. This architecture allows for independent development, deployment, and scaling of different functionalities, leading to enhanced scalability, flexibility, and cost efficiency in application development and maintenance.

[0007] Distributed / Federated AI / ML in Core and RAN

[0008] There are widespread efforts and support for AI / ML across various 3GPP Working Groups. The Network Data Analytics Function (NWDAF) in 5G Core (5GC) is a network function that provides AI / ML functionality, such as statistics and predictions related to UE mobility, user data congestion, QoS, network performance, etc. rApp and xApp are part of the Radio Access Network (RAN) and leverage AI / ML to address RAN needs. In addition to centralized ML training, there are multiple distributed ML training technologies, including transfer learning, split learning, horizontal federated learning, and vertical federated learning. The choice of technology depends on the specific use case. Distribution may occur across remote sites [1] (https: / / www.ericsson.eom / en / blog / 2022 / 1 / cognitive-networks-6g-architecture).

[0009] In Federated Learning (FL), the participants train an ML model with their local data and send updates (i.e. , local model parameters) to a federated server in an encryption mode. The server (also known as an aggregator or coordinator) fuses the local updates and uses them to create a new generic global model that is often sent back to the parties. This process can be repeated several times to obtain a final global model that achieves a certain desired performance or until another stopping condition is reached. Federated learning can be categorized into horizontal federated learning (HFL), vertical federated learning (VFL), and federated transfer learning (FTL) according to the distribution of data. Horizontal federated learning is suitable in the case where all participants share the same attributes (or features), i.e., the attributes are aligned across the participants, but the participants have different data samples. In contrast, vertical federated learning is suitable in the case where all participants share the same data samples, i.e., data samples are aligned across the participants, but the participants have different attributes.

[0010] Figure 1 shows an example of horizontal data distribution, which is horizontally distributed audit data in this example (top) and vertical data distribution, which is vertically distributed audit data in this example (bottom). In the horizontal case, all applications have the three attributes in the data (Attribute 1 , Attribute 2, and Attribute 3), while not having the same record. For example, Application 1 has records #1 and #2, while Application n has records #3 and #4. In the vertical case, the same data record is split between applications. For example, the same data record id #1 belongs to Application 1 and to Application 2, however the attributes are split such that Application 1 has two attributes (Attribute 1 , Attribute 2) and Application 2 has one attribute (Attribute 3).

[0011] In TS 23.288, Rel. 18 [3] (3GPP TS 23.288 V18.3.0 (2023-09) Study on Artificial Intelligence (Al) / Machine Learning (ML) for NR air interface https: / / www.3gpp.org / ftp / Specs / archive / 23_series / 23.288 / 23288-i30.zip), Federated Learning (FL) among multiple NWDAFs has been defined as “a machine learning technique in core network that trains an ML Model across multiple decentralized entities holding local datasets, without exchanging / sharing local datasets”. FL addresses issues like data privacy, data security, and data access rights that may arise in traditional centralized ML techniques where all the local datasets are uploaded to one server. Vertical Federated Learning (VFL) is also mentioned in 3GPP study [4] (3GPP TSG SA Meeting #102, SP-231678_rev1 , Title: New SID on Core Network Enhanced Support for Artificial Intelligence (Al) / Machine Learning (ML), https: / / www.3gpp.org / ftp / tsg sa / WG2 Arch / TSGS2 158 Goteborg 2023) to support Al training and inference for the case of cross-domain (UE, RAN, Core, Applications, etc.).

[0012] Also, it is understandable from

[0001] (https: / / www.e csson.eom / en / bloq / 2022 / 1 / coqnitive- networks-6g-architectiire) that Network Functions (NFs) like gNB, AMF, SMF, and MDAF may contain intelligent components (that require data and trained models) and may also be controlled by intent managers or separately deploy intelligent algorithms. Depending on the nature of the control loop (for example, timing requirements or availability of input data), these could be deployed on the same site / server or distributed across different sites.

[0013] Formal Methods for compliance verification

[0014] In order to rigorously verify the compliance of systems with their security policies and properties (e.g., derived from security requirements stated in standards, regulations, and best practices) and identify those configuration records violating them, a standard practice is to use formal methods. These methods are well-known for providing rigorous mathematical proofs and evidence about compliance. Finding configuration records that violate a security policy requires applying formal methods systematically to each and every configuration record. However, in typical cases, only a part of the records in this dataset violates the security policy.

[0015] There currently exist certain challenge(s).

[0016] Several challenges can arise when enabling formal security verification using formal methods in distributed settings (such as microservice-based environments like 5G and 6G), . The standard practice of using formal methods to provide rigorous mathematical proof about compliance with respect to security policies and properties is becoming challenging in such environments. These challenges include:

[0017] Sheer size of the deployments: Hundreds of thousands of microservices are required for reliable service deployment. Real-life microservices-based applications (mApps) can become very large and complex (e.g., 1000 microservices for the case of Uber and 0(105) different microservices scaled to 0(103) service instances for Twitter in 2016). Several instances can be dynamically and simultaneously deployed to adapt to the service demand, and then instantly reconfigured to accommodate different needs such as improved availability, service failure recovery, attack mitigation, etc. This can result in a huge amount of configuration data and logs hindering collecting and storing all this data in a central location for service and security management.

[0018] Data mobility restrictions: Multi-vendor and multi-provider deployments of 5G, as well as deployments across different administrative domains (different operators) or remote sites (RAN, Core) belonging to different administrators, can raise confidentiality and privacy issues, restricting data mobility and sharing between different administrative domains.

[0019] Computing and network resources: Scarcity of network resources and computing resources (e.g., in edge cloud) can be prohibitive for a centralized approach for security compliance verification.

[0020] In [2] ("MLFM: Machine Learning Meets Formal Method for Efficient Security Verification in Network Functions Virtualization (NFV)", Alaa Oqaily, Yosr Jarraya, Lingyu Wang, Makan Pourzandi, Suryadipta Majumdar, Proc, the 27th European Symposium on Research in Computer Security (ESORICS 2022), Copenhagen, Denmark, September 26 - 30, 2022, Accepted)), machine learning capabilities have been leveraged to guide the audit process performed by formal methods, such that it enables the identification and verification of records violating the security policy using a formal verifier in a faster time than applying the formal verifier on the whole dataset blindly as in traditional approaches. The drawback of this solution is that it only applies in a centralized location, and all the data needs to be transferred to that location. The approach doesn’t support the distributed nature of the modern microservice-based application / services deployed.

[0021] [2] is the only work that combines ML with FM. None of the existing works have proposed the use of FL to enable formal security verification for distributed systems and improve the cost of applying FM tools (such as SAT solvers) for the formal verification of security in a distributed environment. There is no solution addressing this without requiring fully sharing or centralizing the audit data located in distributed nodes to a central trusted node.

[0022] SUMMARY

[0023] Certain aspects of the disclosure and their embodiments may provide solutions to the above noted or other challenges. This present disclosure proposes a solution to address these issues in two cases: where the distributed sites have the same features (or attributes) but different records (the horizontal case), or different features but the same records (the vertical case).

[0024] An objective of the solution proposed herein (named FLFM) is to leverage horizontal (H- FLFM) and vertical (V-FLFM) distributed ML, namely horizontal federated learning, and vertical federated learning, to guide the formal verification of security policies and requirements in a distributed environment (e.g., microservices-based service) such as 5G and 6G.

[0025] The use of FL in this manner increases the speed of identification of the audit records that are more likely to violate the security policies, which can then be verified using formal methods with priority. Methods of the present disclosure enable sorted data to be obtained, and enable audit records with possible violations to be presented with priority to a formal verification tool. This enables the mathematical proof to be obtained early for likely violations, and thus allow faster identification and mitigation of violations. According to certain embodiments described herein, the proposed solution decomposes the local audit records at a distributed node into two subsets: one subset containing most of the records potentially violating the security policy and another subset containing most of the records potentially non-violating the policy. The subset (first subset) containing the violations is verified first, and the other subset (second subset) can be either discarded or verified with a lower priority than the first one.

[0026] As the audit records are distributed among different locations and belong to different owners, a FL-based Formal Method (FM) will help minimize (and in some cases avoid) the need for data mobility across different admin domains for formal verification. Horizontal-FLFM addresses the cases where all participating applications have the same features / security attribute space while the data records are distributed in different applications. Vertical-FLFM addresses the case where participating applications have different features / security attribute spaces for the same data record.

[0027] Certain embodiments of the present disclosure propose leveraging from one of two types of federated machine learning (horizontal and vertical), and formal verification (in the sense of the use of mathematical and logical tools like SAT solvers) to formally audit distributed audit data records against security properties, where it is impossible or not recommended to centrally collect the audit data because of data sharing and privacy constraints.

[0028] There are, proposed herein, various embodiments which address one or more of the issues disclosed herein.

[0029] According to certain embodiments described herein, there is provided a technique which combines federated Machine Learning and formal methods for fast verification and identification of records that violate security policy in a distributed system.

[0030] According to certain embodiments described herein, there is provided a technique that uses a small subset from a local dataset available at a distributed node to build a ML model that can be used to efficiently search and classify the rest of the records in the local dataset (i.e., those not used for building / training the ML model), and group them based on whether they can potentially violate the security policy or not.

[0031] According to certain embodiments described herein, there is provided a technique that iteratively builds a ML model by sampling the local dataset at each iteration, and retaining the ones that allow better detection of violation of a property. The ML model built this way is then used to divide rest of the records in the local dataset into two subsets: one with the data points most probable of violating the property, and one with the other data points (less probable). Depending on whether the distributed dataset represents a horizontal data distribution, or a vertical data distribution, either the distributed node or the central node then tests the most probable datasets first to reduce the time required to detect the property violations. The iterative building of the ML model enables the violations to be identified more quickly, while keeping the cost of using the formal methods to a minimum.

[0032] Some embodiments of the present disclosure include methods performed by a distributed node in a distributed system, for facilitating formal verification of compliance of a security property in the distributed system. These exemplary methods can include determining whether a distributed dataset represents a horizontal distribution of datapoints in the distributed system or a vertical distribution of datapoints in the distributed system, wherein a plurality of datapoints forming a distributed dataset are distributed amongst a plurality of distributed nodes in the distributed system, wherein each datapoint represents an instance to be verified as to its compliance to the security property, and wherein the distributed node has access to a local subset of the distributed dataset. These exemplary methods can also include iteratively performing a number of operations, for a predetermined number of iterations N, to form a training dataset comprising a number of datapoints of the local subset, and to obtain a Machine Learning, ML, model for predicting violation of the security property. These exemplary methods can also include forming a modified local subset comprising the datapoints of the local subset that are absent from the training dataset. These exemplary methods can also include classifying, using the ML model, each of the datapoints of the modified local subset into one of a first subset and a second subset, wherein the first subset includes datapoints that are predicted as having violating characteristics with respect to the security property, and the second subset includes datapoints that are predicted as having non-violating characteristics with respect to the security property. These exemplary methods can also include, responsive to determining that the distributed dataset represents a horizontal distribution of datapoints: formally verifying whether each datapoint in the first subset violates the security property, and generating a list of datapoints in the first subset that violate the security property, or responsive to determining that the distributed dataset represents a vertical distribution of datapoints, transmitting the first subset to a central node in the distributed system, wherein the central node is configured to formally verify whether each datapoint in the first subset violates the security property and to generate a list of datapoints in the first subset that violate the security property.

[0033] Some embodiments of the present disclosure include methods performed by a central node in a distributed system, for facilitating formal verification of compliance of a security property in the distributed system. These exemplary methods can include receiving, from each distributed node, a sample from a respective local subset available at the distributed node, wherein a plurality of datapoints forming a distributed dataset are distributed amongst a plurality of distributed nodes in the distributed system, wherein each datapoint represents an instance to be verified as to its compliance to the security property, and wherein each distributed node has access to a respective local subset of the distributed dataset, and wherein the distributed dataset represents a vertical distribution of datapoints in the distributed system. These exemplary methods can also include merging the received samples. These exemplary methods can also include formally verifying whether each of the received samples violates the security property. These exemplary methods can also include assigning a positive verification tag or a negative verification tag to each of the received samples, wherein the positive verification tag indicates that the respective instance represented by the respective sample violates the security property, and the negative verification tag indicates that the respective instance represented by the by the respective sample does not violate the security property. These exemplary methods can also include transmitting, to each distributed node, the respective sample received from the distributed node and the verification tag that has been assigned to the respective sample.

[0034] Some embodiments of the present disclosure include methods performed by a distributed node in a distributed system, for facilitating formal verification of compliance of a security property in the distributed system, wherein a horizontal distribution of datapoints in the distributed system represent a distributed dataset, wherein a plurality of datapoints forming the distributed dataset are distributed amongst a plurality of distributed nodes in the distributed system, wherein each datapoint represents an instance to be verified as to its compliance to the security property, and wherein the distributed node has access to a local subset of the distributed dataset. These exemplary methods can include iteratively performing a number of operations, for a predetermined number of iterations N, to form a training dataset comprising a number of datapoints of the local subset, and to obtain a Machine Learning, ML, model for predicting violation of the security property. These exemplary methods can also include forming a modified local subset comprising the datapoints of the local subset that are absent from the training dataset. These exemplary methods can also include classifying, using the ML model, each of the datapoints of the modified local subset into one of a first subset and a second subset, wherein the first subset includes datapoints that are predicted as having violating characteristics with respect to the security property, and the second subset includes datapoints that are predicted as having non-violating characteristics with respect to the security property. These exemplary methods can also include formally verifying whether each datapoint in the first subset violates the security property. These exemplary methods can also include generating a list of datapoints in the first subset that violate the security property.

[0035] Some embodiments of the present disclosure include methods performed by a distributed node in a distributed system, for facilitating formal verification of compliance of a security property in the distributed system, wherein a vertical distribution of datapoints in the distributed system represent a distributed dataset, wherein a plurality of datapoints forming the distributed dataset are distributed amongst a plurality of distributed nodes in the distributed system, wherein each datapoint represents an instance to be verified as to its compliance to the security property, and wherein the distributed node has access to a local subset of the distributed dataset These exemplary methods can include iteratively performing a number of operations, for a predetermined number of iterations N, to form a training dataset comprising a number of datapoints of the local subset, and to obtain a Machine Learning, ML, model for predicting violation of the security property. These exemplary methods can also include forming a modified local subset comprising the datapoints of the local subset that are absent from the training dataset. These exemplary methods can also include classifying, using the ML model, each of the datapoints of the modified local subset into one of a first subset and a second subset, wherein the first subset includes datapoints that are predicted as having violating characteristics with respect to the security property, and the second subset includes datapoints that are predicted as having non-violating characteristics with respect to the security property. These exemplary methods can also include transmitting the first subset to a central node in the distributed system, wherein the central node is configured to formally verify whether each datapoint in the first subset violates the security property and to generate a list of datapoints in the first subset that violate the security property.

[0036] Other embodiments include distributed nodes and central nodes that are configured to perform the operations corresponding to any of the exemplary methods described herein. Other embodiments also include a computer program product comprising a computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform any of the exemplary methods described herein.

[0037] Certain embodiments may provide one or more of the following technical advantage(s).

[0038] There are, proposed herein, various embodiments which address one or more of the issues disclosed herein.

[0039] The techniques disclosed herein enable runtime formal verification in a distributed system while improving the time to identify violations. The techniques disclosed herein also minimize (in the case of the vertical scenario) and avoid (in the case of the horizontal scenario) data sharing between applications and a central location. The techniques disclosed herein also combine the practicality of ML with the mathematical rigorous proof of formal methods to enable compliance auditing and verification at runtime in distributed systems. The techniques disclosed herein also leverage two types of FL (horizontal and vertical) to address the data mobility issues in formal verification of security policies where audit data records are distributed among different participating applications and cannot be shared totally or partially between applications or with a central location.

[0040] Brief Description of the Drawings

[0041] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings, in which:

[0042] Fig. 1 shows an example of horizontally distributed audit data and vertically distributed audit data;

[0043] Fig. 2 shows an overview of an FLFM system architecture according to embodiments of the disclosure;

[0044] Fig. 3 shows a possible implementation in 5G Core where the FLFM server coordinates horizontal / vertical FLFM clients;

[0045] Fig. 4 shows a flow chart with steps performed by the FLFM coordinator at the FLFM server side for both Horizontal and Vertical Scenarios, according to embodiments of the present disclosure;

[0046] Fig. 5 shows a flow chart with steps performed by the FLFM coordinator at the FLFM client side for the Horizontal Scenario, according to an embodiment of the present disclosure;

[0047] Fig. 6 shows a flow chart with steps performed by the FLFM coordinator at the FLFM client side for the Vertical Scenario, according to an embodiment of the present disclosure;

[0048] Fig. 7 shows a node according to some embodiments.

[0049] Fig. 8 is a flow chart illustrating a method in accordance with some embodiments;

[0050] Fig. 9 is a flow chart illustrating a method in accordance with some embodiments;

[0051] Fig. 10 is a flow chart illustrating a method in accordance with some embodiments

[0052] Fig. 11 is a flow chart illustrating a method in accordance with some embodiments;

[0053] Figs. 12 to 25 are reproduced from a first article text as discussed in further detail below; and

[0054] Figs. 26 to 40 are reproduced from a second article text as discussed in further detail below.

[0055] DETAILED DESCRIPTION

[0056] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art. Additional information may also be found in the “Additional Information” section at the end of the Detailed Description .

[0057] Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and / or is implied from the context in which it is used. All references to a / an / the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and / or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following description.

[0058] The following sets forth specific details, such as particular embodiments or examples for purposes of explanation and not limitation. It will be appreciated by one skilled in the art that other examples may be employed apart from these specific details. In some instances, detailed descriptions of well-known methods, nodes, interfaces, circuits, and devices are omitted so as not obscure the description with unnecessary detail. Those skilled in the art will appreciate that the functions described may be implemented in one or more nodes using hardware circuitry (e.g., analog and / or discrete logic gates interconnected to perform a specialized function, ASICs, PLAs, etc.) and / or using software programs and data in conjunction with one or more digital microprocessors or general purpose computers. Nodes that communicate using the air interface also have suitable radio communications circuitry. Moreover, where appropriate the technology can additionally be considered to be embodied entirely within any form of computer-readable memory, such as solid-state memory, magnetic disk, or optical disk containing an appropriate set of computer instructions that would cause a processor to carry out the techniques described herein.

[0059] Hardware implementation may include or encompass, without limitation, digital signal processor (DSP) hardware, a reduced instruction set processor, hardware (e.g., digital or analogue) circuitry including but not limited to application specific integrated circuit(s) (ASIC) and / or field programmable gate array(s) (FPGA(s)), and (where appropriate) state machines capable of performing such functions.

[0060] There is proposed herein a technique that combines federated Machine Learning and formal methods for fast verification and identification of records that violate security policy in a distributed system. An example system architecture for implementing this solution is now described.

[0061] FLFM Architecture

[0062] Figure 2 is an overview of an FLFM system architecture according to embodiments of the disclosure. Figure 2 shows a detailed overview of the FLFM solution architecture (also referred to herein as a distributed system) according to embodiments of the disclosure. It is composed of two principal components: (1) a FLFM server, which is deployed as one instance to serve several FLFM clients (2) several (at least two) FLFM clients deployed each in a given administrative domain or at a single application location. Each component of the architecture is now described. Further detail regarding a FLFM Server (also referred to herein as a central node) and a FLFM client (also referred to herein as a distributed node) according to embodiments of the disclosure is set out with respect to Figure 7.

[0063] FLFM Server

[0064] The FLFM server comprises the following components, the components not represented by dashed boxes are common to both the horizontal and vertical cases. As an initial input, the FLFM Server receives configuration inputs such as, the security policies to be verified and the configuration of which formal verifier tool to be used for each property, the description of data to be used at the application side for each security property. The FLFM Server also receives initialization parameters required fortraining ML model(s), such as the size of data used in training and the number of iterations required for the training process (local and federated).

[0065] Common Components

[0066] FLFM Coordinator: The FLFM Coordinator communicates with its counterpart in an FLFM client to coordinate the Federated ML training. It is accountable for triggering either a Horizontal or Vertical FLFM approach based on the outcome of the security policy manager. Additionally, it manages and orchestrates the interactions among other system modules, specifically for conducting data processing, data sampling, formal verification, ML training, and ML application.

[0067] Security Policy Manager: The Security Policy Manager takes as an input the security properties to be verified, and identifies the appropriate scenario (horizontal or vertical) to handle the verification based on the audit property and data distribution.

[0068] Aggregator: The Aggregator aggregates different learning parameters received from FLFM clients.

[0069] The Vertical FLFM Components are now described. These components are utilized in the vertical case.

[0070] Formal Verifier: The Formal Verifier may be responsible for performing the actual verification of the audited properties. It can utilize formal methods to formally verify that the system model complies with the audited properties, which facilitates automated reasoning and provides evidence of security violations, if any. Once a sample of records is verified, each record is labeled in order to indicate whether it violates or not the security property based on its verification result.

[0071] Compliance Reports Generator: This component generates compliance reports based on the audited security policies and the result of the formal verification.

[0072] FLFM Client

[0073] The FLFM client comprises the following components, the components not represented by dashed boxes are common to both the horizontal and vertical cases.

[0074] Common Components Data Collection and Processing: This module collects local audit data from the application where the FLFM client is deployed and preprocesses it into appropriate formats for both formal verification and ML.

[0075] ML updates: This module updates the ML model based on received parameters from the FLFM server.

[0076] ML Deployment: This module performs inference based on the final learned ML model on the remaining data. This module may be responsible for leveraging the ML model to classify the remaining data in the local audit dataset (that is, the data that was not included in the training dataset) into two classes: “to be verified” class and “not to be verified” class. In the vertical case, the FLFM client may then provide the classified data to the FLFM server.

[0077] FLFM Coordinator: This module communicates with its counterpart in the FLFM server to coordinate the Federated ML training. It also triggers different modules in the client and performs the checking of the looping condition. For example, based on some pre-defined condition (for example, that the model does not show a considerable improvement in comparison to a previous iteration of the model) or upon the loop having been executed for a fixed number of iterations, this module may terminate the ML training stage.

[0078] Sampler: This module may employ active learning sampling techniques to draw informative and representative data from the local audit data, to train a model with good accuracy faster and with minimal data.

[0079] The Horizontal FLFM Components are now described. These components are utilized in the horizontal case.

[0080] Local ML training: This module trains a local ML model at the FLFM client side. This module may be responsible for training the ML model based on a subset of the local audit dataset available at the FLFM client.

[0081] Federated ML training: This module performs federated training of the ML model using a horizontal approach at the FLFM client side.

[0082] The Formal Verifier and the Compliance Reports Generator modules correspond to the Formal Verifier and the Compliance Reports Generator modules in the FLFM Server (vertical scenario).

[0083] The Vertical FLFM Components are now described. These components are utilized in the vertical case.

[0084] Federated ML training: This module performs federated training of the ML model using a vertical approach at the FLFM client side.

[0085] Figure 3 shows a possible deployment of a FLFM Server and a number of FLFM clients in 5G Core, according to embodiments of the present disclosure. In this example, the FLFM server (as separate NF or as a sidecar close to NWDAF server) coordinates horizontal / vertical FLFM clients ](close to the NF as sidecars / NWDAF clients).

[0086] Fig. 8 is a flow chart illustrating a method according to various embodiments performed by a distributed node. The distributed node may perform the method in response to executing suitably formulated computer readable code. The computer readable code may be embodied or stored on a computer readable medium, such as a memory chip, optical disc, or other storage medium. The computer readable medium may be part of a computer program product.

[0087] Fig. 8 depicts a method in accordance with particular embodiments. The method 800 may be performed by a distributed node (e.g. the node 700).

[0088] The steps provide a method by which a distributed node can facilitate fast verification and identification of records that violate security policy in a distributed system.

[0089] In some respects, the method 800 corresponds to the set of embodiments numbered 24 to 32, the set of embodiments numbered 1 to 12 , and / or the methods described below with respect to Figures 5 and / or 6. The description of method 800 should also be read in conjunction with the method 900, which set out complementary steps performed by the central node.

[0090] The method begins at step 802 with determining whether a distributed dataset represents a horizontal distribution of datapoints in the distributed system or a vertical distribution of datapoints in the distributed system. A plurality of datapoints forming the distributed dataset are distributed amongst a plurality of distributed nodes in the distributed system, wherein each datapoint represents an instance to be verified as to its compliance to the security property. The distributed node has access to a local subset of the distributed dataset.

[0091] Where the distributed dataset represents a horizontal distribution of datapoints (the horizontal case, or horizontal scenario), each distributed node has access to the same features (or attributes) in the data, but different data records. Where the distributed dataset represents a vertical distribution of datapoints (the vertical case, or vertical scenario), each distributed node has access to the same data records, but different features (or attributes) in the data.

[0092] In some embodiments, determining whether the distributed dataset represents a horizontal distribution of datapoints in the distributed system, or a vertical distribution of datapoints in the distributed system comprises receiving, from the central node, an identifier indicating whether the distributed dataset represents a horizontal distribution or a vertical distribution.

[0093] In step 804, the distributed node iteratively performs a number of operations, for a predetermined number of iterations N, to form a training dataset comprising a number of datapoints of the local subset, and to obtain a Machine Learning, ML, model for predicting violation of the security property. The iterative process of forming the training dataset aims to improve the ML model obtained each iteration by adding more representative instances to the training dataset.

[0094] In some embodiments, prior to iteratively performing the number of operations, the method 800 further comprises, selecting, at the distributed node, an initial training set of datapoints, or receiving, from the central node, an initial training set of datapoints, and training the ML model using the initial training set of datapoints. In some embodiments, the initial training set of datapoints comprises a first datapoint and second datapoint, the first datapoint representing an instance which violates the security property, and the second datapoint representing an instance which does not violate the security property. In some embodiments, the first datapoint is assigned a positive verification tag, and wherein the second datapoint is assigned a negative verification tag.

[0095] In step 806, the distributed node forms a modified local subset comprising the datapoints of the local subset that are absent from the training dataset.

[0096] In step 808, the distributed node classifies, using the ML model, each of the datapoints of the modified local subset into one of a first subset and a second subset, wherein the first subset includes datapoints that are predicted as having violating characteristics with respect to the security property, and the second subset includes datapoints that are predicted as having nonviolating characteristics with respect to the security property.

[0097] In step 810, the distributed node, responsive to determining that the distributed dataset represents a horizontal distribution of datapoints: formally verifies whether each datapoint in the first subset violates the security property, and generates a list of datapoints in the first subset that violate the security property; or, responsive to determining that the distributed dataset represents a vertical distribution of datapoints, the distributed node transmits the first subset to a central node in the distributed system, wherein the central node is configured to formally verify whether each datapoint in the first subset violates the security property and to generate a list of datapoints in the first subset that violate the security property.

[0098] In some embodiments, in response to determining that the distributed dataset represents a horizontal distribution of datapoints, the method 800 further comprises formally verifying whether each datapoint in the second subset violates the security property, and generating a list of datapoints in the second subset that violate the security property.

[0099] In some embodiments, in response to determining that the distributed dataset represents a vertical distribution of datapoints, the method further comprises transmitting the second subset to the central node, wherein the central node is further configured to formally verify whether each datapoint in the second subset violates the security property and to generate a list of datapoints in the second subset that violate the security property. The method 800 therefore decomposes the local audit records at the distributed node into two subsets: one subset containing most of the records potentially violating the security policy and another subset containing most of the records potentially non-violating the policy. The subset (first subset) containing the violations is the verified first, and the other subset (second subset) can be either discarded or verified with a lower priority than the first one.

[0100] In some embodiments, in response to the determining that the distributed dataset represents a horizontal distribution of datapoints, the number of operations comprise: selecting a predetermined number M of samples from the local subset; formally verifying whether each of the selected samples violate the security property; assigning a positive verification tag or a negative verification tag to each of the selected samples, wherein the positive verification tag indicates that the respective instance represented by the respective sample violates the security property, and the negative verification tag indicates that the respective instance represented by the by the respective sample does not violate the security property; classifying each of the selected samples as a positive instance or a negative instance, using the ML model; identifying, from the selected samples, a subset of samples by comparing the respective assigned verification tag and the respective classification for each selected sample, wherein the subset of samples includes any samples that are incorrectly classified as negative instances, and any samples that are incorrectly classified as positive instances; and updating the training dataset by adding the identified subset of samples in the current iteration to the training dataset.

[0101] In some embodiments, the method 800 further comprises training the ML model using the updated training dataset; obtaining one or more learning parameters of the ML model; and determining whether to repeat the number of operations for a further N iterations, based on the one or more learning parameters.

[0102] In some embodiments, the method further comprises performing iteratively the following steps for a predetermined number of iterations P: sending one or more learning parameters of the ML model to the central node; receiving one or more aggregated learning parameters from the central node; and updating the ML Model using the received aggregated learning parameters to obtain a global ML model.

[0103] In some embodiments, in response to determining that the distributed dataset represents a vertical distribution of datapoints, the number of operations comprise: selecting a sample from the local subset; sending, to the central node, the sample; receiving, from the central node, the sample with an assigned positive verification tag or negative verification tag, wherein the positive verification tag indicates that the instance represented by the sample violates the security property, and the negative verification tag indicates that the instance represented by the by the sample does not violate the security property; updating the training dataset by adding the sample with its assigned verification tag to the training dataset; training the ML model using the updated training dataset; sending one or more learning parameters of the ML model to the central node; receiving one or more aggregated learning parameters from the central node; and updating the ML Model using the received aggregated learning parameters to obtain a global ML model.

[0104] In some embodiments, the method further comprises, in response to the determining that the distributed dataset represents a horizontal distribution of datapoints, generating a compliance report comprising the list of instances that violate the security property.

[0105] The numbered embodiments 24-32 below set out further detail of a distributed node according to embodiments of the disclosure, which should be read in conjunction with the flowchart shown in Figure 8.

[0106] Fig. 9 is a flow chart illustrating a method according to various embodiments performed by a central node. The central node may perform the method in response to executing suitably formulated computer readable code. The computer readable code may be embodied or stored on a computer readable medium, such as a memory chip, optical disc, or other storage medium. The computer readable medium may be part of a computer program product.

[0107] Fig. 9 depicts a method in accordance with particular embodiments. The method 900 may be performed by a central node (e.g. the node 700).

[0108] The steps provide a method by which a central node can facilitate fast verification and identification of records that violate security policy in a distributed system.

[0109] In some respects, the method 900 corresponds to the set of embodiments numbered 33 to 35, the set of embodiments numbered 13 to 16 , and / or the methods described below with respect to Figure 4. The description of method 900 should also be read in conjunction with the method 800, which sets out complementary steps performed by the distributed node.

[0110] The method begins at step 902 with receiving, from each distributed node, a sample from a respective local subset available at the distributed node, wherein a plurality of datapoints forming a distributed dataset are distributed amongst a plurality of distributed nodes in the distributed system, wherein each datapoint represents an instance to be verified as to its compliance to the security property, and wherein each distributed node has access to a respective local subset of the distributed dataset, and wherein the distributed dataset represents a vertical distribution of datapoints in the distributed system.

[0111] At step 904, the central node merges the received samples.

[0112] At step 906, the central node formally verifies whether each of the received samples violates the security property.

[0113] At step 908, the central node assigns a positive verification tag or a negative verification tag to each of the received samples, wherein the positive verification tag indicates that the respective instance represented by the respective sample violates the security property, and the negative verification tag indicates that the respective instance represented by the by the respective sample does not violate the security property.

[0114] At step 910, the central node transmits, to each distributed node, the respective sample received from the distributed node and the verification tag that has been assigned to the respective sample.

[0115] In some embodiments, the method further comprises receiving, from each distributed node, a respective first subset including datapoints of the local subset available at distributed node that are predicted as having violating characteristics with respect to the security property; merging the received datapoints; formally verifying whether each received datapoint violates the security property; and generating a list of datapoints that violate the security property.

[0116] In some embodiments, the method further comprises receiving, from each distributed node, a respective second subset including datapoints of the local subset available at distributed node that are predicted as having non-violating characteristics with respect to the security property; merging the received datapoints; formally verifying whether each received datapoint violates the security property; and generating a list of datapoints that violate the security property.

[0117] In some embodiments, the method further comprises determining whether the distributed dataset represents a horizontal distribution of datapoints in the distributed system, or a vertical distribution of datapoints in the distributed system; and transmitting, to at least one distributed node, an identifier indicating whether the distributed dataset represents a horizontal distribution or a vertical distribution.

[0118] The numbered embodiments 33-35 below set out further detail of a central node according to embodiments of the disclosure, which should be read in conjunction with the flowchart shown in Figure 9.

[0119] Fig. 10 is a flow chart illustrating a method according to various embodiments performed by a distributed node, wherein a horizontal distribution of datapoints in the distributed system represent a distributed dataset, wherein a plurality of datapoints forming the distributed dataset are distributed amongst a plurality of distributed nodes in the distributed system, wherein each datapoint represents an instance to be verified as to its compliance to the security property, and wherein the distributed node has access to a local subset of the distributed dataset. Where the distributed dataset represents a horizontal distribution of datapoints (the horizontal case, or horizontal scenario), each distributed node has access to the same features (or attributes) in the data, but different data records. The method may be performed by the distributed node as a result of receiving, from a central node, an identifier indicating that the distributed dataset represents a horizontal distribution.

[0120] The distributed node may perform the method in response to executing suitably formulated computer readable code. The computer readable code may be embodied or stored on a computer readable medium, such as a memory chip, optical disc, or other storage medium. The computer readable medium may be part of a computer program product.

[0121] Fig. 10 depicts a method in accordance with particular embodiments. The method 1000 may be performed by a distributed node (e.g. the node 700).

[0122] The steps provide a method by which a distributed node can facilitate fast verification and identification of records that violate security policy in a distributed system.

[0123] In some respects, the method 1000 corresponds the methods described below with respect to Figure 5. The description of method 1000 should also be read in conjunction with the method 900, which set out complementary steps performed by the central node.

[0124] In step 1002, the distributed node iteratively performs a number of operations, for a predetermined number of iterations N, to form a training dataset comprising a number of datapoints of the local subset, and to obtain a Machine Learning, ML, model for predicting violation of the security property. The iterative process of forming the training dataset aims to improve the ML model obtained each iteration by adding more representative instances to the training dataset.

[0125] In some embodiments, prior to iteratively performing the number of operations, the method 1000 further comprises, selecting, at the distributed node, an initial training set of datapoints, or receiving, from the central node, an initial training set of datapoints, and training the ML model using the initial training set of datapoints. In some embodiments, the initial training set of datapoints comprises a first datapoint and second datapoint, the first datapoint representing an instance which violates the security property, and the second datapoint representing an instance which does not violate the security property. In some embodiments, the first datapoint is assigned a positive verification tag, and wherein the second datapoint is assigned a negative verification tag.

[0126] In step 1004, the distributed node forms a modified local subset comprising the datapoints of the local subset that are absent from the training dataset.

[0127] In step 1006, the distributed node classifies, using the ML model, each of the datapoints of the modified local subset into one of a first subset and a second subset, wherein the first subset includes datapoints that are predicted as having violating characteristics with respect to the security property, and the second subset includes datapoints that are predicted as having nonviolating characteristics with respect to the security property.

[0128] In step 1008, the distributed node formally verifies whether each datapoint in the first subset violates the security property.

[0129] In step 1010, the distributed node generates a list of datapoints in the first subset that violate the security property.

[0130] In some embodiments, the method 1000 further comprises formally verifying whether each datapoint in the second subset violates the security property, and generating a list of datapoints in the second subset that violate the security property.

[0131] The method 1000 therefore decomposes the local audit records at the distributed node into two subsets: one subset containing most of the records potentially violating the security policy and another subset containing most of the records potentially non-violating the policy. The subset (first subset) containing the violations is the verified first, and the other subset (second subset) can be either discarded or verified with a lower priority than the first one.

[0132] In some embodiments, the number of operations comprise: selecting a predetermined number M of samples from the local subset; formally verifying whether each of the selected samples violate the security property; assigning a positive verification tag or a negative verification tag to each of the selected samples, wherein the positive verification tag indicates that the respective instance represented by the respective sample violates the security property, and the negative verification tag indicates that the respective instance represented by the by the respective sample does not violate the security property; classifying each of the selected samples as a positive instance or a negative instance, using the ML model; identifying, from the selected samples, a subset of samples by comparing the respective assigned verification tag and the respective classification for each selected sample, wherein the subset of samples includes any samples that are incorrectly classified as negative instances, and any samples that are incorrectly classified as positive instances; and updating the training dataset by adding the identified subset of samples in the current iteration to the training dataset.

[0133] In some embodiments, the method 1100 further comprises training the ML model using the updated training dataset; obtaining one or more learning parameters of the ML model; and determining whether to repeat the number of operations for a further N iterations, based on the one or more learning parameters.

[0134] In some embodiments, the method further comprises performing iteratively the following steps for a predetermined number of iterations P: sending one or more learning parameters of the ML model to the central node; receiving one or more aggregated learning parameters from the central node; and updating the ML Model using the received aggregated learning parameters to obtain a global ML model.

[0135] In some embodiments, the method further comprises, generating a compliance report comprising the list of instances that violate the security property.

[0136] Fig. 11 is a flow chart illustrating a method according to various embodiments performed by a distributed node, wherein a vertical distribution of datapoints in the distributed system represent a distributed dataset, wherein a plurality of datapoints forming the distributed dataset are distributed amongst a plurality of distributed nodes in the distributed system, wherein each datapoint represents an instance to be verified as to its compliance to the security property, and wherein the distributed node has access to a local subset of the distributed dataset. Where the distributed dataset represents a vertical distribution of datapoints (the vertical case, or vertical scenario), each distributed node has access to the same data records, but different features (or attributes) in the data. The method may be performed by the distributed node as a result of receiving, from a central node, an identifier indicating that the distributed dataset represents a vertical distribution.

[0137] The distributed node may perform the method in response to executing suitably formulated computer readable code. The computer readable code may be embodied or stored on a computer readable medium, such as a memory chip, optical disc, or other storage medium. The computer readable medium may be part of a computer program product.

[0138] Fig. 11 depicts a method in accordance with particular embodiments. The method 1100 may be performed by a distributed node (e.g. the node 700).

[0139] The steps provide a method by which a distributed node can facilitate fast verification and identification of records that violate security policy in a distributed system.

[0140] In some respects, the method 1100 corresponds to the methods described below with respect to Figure 6. The description of method 1100 should also be read in conjunction with the method 900, which set out complementary steps performed by the central node.

[0141] In step 1102, the distributed node iteratively performs a number of operations, for a predetermined number of iterations N, to form a training dataset comprising a number of datapoints of the local subset, and to obtain a Machine Learning, ML, model for predicting violation of the security property. The iterative process of forming the training dataset aims to improve the ML model obtained each iteration by adding more representative instances to the training dataset.

[0142] In some embodiments, prior to iteratively performing the number of operations, the method 1100 further comprises, selecting, at the distributed node, an initial training set of datapoints, or receiving, from the central node, an initial training set of datapoints, and training the ML model using the initial training set of datapoints. In some embodiments, the initial training set of datapoints comprises a first datapoint and second datapoint, the first datapoint representing an instance which violates the security property, and the second datapoint representing an instance which does not violate the security property. In some embodiments, the first datapoint is assigned a positive verification tag, and wherein the second datapoint is assigned a negative verification tag.

[0143] In step 1104, the distributed node forms a modified local subset comprising the datapoints of the local subset that are absent from the training dataset.

[0144] In step 1106, the distributed node classifies, using the ML model, each of the datapoints of the modified local subset into one of a first subset and a second subset, wherein the first subset includes datapoints that are predicted as having violating characteristics with respect to the security property, and the second subset includes datapoints that are predicted as having nonviolating characteristics with respect to the security property.

[0145] In step 1108, the distributed node transmits the first subset to a central node in the distributed system, wherein the central node is configured to formally verify whether each datapoint in the first subset violates the security property and to generate a list of datapoints in the first subset that violate the security property.

[0146] In some embodiments, the method further comprises transmitting the second subset to the central node, wherein the central node is further configured to formally verify whether each datapoint in the second subset violates the security property and to generate a list of datapoints in the second subset that violate the security property.

[0147] The method 1100 therefore decomposes the local audit records at the distributed node into two subsets: one subset containing most of the records potentially violating the security policy and another subset containing most of the records potentially non-violating the policy. The subset (first subset) containing the violations is the verified first, and the other subset (second subset) can be either discarded or verified with a lower priority than the first one.

[0148] In some embodiments, the number of operations comprise: selecting a sample from the local subset; sending, to the central node, the sample; receiving, from the central node, the sample with an assigned positive verification tag or negative verification tag, wherein the positive verification tag indicates that the instance represented by the sample violates the security property, and the negative verification tag indicates that the instance represented by the by the sample does not violate the security property; updating the training dataset by adding the sample with its assigned verification tag to the training dataset; training the ML model using the updated training dataset; sending one or more learning parameters of the ML model to the central node; receiving one or more aggregated learning parameters from the central node; and updating the ML Model using the received aggregated learning parameters to obtain a global ML model.

[0149] The following section includes a number of flow charts illustrating operation of various entities in the FLFM architecture, according to the methods described above.

[0150] Figure 4 shows a flow chart with steps performed by the FLFM coordinator at the (FLFM) server side, for both Horizontal and Vertical Scenarios, according to embodiments of the present disclosure. The steps are as follows:

[0151] • Step 1 : The FLFM coordinator at the server begins by collecting input and configuring the server and the participating clients with initial input from admins. It also performs initialization and configuration of different parameters in the server and the clients.

[0152] • Step 2: The FLFM coordinator at the server triggers the Security Policy Manger to identify the scenario (horizonal data distribution or vertical data distribution) to determine for each security policy verification whether the data distribution is either horizontal or vertical.

[0153] • Step 3: The FLFM coordinator at the server sends to participating FLFM clients for each security policy verification an identifier tag (horizontal or vertical) determined in the previous step, to start the verification of the security policies. This verification can be programmed to be restarted periodically (either at the end of a verification cycle or after a time interval). In the case of horizontal distribution, Steps 4.H are triggered, otherwise Steps 4.V are used.

[0154] • Steps 4. H: o Step 4.H1 : the FLFM server coordinator at the server receives learning parameters for local ML models from all FLFM clients. Once all the parameters from all clients are received for this round, the next step is triggered. o Step 4.H2: the FLFM server coordinator at the server triggers the Aggregator, which aggregates all received learning parameters. o Step 4.H3: the FLFM server coordinator sends the aggregated learning parameters obtained from the previous step to the participating FLFM clients. o At the end of the latter step, a condition is checked to determine whether a new iteration should be performed. If the iterations must stop (condition = no), the FLFM server coordinator iterates on Step 3 (to trigger other verification), otherwise (condition = yes), a second round of the horizontal scenario is performed (by restarting Step 4.H1).

[0155] • Steps 4.V: o Step 4.V1 : the FLFM server coordinator sends a sample of audit data with associated verification tags (previously obtained from a formal verification of these samples), which will constitute an initial training dataset, to each FLFM client. o Step 4.V2: (similar to Step 4.H1) the FLFM server coordinator receives the learning parameters from all FLFM clients for this round, then the next step is triggered. o Step 4.V3: (similar to Step 4.H2) the FLFM coordinator triggers the Aggregator who will aggregate all received learning parameters from all clients. o Step 4.V4: (similar to Step 4.H3) the FLFM server coordinator sends the aggregated learning parameters received from previous step to the participating FLFM clients. o At the end of the previous step, a condition is checked to determine whether a new iteration should be performed. If iterations must stop (condition = no), the FLFM server coordinator triggers Step 4.V9. Otherwise (condition = yes), Step4.V5 is triggered. o If the condition indicates that another iteration should be executed (condition = yes), then the following steps are executed:

[0156] □ Step 4.V5: the FLFM Server coordinator receives samples from all FLFM clients. Once all samples are received from all clients, the next step Step4.V6 is triggered.

[0157] □ Step4.V6: the FLFM Server coordinator merges the received samples from the previous step to build a complete instance. Note that as this is the case where data is distributed vertically, we need to merge the data for the same data record (identified with same id) before being able to perform formal verification. Then the merged sample is transformed into the input language of the formal verifier

[0158] □ Step 4.V7: the FLFM coordinator triggers the formal verifier to verify the policy on the merged samples and associate a verification tag to the records as either “to be verified” or “not to be verified”. Note that those records are already formally verified and will not be reverified at the end as they will be removed from the distributed audit dataset, to keep only the remaining dataset.

[0159] □ Step 4.V8: the FLFM coordinator divides the merged samples vertically and sends them with their verification tags to the corresponding FLFM clients. At the end of this step, Step 4V.2 is triggered again. o If the condition is to discontinue iteration (condition = no), then the following steps are executed:

[0160] □ Step 4.V9: The FLFM coordinator receives the data records that need to be verified.

[0161] □ Step 4V.10: The FLFM coordinator merges the received samples and transforms them into the input language formal verifier.

[0162] □ Step 4V.11 The FLFM coordinator triggers the formal verifier for the data from the previous step and associates verification tags to each datapoint. The violating instances are assigned a positive verification tag, and the non-violating instances are assigned a negative verification tag.

[0163] □ Step 4.V12: The compliance report generator is triggered to produce compliance reports about the verified policy and the compliance of all records. A compliance report may include a list of instances that violate the security property. Then, Step 2 is triggered for the verification of another policy or the same policy again.

[0164] □ Optionally the compliance report can be shared with the distributed FLFM clients.

[0165] Figure 5 shows a flow chart with steps performed by the FLFM coordinator at the (FLFM) client side for the horizontal case, according to an embodiment of the present disclosure. The steps are as follows:

[0166] • Step 1 : The FLFM coordinator at the client side receives an identifier tag from the central server. If the horizonal tag is specified, the FLFM client coordinator starts Step 2 related to the Horizontal FLFM.

[0167] • Step 2: the Learner trains an ML model using an initial training dataset with minimal datapoints. The initial training dataset may comprise a first datapoint representing an instance which violates the security property associated with verification tag of “to be verified”, and a second datapoint representing an instance which does not violate the security property associated with verification tag of “not to be verified”. The ML model may learn the characteristics of the audit data and classify them accordingly into two subsets: “to be verified” subset and “not to be verified” subset.

[0168] • Step 3: This step starts an iterative process where firstly, the Sampler selects a small number of representative sample instances from the local audit data. The iterative process aims to improve the ML model each iteration by adding more representative instances to the training data.

[0169] • Step 4: The FLFM client coordinator transforms the sample instances obtained in step 3 into the input language of the formal verifier tool.

[0170] • Step 5: The Formal verifier at the client side verifies each of the transformed sample instances and finds out whether it is a violating instance or a non-violating instance with regard to the audit property. The Formal Verifier obtains a verification tag for each instance, wherein the violating instances are assigned a positive verification tag, and the non-violating instances are assigned a negative verification tag.

[0171] • Step 6: The ML deployment uses the ML model (which was either trained at step 2, or obtained in a previous iteration of step 11) and applies it on the samples obtained at step 3, to obtain a prediction / a classification for each sample instance, where each sample instance is classified as either in the “to be verified” class or in the “not to be verified” class.

[0172] • Step 7: The FLFM coordinator at the client side adds a subset of the samples obtained in step 3, where each sample within the subset is respectively associated with a verification tag (obtained at step 5) that does not correspond with the predicted class for the sample (obtained at step 6), into the training dataset, such that the training dataset from the previous iteration of steps 3-7 will be updated to include the subset of samples. Then, a condition is checked to determine whether or not to perform more sampling. If the condition is verified (condition = yes) then Step 3 is triggered to perform another round to increase the training dataset. Otherwise, Step 8 is triggered.

[0173] • Step 8: The learner then trains the ML model with the training dataset obtained from the latest iteration of Step 7, and obtains the learning parameters for this model. A condition is then checked to determine whether the more iterations should be performed to train the ML model again. If more iterations are needed, then Step 3 is triggered again. Otherwise, step 9 is triggered, ending the local training.

[0174] • Step 9: The FLFM coordinator at the client side sends the learning parameters obtained in step 8 to the FLFM server.

[0175] • StepIO: The FLFM coordinator at the client side waits to receive the aggregated learning parameters from the FLFM server. Once they are received, Step 11 is triggered.

[0176] • Step 11 : The model updater updates the ML model. Following this, a condition to start a new iteration of Horizontal learning (H) is checked. If the condition is true (condition = yes) Step 3 is triggered. Otherwise, Step 12 is triggered.

[0177] • Step 12: The ML Deployment module applies the ML model obtained in Step 11 on the remaining local audit data (which consists of local audit data without the training data), to classify the instances in the remaining local audit data.

[0178] • Step 13: The FLFM coordinator at the client side transforms all data records obtained from step 12, and extracts those classified as “to be verified”.

[0179] • Step 14: The formal verifier verifies the transformed data record from step 13 and obtains a verification tag for each data point classified as “to be verified”.

[0180] • Step 15: the Compliance Reports generator, with the results obtained from step 14, generates a compliance report. A compliance report may include a list of instances that violate the security property.

[0181] Figure 6 shows a flow chart with steps performed by the FLFM coordinator at the (FLFM) client side for the vertical case, according to an embodiment of the present disclosure. The steps are as follows: • Step 1: The FLFM coordinator at the client side receives the identifier tag from a central server. If the vertical tag is specified, the FLFM client coordinator starts Step 2 related to the Vertical FLFM.

[0182] • Step 2: The FLFM coordinator at the client side receives initial training data, TO, from the FLFM server. The initial training dataset may comprise a first datapoint representing an instance which violates the security property associated with verification tag of “to be verified”, and a second datapoint representing an instance which does not violate the security property associated with verification tag of “not to be verified.

[0183] • Step 3: The learner trains a ML model with the initial training data TO received in step 2. The ML model may learn the characteristics of the audit data and classify them accordingly into two subsets: “to be verified” subset and “not to be verified” subset.

[0184] • Step 4: The sampler selects a minimal representative sample Ti from the local audit data. This step represents the start of an iterative process. The iterative process aims to improve the ML model each iteration by adding more representative instances to the training data.

[0185] • Step 5: The FLFM coordinator at the client side sends the sample obtained in step 4 to the FLFM server.

[0186] • Step 6: The FLFM coordinator at the client side waits to receive the sent sample in Step 5 from FLFM server with its corresponding verification tag. The violating instances are assigned a positive verification tag, and the non-violating instances are assigned a negative verification tag. Once received, it adds the sample and its corresponding verification tag to the training dataset, such that the training dataset from the previous iteration of steps 4-10 will be updated to include the received sample. Step 7 is then triggered.

[0187] • Step 7: The learner at the client side uses the training dataset obtained from the latest iteration of Step 6 to train the ML model . The learner then obtains the learning parameters from this model.

[0188] • Step 8: The FLFM coordinator at the client side sends the learning parameters to the FLFM server.

[0189] • Step 9: The FLFM coordinator at the client side receives the aggregated parameters and then triggers Step 10.

[0190] • Step 10: The model updater uses the aggregated parameters from the previous step to update the ML model. Then, a condition is used to determine whether more iterations are needed for the vertical case. In the case that the answer is positive, Step 4 is triggered again to enter a new iteration, otherwise Step 11 is triggered.

[0191] • Step 11 : The ML deployment at the client side applies the obtained ML model on the remaining local audit data (which consists of local audit data without the training data), to obtain two subsets: one comprising data that has been tagged “to be verified”, and another subset data that has been tagged “not to be verified”.

[0192] • Step 11 : The FLFM coordinator at the client side sends the data records labelled “to be verified” to the FLFM server for formal verification with priority. The FLFM coordinator may then optionally send the data records labelled “not to be verified” for formal verification if required.

[0193] The embodiments described herein may be performed by nodes in a network, such as distributed nodes (or client nodes, or FLFM clients) and / or central nodes (or server nodes, or FLFM servers). The network referred to herein can be any type of network. For example, the network referred to herein may be a communications or telecommunications network. In some embodiments, the network referred to herein can be a mobile network, such as a fifth generation (5G) mobile network or any other generation mobile network. In some embodiments, the network referred to herein can be a core network (e.g. a 5G core (5GC) network) or a radio access network (RAN). In some embodiments, the network referred to herein can be a virtual network or an at least partially virtual network. Although some examples have been provided for the type of network referred to herein, it will be understood that the network referred to herein can be any other type of network. A communications network may comprise any one, or any combination of: a wired link (e.g. ASDL) or a wireless link such as Global System for Mobile Communications (GSM), Wideband Code Division Multiple Access (WCDMA), Long Term Evolution (LTE), New Radio (NR), WiFi, Bluetooth or future wireless technologies. The skilled person will appreciate that these are merely examples and that the communications network may comprise other types of links. A wireless network may be configured to operate according to specific standards or other types of predefined rules or procedures. Thus, particular embodiments of the wireless network may implement communication standards, such as Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, 5G, 6G standards, or any future standards; wireless local area network (WLAN) standards, such as the IEEE 802.11 standards; and / or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave and / or ZigBee standards.

[0194] Fig. 7 illustrates an example network node 700 in a network according to some embodiments herein. Generally, the node 700 may comprise any component or network function (e.g. any hardware or software module) in the network suitable for performing the functions described herein.

[0195] The node 700 is configured (e.g. adapted, operative, or programmed) to perform any of the embodiments of the methods 8 and 9 described above, and / or the methods shown in Figures 4, 5 and / or 6 and / or operable to communicate directly or indirectly with other nodes or equipment to enable and / or to perform the functionality described herein. It will be appreciated that the node 700 may comprise one or more virtual machines running different software and / or processes. The node 700 may therefore comprise one or more servers, switches and / or storage devices and / or may comprise cloud computing infrastructure or infrastructure configured to perform in a distributed manner, that runs the software and / or processes. In some embodiments, the node 700 referred to herein can, for example, be a physical node (e.g. a physical machine or server) or a virtual node (e.g. a virtual machine, VM).

[0196] The node 700 may comprise a processor (e.g. processing circuitry or logic) 702. The processor 702 may control the operation of the node 700 in the manner described herein. The processor 702 can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the node 700 in the manner described herein. In particular implementations, the processor 702 can comprise a plurality of software and / or hardware modules 706 that are each configured to perform, or are for performing, individual or multiple steps of the functionality of the node 700 as described herein.

[0197] The node 700 may comprise a memory 704. In some embodiments, the memory 704 of the node 700 can be configured to store program code or instructions 706 that can be executed by the processor 702 of the node 700 to perform the functionality described herein. Alternatively or in addition, the memory 704 of the node 700, can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processor 702 of the node 700 may be configured to control the memory 704 of the node 700 to store any requests, resources, information, data, signals, or similar that are described herein.

[0198] It will be appreciated that a node 700 may comprise other components in addition or alternatively to those indicated in Fig. 7. For example, in some embodiments, a node 700 may comprise a communications interface. The communications interface may be for use in communicating with other nodes in the network, (e.g. such as other physical or virtual nodes). For example, the communications interface may be configured to transmit to and / or receive from other nodes or network functions requests, resources, information, data, signals, or similar. The processor 702 of node 700 may be configured to control such a communications interface to transmit to and / or receive from other nodes or network functions requests, resources, information, data, signals, or similar.

[0199] In some embodiments, the node 700 may be a central node and / or a distributed node as described above. A central node and / or distributed node may comprise equipment capable, configured, arranged and / or operable to communicate directly or indirectly with a UE (such as a wireless device) and / or with other network nodes or equipment in the network to enable and / or provide wireless or wired access to the UE and / or to perform other functions (e.g., administration) in the network. Examples of nodes suitable to perform the methods attributed to the detector node include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs) and NR NodeBs (gNBs)). Further examples of nodes include but are not limited to core network functions such as, for example, core network functions in a Fifth Generation Core network (5GC) such as NWDAF (Network Data Analytics Function).

[0200] In some embodiments, the node 700 may comprise a central node and / or a distributed node. Central nodes and / or distributed nodes can be network functions or a side car container in the core network, which, for example, utilize NWDAF for analytics, or in the radio access network, which, for example, utilize rApp / xApp for analytics. In some embodiments, a central node and / or a distributed node may be deployed in a cloud environment (for example, across mobile edge computing sites and / or cloud data centres), where there may be data mobility concerns and / or privacy concerns about sharing data across different domains.

[0201] In some embodiments, the node functionality described herein can be performed by hardware. Thus, in some embodiments, the node 700 described herein can be a hardware entity. However, it will also be understood that optionally at least part or all of the node 700 functionality described herein can be virtualised. For example, the functions performed by the node 700 described herein can be implemented in software running on generic hardware that is configured to orchestrate the distributed node functionality and / or central node functionality described herein. Thus, in some embodiments, the node 700 described herein can be a virtual node. In some embodiments, at least part or all of the node 700 functionality described herein may be performed in a network enabled cloud. Thus, the methods described herein can be realised as a cloud implementation according to some embodiments. The node 700 functionality described herein may all be at the same location or at least some of the node 700 functionality may be distributed, e.g. the node 700 functionality may be performed by one or more different nodes.

[0202] In another embodiment, there is provided a computer program product comprising a computer readable medium, the computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform the method or methods described herein, such as the methods 8 or 9.

[0203] Thus, it will be appreciated that the disclosure also applies to computer programs, particularly computer programs on or in a carrier, adapted to put embodiments into practice. The program may be in the form of a source code, an object code, a code intermediate source and an object code such as in a partially compiled form, or in any other form suitable for use in the implementation of the method according to the embodiments described herein.

[0204] It will also be appreciated that such a program may have many different architectural designs. For example, a program code implementing the functionality of the method or system may be sub-divided into one or more sub-routines. Many different ways of distributing the functionality among these sub-routines will be apparent to the skilled person. The sub-routines may be stored together in one executable file to form a self-contained program. Such an executable file may comprise computer-executable instructions, for example, processor instructions and / or interpreter instructions (e.g. Java interpreter instructions). Alternatively, one or more or all of the sub-routines may be stored in at least one external library file and linked with a main program either statically or dynamically, e.g. at run-time. The main program contains at least one call to at least one of the sub-routines. The sub-routines may also comprise function calls to each other.

[0205] The carrier of a computer program may be any entity or device capable of carrying the program. For example, the carrier may include a data storage, such as a ROM, for example, a CD ROM or a semiconductor ROM, or a magnetic recording medium, for example, a hard disk. Furthermore, the carrier may be a transmissible carrier such as an electric or optical signal, which may be conveyed via electric or optical cable or by radio or other means. When the program is embodied in such a signal, the carrier may be constituted by such a cable or other device or means. Alternatively, the carrier may be an integrated circuit in which the program is embedded, the integrated circuit being adapted to perform, or used in the performance of, the relevant method.

[0206] Although the computing devices described herein (e.g. UEs, network nodes) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and / or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and / or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

[0207] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device- readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer-readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally.

[0208] The foregoing merely illustrates the principles of the disclosure. Various modifications and alterations to the described embodiments will be apparent to those skilled in the art in view of the teachings herein. It will thus be appreciated that those skilled in the art will be able to devise numerous systems, arrangements, and procedures that, although not explicitly shown or described herein, embody the principles of the disclosure and can be thus within the scope of the disclosure. Various exemplary embodiments can be used together with one another, as well as interchangeably therewith, as should be understood by those having ordinary skill in the art.

[0209] The following are certain enumerated embodiments further illustrating various aspects the disclosed subject matter.

[0210] 1. A method performed by a distributed node in a distributed system, for facilitating formal verification of compliance of a security property in the distributed system, the method comprising: determining whether a distributed dataset represents a horizontal distribution of datapoints in the distributed system or a vertical distribution of datapoints in the distributed system, wherein a plurality of datapoints forming a distributed dataset are distributed amongst a plurality of distributed nodes in the distributed system, wherein each datapoint represents an instance to be verified as to its compliance to the security property, and wherein the distributed node has access to a local subset of the distributed dataset; iteratively performing a number of operations, for a predetermined number of iterations N, to form a training dataset comprising a number of datapoints of the local subset, and to obtain a Machine Learning, ML, model for predicting violation of the security property; forming a modified local subset comprising the datapoints of the local subset that are absent from the training dataset; classifying, using the ML model, each of the datapoints of the modified local subset into one of a first subset and a second subset, wherein the first subset includes datapoints that are predicted as having violating characteristics with respect to the security property, and the second subset includes datapoints that are predicted as having non-violating characteristics with respect to the security property; and responsive to determining that the distributed dataset represents a horizontal distribution of datapoints: formally verifying whether each datapoint in the first subset violates the security property, and generating a list of datapoints in the first subset that violate the security property; or responsive to determining that the distributed dataset represents a vertical distribution of datapoints, transmitting the first subset to a central node in the distributed system, wherein the central node is configured to formally verify whether each datapoint in the first subset violates the security property and to generate a list of datapoints in the first subset that violate the security property.

[0211] 2. The method of embodiment 1 , wherein, prior to iteratively performing the number of operations, the method further comprises: selecting, at the distributed node, an initial training set of datapoints, or receiving, from the central node, an initial training set of datapoints; and training the ML model using the initial training set of datapoints.

[0212] 3. The method of embodiment 1 or 2, wherein, in response to determining that the distributed dataset represents a horizontal distribution of datapoints, the method further comprises: formally verifying whether each datapoint in the second subset violates the security property, and generating a list of datapoints in the second subset that violate the security property.

[0213] 4. The method of embodiment 1 or 2, wherein, in response to determining that the distributed dataset represents a vertical distribution of datapoints, the method further comprises: transmitting the second subset to the central node, wherein the central node is further configured to formally verify whether each datapoint in the second subset violates the security property and to generate a list of datapoints in the second subset that violate the security property.

[0214] 5. The method of any of embodiments 1-3, wherein, in response to the determining that the distributed dataset represents a horizontal distribution of datapoints, the number of operations comprise: selecting a predetermined number M of samples from the local subset; formally verifying whether each of the selected samples violate the security property; assigning a positive verification tag or a negative verification tag to each of the selected samples, wherein the positive verification tag indicates that the respective instance represented by the respective sample violates the security property, and the negative verification tag indicates that the respective instance represented by the by the respective sample does not violate the security property; classifying each of the selected samples as a positive instance or a negative instance, using the ML model; identifying, from the selected samples, a subset of samples by comparing the respective assigned verification tag and the respective classification for each selected sample, wherein the subset of samples includes any samples that are incorrectly classified as negative instances, and any samples that are incorrectly classified as positive instances; and updating the training dataset by adding the identified subset of samples in the current iteration to the training dataset.

[0215] 6. The method of embodiment 5, wherein the method further comprises: training the ML model using the updated training dataset; obtaining one or more learning parameters of the ML model; and determining whether to repeat the number of operations for a further N iterations, based on the one or more learning parameters.

[0216] 7. The method of any of embodiments 1-3, 5 or 6, wherein the distributed node is further configured to perform iteratively the following steps for a predetermined number of iterations P: sending one or more learning parameters of the ML model to the central node; receiving one or more aggregated learning parameters from the central node; and updating the ML Model using the received aggregated learning parameters to obtain a global ML model.

[0217] 8. The method of any of embodiments 1 , 2 or 4, wherein, in response to determining that the distributed dataset represents a vertical distribution of datapoints, the number of operations comprise: selecting a sample from the local subset; sending, to the central node, the sample; receiving, from the central node, the sample with an assigned positive verification tag or negative verification tag, wherein the positive verification tag indicates that the instance represented by the sample violates the security property, and the negative verification tag indicates that the instance represented by the by the sample does not violate the security property; updating the training dataset by adding the sample with its assigned verification tag to the training dataset; and training the ML model using the updated training dataset; sending one or more learning parameters of the ML model to the central node; receiving one or more aggregated learning parameters from the central node; and updating the ML Model using the received aggregated learning parameters to obtain a global ML model.

[0218] 9. The method of any of embodiments 2-8, wherein the initial training set of datapoints comprises a first datapoint and second datapoint, the first datapoint representing an instance which violates the security property, and the second datapoint representing an instance which does not violate the security property.

[0219] 10. The method of embodiment 9, wherein the first datapoint is assigned a positive verification tag, and wherein the second datapoint is assigned a negative verification tag.

[0220] 11. The method of any of embodiments 1-3, 5-7, 9 or 10, wherein the method further comprises, in response to the determining that the distributed dataset represents a horizontal distribution of datapoints: generating a compliance report comprising the list of instances that violate the security property. 12. The method of any preceding embodiment, wherein the step of determining whether the distributed dataset represents a horizontal distribution of datapoints in the distributed system, or a vertical distribution of datapoints in the distributed system comprises: receiving, from the central node, an identifier indicating whether the distributed dataset represents a horizontal distribution or a vertical distribution.

[0221] 13. A method performed by a central node in a distributed system, for facilitating formal verification of compliance of a security property in the distributed system, the method comprising: receiving, from each distributed node, a sample from a respective local subset available at the distributed node, wherein a plurality of datapoints forming a distributed dataset are distributed amongst a plurality of distributed nodes in the distributed system, wherein each datapoint represents an instance to be verified as to its compliance to the security property, and wherein each distributed node has access to a respective local subset of the distributed dataset, and wherein the distributed dataset represents a vertical distribution of datapoints in the distributed system; merging the received samples; formally verifying whether each of the received samples violates the security property; assigning a positive verification tag or a negative verification tag to each of the received samples, wherein the positive verification tag indicates that the respective instance represented by the respective sample violates the security property, and the negative verification tag indicates that the respective instance represented by the by the respective sample does not violate the security property; and transmitting, to each distributed node, the respective sample received from the distributed node and the verification tag that has been assigned to the respective sample.

[0222] 14. The method of embodiment 13, wherein the method further comprises: receiving, from each distributed node, a respective first subset including datapoints of the local subset available at distributed node that are predicted as having violating characteristics with respect to the security property; merging the received datapoints; formally verifying whether each received datapoint violates the security property; and generating a list of datapoints that violate the security property.

[0223] 15. The method of embodiment 14, the method further comprising: receiving, from each distributed node, a respective second subset including datapoints of the local subset available at distributed node that are predicted as having nonviolating characteristics with respect to the security property; merging the received datapoints; formally verifying whether each received datapoint violates the security property; and generating a list of datapoints that violate the security property.

[0224] 16. The method of any of embodiments 13-15, wherein the method further comprises: determining whether the distributed dataset represents a horizontal distribution of datapoints in the distributed system, or a vertical distribution of datapoints in the distributed system; and transmitting, to at least one distributed node, an identifier indicating whether the distributed dataset represents a horizontal distribution or a vertical distribution.

[0225] 17. A computer program product comprising a computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform the method of any of embodiments 1 to 16.

[0226] 18. A distributed node configured to perform the method of any of embodiments 1 to 12.

[0227] 19. A distributed node, comprising a processor and a memory, said memory containing instructions executable by said processor whereby said distributed node is operative to perform the method of any of embodiments 1 to 12.

[0228] 20. A central node, configured to perform the method of any of embodiments 13 to 16.

[0229] 21. A central node comprising a processor and a memory, said memory containing instructions executable by said processor whereby said central node is operative to perform the method of any of embodiments 13 to 16.

[0230] 22. A distributed node, comprising: processing circuitry configured to cause the distributed node to perform any of the steps of any of embodiments 1 to 12; and power supply circuitry configured to supply power to the processing circuitry.

[0231] 23. A central node, comprising: processing circuitry configured to cause the central node to perform any of the steps of any of embodiments 13 to 16; power supply circuitry configured to supply power to the processing circuitry.

[0232] 24. A distributed node for sorting a local audit dataset part of a distributed audit dataset consisting of a plurality of datapoints where each datapoint represents an instance (or a part of an instance distributed in other nodes) to be formally verified to fasten the formal verification of security compliance with respect to a security property in a system and identify compliance violations, the distributed node being configured to: determine whether the distributed audit dataset is a horizontal or vertical distribution; perform a combination of minimal set of iterative interactions, locally and between the distributed node and the central node, to build a training dataset with a minimal number of datapoints from the local audit dataset and train a Machine Learning (ML) model using the training dataset to obtain a trained ML model, and obtain a remaining dataset by removing the training dataset from the local audit dataset; determine for each datapoint in the remaining dataset, one of two subsets that the datapoint is to be placed in, namely a first subset or a second subset, wherein the first subset includes datapoints that are predicted by the trained ML model as having violating characteristics with respect to the security property, and the second subset includes datapoints that are predicted by the trained ML model as having non-violating characteristics with respect to the security property; and responsive to the distributed audit dataset being a horizontal distribution, formally verify with priority the first subset using a formal verifier tool, and optionally verify subsequently the second subset, where the datapoints from the remaining datasets that are formally verified and thus mathematically proved to be violating the security property are identified as compliance violating datapoint instances; or responsive to the distributed audit dataset being a vertical distribution, send the first subset to the central node for formal verification, and optionally send the second subset, where the datapoints from the remaining datasets that are formally verified and thus mathematically proved to be violating the security property by the central node are identified as compliance violating datapoint instances by the central node.

[0233] In some embodiments, the system may be a virtual infrastructure. In some embodiments, the distributed node is configured to determine whether the distributed audit dataset is a horizontal or vertical distribution by receiving an identifier from the central node indicating whether the distributed audit dataset is a horizontal or vertical distribution.

[0234] 25. The distributed node of embodiment 24, wherein responsive to the distributed audit dataset being a horizontal distribution, the distributed node is further configured to perform the following minimal set of iterative interactions locally for a predetermined number of iterations Nitr: select a set of M representative samples of datapoint instances from the datapoints in the local audit dataset and transform the selected samples into the input language of the formal verification tool; formally verify the transformed samples against the security property using the formal verification tool, and for each verified sample, obtain a verification tag that is associated with the verified sample; apply a ML model on the samples; for sample datapoints with verification tags that are not equal to the classification results from applying the ML model on these samples, add these samples with their associated verification tags to a training dataset obtained from previous iterations to obtain a new training dataset.

[0235] 26. The distributed node of embodiment 25, wherein the distributed node is further configured to, prior to performing a minimal set of iterative interactions locally, train a ML model with an initial training dataset.

[0236] 27. The distributed node of embodiment 25, wherein the distributed node is further configured to, subsequent to performing the minimal set of iterative interactions locally, train a ML model with the new training dataset, obtain learning parameters of the trained ML model, and decide, based on some condition, whether to proceed or not with performing again the minimal set of iterative interactions locally;

[0237] 28. The distributed node of embodiment 27, wherein the distributed node is further configured to, subsequent to training the ML model with the training dataset and obtaining learning parameters of the trained ML model, perform the following minimal set of interactive interactions between the distributed node and the central node for a predetermined number of iterations Nitrprime, to obtain a global ML model: send learning parameters of the trained ML model to the central node; receive aggregated learning parameters from the central node; and update the ML Model using the received aggregated learning parameters to obtain a global ML model.

[0238] 29. The distributed node of embodiment 24, wherein, responsive to the distributed audit dataset being a vertical distribution, the distributed node is further configured to perform the following minimal set of iterative interactions between the distributed node and the central node for a predetermined number of iterations N itr: : select a representative sample datapoint instance from the datapoints in the local audit dataset; send the sample to the central node; receive the sample with its associated verification tag and add them to the training dataset obtained from a previous iteration to obtain a new training dataset; train a ML model with the new training dataset. send learning parameters of the trained ML model to the central node; receive aggregated learning parameters from the central node; and update the ML Model using the received aggregated learning parameters to obtain a global ML model.

[0239] 30. The distributed node of embodiment 29, wherein the distributed node is further configured to, prior to performing the minimal set of iterative interactions between the distributed node and the central node: receive an initial training dataset from the central node; and train an ML model with the initial training dataset.

[0240] 31. The distributed node of embodiment 30 and embodiment 26, wherein the initial training set of datapoints comprises a first datapoint and second datapoint, the first datapoint representing an instance which violates the security property associated with verification tag of “to be verified”, and the second datapoint representing an instance which does not violate the security property associated with verification tag of “not to be verified”.

[0241] 32. The distributed node of embodiment 24, responsive to the distributed audit dataset being a horizontal distribution, subsequent to obtaining compliance violating datapoint instances, is further configured to generate a compliance report with the datapoints and the result from the formal verification of the first subset and optionally from the formal verification of the second subset.

[0242] 33. A central node, wherein the central node is configured to: receive sample datapoint instances from each of the distributed nodes in the distributed system; merge the received datapoint instances; transform the merged datapoint instances into the input language of the formal verification tool; for each datapoint instance, formally verify the transformed datapoint instance against the security property and obtain a tag that is associated with the verified datapoint; split the merged datapoints into distributed datapoints; and transmit each distributed datapoint with its associated verification tag to its corresponding distributed node.

[0243] 34. The central node of embodiment 33, responsive to the distributed audit dataset being a vertical distribution, and subsequent to receiving the first subset and optionally the second subset and formally verifying the datapoints, the central node is further configured to: generate a compliance report comprising datapoints and the result from the formal verification of the fist subset and optionally results from the formal verification of the second subset.

[0244] 35. The central node of embodiment 34, wherein the central node is further configured to: identify whether the distributed audit dataset is a horizontal or vertical distribution; and transmit, to at least one distributed node, an identifier indicating the horizontal or vertical distribution.

[0245] ADDITIONAL INFORMATION

[0246] The following pages of the detailed description provide additional information regarding the distributed node, the central node and the methods discussed herein, and their implementation. These pages reproduce the text of an article “FLFM: Federated Learning-Guided Formal Method Verification for Microservices” that was included as an appendix to the priority founding application for this disclosure: US63 / 559298. Figure numbers referred to in the following pages correspond to the Figures appended to this disclosure as follows: Article Figures 1 to 14 referred to below comprise Figures 12 to 25 of the Figures appended to this disclosure. ABSTRACT

[0247] The microservice architecture divides a single application into loosely coupled, autonomous microservices to allow for independent development, deployment, and scaling of different functionalities. The architecture is widely adopted in modern cloud environments due to its numerous benefits, such as enhanced scalability, flexibility, and cost efficiency in application development and maintenance. On the other hand, the sheer scale and distributed nature of microservice-based applications may also lead to novel challenges for existing security solutions. Particularly, the standard practice of using formal methods to provide rigorous mathematical proof about security compliance may face two major challenges in the context of microservices. First, large scale microservice applications can cause formal methods to become very slow in identifying security breaches, which may leave a wide attack window. Second, the prohibitive overhead and potential privacy concerns may both prevent the collection of data from all the microservices for performing security verification at a central location. In this paper, we propose FLFM, a novel approach that combines the efficiency and privacy-friendliness of federated learning (FL) and the rigor of formal method (FM) for security verification in microservices. Specifically, FLFM works in two stages. First, each application samples a small but representative subset of its configuration data, and then labels such data using FM verification. This allows a relatively accurate FL model to be jointly trained by all the applications using only a small subset of data from each application. Second, the FL model can then be applied by each application to its remaining data in order to “guide” the FM verification for identifying security breaches faster, through prioritizing more suspicious candidates. We provide detailed methodologies for both the horizontal FL and vertical FL cases. We implement our solution based on the federated XG-Boost algorithm, the uncertainty sampling method, and a constraint satisfaction problem solver. Our experimental results demonstrate that FLFM can identify security breaches much faster than the baseline (e.g., 39% faster than the baseline approach in the horizontal FL case and 81.46% faster in the vertical FL case).

[0248] INDEX TERMS

[0249] Microservices, Federated learning, Security verification, Formal methods.

[0250] I. INTRODUCTION

[0251] The microservices architecture [1], a widely adopted software development architectural style, organizes and implements modern cloud applications as a collection of small, loosely coupled services, namely microservices, with well-defined interfaces and operations. Each microservice can be developed, deployed, upgraded, and scaled independently, thereby significantly improving the scalability and flexibility of application development and maintenance at minimal costs. As a result, microservices has become a de facto standard for developing large-scale commercial cloud applications, as evidenced by its adoption by many well-known companies (e.g., Uber [2], Twitter [3], and Netflix [4]).

[0252] Despite their benefits, microservices can pose novel security and privacy issues. Since real-world microservices-based applications (mApps) can become very large and complex (e.g., 1 ,000 microservices for the case of Uber [2], and O(105) different microservices scaled to O(103) (In production, administrators may use multiple identical instances of a microservice to improve performance and provide high availability [5]) service instances for Twitter in 2016 [3]), they may suffer from a larger attack surface and a higher risk of misconfiguration compared to their monolithic counterparts. For instance, communications among microservices, which were previously conducted through local invocations within a monolithic application, are now exposed through the network, which increases the security risks for the entire application. Consequently, an adversary can exploit the exposed inter-service communications to attack the entire application by sending malicious requests from a single compromised microservice to the other microservices [5], The timely identification of such security threats is important to ensure the security of the microservices-based applications.

[0253] In this regard, formal method-based security verification solutions (e.g., [6], [7], [8], [9],

[0010] ,

[0011] ,

[0012] ,

[0013] ) can offer rigorous evidence about the compliance or violation (alongside counterexamples showing security breaches) of configurations w.r.t. given security properties. However, the application of formal methods in such an environment can be challenging. First, the sheer scale of microservice applications can exacerbate the inherent complexity of formal methods

[0014] and cause them to experience significant delay in identifying misconfigurations. This delay could result in a wide attack window inside which the microservice applications will remain vulnerable. Second, the distributed nature of microservice applications can make data collection for security verification expensive or even infeasible. Specifically, collecting configuration data from each application could be expensive in terms of high communication costs, or infeasible due to the growing concerns about data confidentiality and privacy, especially considering the fact that such configuration data may be highly sensitive (as they may reveal security flaws) and typically governed by different organizations or administrative domains who would be reluctant to share such data.

[0254] Motivating example. We further illustrate this issue through an example. Specifically, Figure 1 shows two cases of data distribution, where the horizontal case means the audit data of the two microservice applications share the same attributes (i.e. , ID and Availability) but may have different ranges of values (e.g., assume Uber tends to have higher availability values than Bolt), and the vertical case means the two applications have different attributes (i.e., ID and Coverage for Insurance, but ID and RemedyCost for Medical). The top of each side shows the property to be verified, while the middle and bottom demonstrate the challenges faced by an existing solution

[0011] , and the key ideas of our solution, respectively.

[0255] More specifically, for the horizontal case, suppose we want to verify whether the Uber and Bolt microservice applications are compliant with the QoS property, i.e., if the ResponseTime is less than (5 seconds), then the AverageAvailability should be greater than or equal to (95%). To that end, MLFM

[0011] is an existing work designed to reduce the verification delay through guiding the formal method verification using a machine learning model.

[0256] However, as illustrated in Figure 1 , since the Availability value of the Uber application tends to be higher than that of the Bolt application, the machine learning model trained locally using each individual application’s data will not be accurate due to such data heterogeneity. Consequently, the model will not be very effective in prioritizing (through reordering) the data records such that likely security breaches (represented by grey bars in the figure) can be verified first.

[0257] In contrast, our solution (lower left of Figure 1) leverages federated learning (FL) such that the two applications can transmit local model parameters (instead of the raw data) to the central authority, who then aggregates such parameters to obtain a more accurate FL model, e.g., by taking average of the Availability thresholds (Step 1). This FL model can then be applied by each application to more effectively prioritize (reorder) its data records to reduce the verification time. The vertical case is similar, except that the challenge to MLFM

[0011] is caused by data unavailability (as each application lacks certain attributes) instead of data heterogeneity, and that the central authority needs to perform global verification (instead of parameter aggregation), which will be detailed later in Section IV.

[0258] The main contributions of this paper are as follows.

[0259] • We propose the novel concept of guiding formal methods with federated learning, namely FLFM, for faster identification of security breaches in microservice applications, without requiring each application to share its sensitive local data. We believe this approach can potentially be applied to other distributed environments.

[0260] • We provide detailed methodologies for both the horizontal and vertical FL cases, and we implement our solution based on a federated XGBoost algorithm

[0015] , uncertainty sampling technique

[0016] , and a constraint satisfaction problem solver, namely, Sugar

[0017] ,

[0261] • We evaluate FLFM through experiments and compare its performance to the state-of the-art approach MLFM

[0011] and the baseline FM method. Our results confirm the effectiveness of FLFM (e.g., it can identify security breaches up to 39% faster than MLFM in the horizontal FL case, and 81.46% faster than the baseline FM method in the vertical FL case). The remainder of the paper is organized as follows. Section II provides the background and threat model. Sections III and IV provides the horizontal and verticals FLFM methodologies, respectively. Section V describes our implementation. Section VI details the experiments. Section VII reviews the related work. Finally, Section VIII concludes the paper.

[0262] II. PRELIMINARIES

[0263] A. MLFM

[0264] MLFM is a security verification approach that combines the efficiency of Machine Learning (ML) and the rigor of Formal Methods (FM) for fast and provable identification of misconfigurations violating a given security property in Network Functions Virtualization (NFV). Specifically, MLFM employs an iterative teacher (FM)-learner (ML) interaction in which the teacher (FM) can gradually provide more representative verification results as training data to the learner (ML) such that it can gradually obtain more accurate ML model using only a small portion of the audit data (ML training stage). The resulted ML model can then be applied to the remaining data (ML application stage); the data not used for training, in order to identify data records that are more likely to violate the given property and prioritize the verification of those records.

[0265] Figure 2 details the teacher-learner interaction (which will be utilized in our work). The left side of Figure 2 shows a simplified example of the audit data (P) related to a security property under audit, represented by the attribute X and identified by the ID. In each iteration of the teacherlearner interaction, the teacher first applies a sampling method (such as uncertainty sampling

[0018] ) to select a representative data sample of fixed size (m) from the audit data (shown as the Sampler in the figure). Figure 2 shows that the sampler selects a sample of size (m = 2) including the (shaded) records (1) and (3), after applying the Decision Tree (DT) model (DTo).

[0266] The teacher then formally verifies the data records inside the selected data sample, and labels each record based on its verification result (shown as Formal verifier in the figure). Labeling means to annotate the data records with an extra field representing their classes, i.e., whether they are compliant with (represented as “+”), or violate (represented as “-”), the security property. In Figure 2 the formal verifier labeled record (1) as “+” and record (3) is labeled as Next the ML model received from the previous iteration (received from the learner) is applied to the labeled sample. By comparing its results to the labels assigned by the formal verifier, the teacher can identify those records that have been correctly classified (i.e., true positives (TPs)) and those incorrectly classified (i.e., false negatives (FNs) and false positives (FPs)) and adds them to a new dataset D, as more representative training data to be sent to the learner (and delete it from the audit data). In the figure the ML model (DTo) predicts “+”, if the value of X is no smaller than 19; otherwise, it is predicted as Comparing these results to the labels previously assigned by the formal verifier, we can identify that record (1) is FN and should be added to the dataset D, whereas (3) is TN and should not be added.

[0267] Finally, if the number of records in D is less than the desired size of the sample (m), the teacher repeats the aforementioned steps as an inner-iteration until it has accumulated m records in D. Otherwise (lower part of the figure), the sample in dataset D will be sent to the learner and D is emptied in preparation for the next teacher-learner iteration. The learner adds the received sample to its existing training data (T) i.e. , the collection of all previous samples, and utilizes this newly enriched training data to build a new more accurate ML model (DTi in the figure).

[0268] B. Federated Learning

[0269] Federated machine learning or Federated Learning (FL) for short, is a burgeoning trend in machine learning and artificial intelligence which enables collaborative decentralized privacypreserving training of machine learning models among multiple parties to overcome data privacy and security problems

[0019] , FL supports regulations that aims to protect users’ personal privacy and data security such as the General Data Protection Regulation (GDPR)

[0020] , the Health Insurance Portability and Accountability Act (HIPAA)

[0021] , and the California Consumer Privacy Act (CCPA)

[0022] ,

[0270] Generally speaking, in FL the participants train an ML model with their local data and send updates (i.e., local model parameters) to a federated server in an encryption mode. The server (also known as aggregator or coordinator) fuses the local updates and use them to create a new generic global model that is often sent back to the parties. This process could be repeated several times to obtain the final global model that achieves a certain desired performance or until reaching another stopping condition.

[0271] Federated learning can be categorized into horizontal federated learning (HFL), vertical federated learning (VFL), and federated transfer learning (FTL) according to the distribution of data

[0023] , In this paper, we utilize the HFL and the VFL. Horizontal federated learning is suitable in the case where all participants share the same attributes, i.e., the attributes are aligned across the participants, but they have different data samples. In contrast, vertical federated learning is suitable in the case where all participants share the same data samples, i.e., data samples are aligned across the participants, but they have different attributes.

[0272] Hereafter, we illustrate the FL training process using the federated XGBoost algorithm (the one we utilized in our work) to facilitate the understanding of the rest of the paper. XGBoost

[0015] is an optimized implementation of the Gradient Boosted Decision Trees (GBDT) which utilize an ensemble of sequentially trained decision trees to make the predictions.

[0273] The training of a single tree would require to calculate the gradient (g) and hessian (h) values for each data sample, then in a node level, build a gradient (and hessian) histogram for each attribute and find the value that maximizes the gain i.e., the value that best split the samples by maximizing the loss reduction after split. Finally, find the attribute with the maximal gain for the current node and split the samples accordingly. If the tree reaches a predefined restrictions such as the maximum depth or the gain is always smaller than zero, then current node is considered as a leaf node and holds the prediction result. The gradient (and hessian) histogram propose a small number of cut points as possible split candidates. The samples are sorted based on their attribute values and arranged into q buckets corresponding to the cut points. The gradient (or hessian) of each cut point is the sum of the gradients of the samples that falls into its bucket. Figure 3 (a) shows an simple example of finding the best split for a single node. Given the dataset, identified by Record ID, the gradients (and hessians, for simplicity we only show the gradients) are first calculated. Then, the gradient histograms are built using the calculated gradients. The histogram of Attribute 1 has two cut point (3, 10), the gradient of each cut point consist of the sum of the gradients of the samples that falls into its bucket e.g., the sample identified by Record ID (1) fall under that cut point (3); since the value of its attribute (i.e., Attribute 1) is less than the cut point (3). Therefore, the gradient of cut point (3) is the gradient of the sample i.e., (8). Afterword, the gain is calculated for each cut point of the histograms and the cut point with highest gain for each histogram is chosen i.e., (17) for histogram of Attribute 1 and (10) for histogram of Attribute 2. Finally, the attribute with the maximal gain is chosen i.e., Attribute 2. Accordingly, the current attribute-value pairs that best split the dataset for the current node are (Attribute 2,10).

[0274] Most of the solutions that utilize XGBoost in the FL settings exchange the gradients, hessians, and / or attribute-value split candidates between the parties and the aggregator

[0024] ,

[0025] ,

[0026] , In this paper we exchange the gradients and hessians histograms in HFL settings. Figure 3 (b) (left) shows an example of XGBoost training algorithm in HFL settings. The dataset (bottom left) is splitted up horizontally between the applications, Application 1 and Application 2. In each round, communicating in a node level, the applications compute the histograms locally and send the histograms to the server (step 1). Then, the server aggregates the histograms by summation i.e., gradient (and hessian) values that fall under a specific bin interval are summed within their respective value buckets (step 2). Next, the applications receive the aggregated histograms from the server to update the local model (step 3). Eventually each party will end with histograms created as if we have the entire dataset (histogram of Attribute 1 in middle figure is identical to the histogram of the same attribute in the left figure).

[0275] Figure 3 (b) (right) shows an example of the XGBoost training algorithm in VFL settings. The dataset (bottom left) is splitted up vertically between the applications, Application 1 and Application 2. Only the application that has the labels (usually called the active participant) i.e., Application 1 , can compute the gradients (and hessians), therefore, this application sends the gradients (and hessians) values to the server (step 1 in the figure), only once for each tree

[0027] , Then, the server sends them back to the other applications (Application 2) (step 2), that do not have the label, so that they can compute the corresponding gradients (and hessians) histograms. Similar to the HFL settings, in each round, communicating in a node level, the applications send the histograms to the server (step 3). Then, the server aggregates the histograms by concatenation i.e., histograms of all attributes are grouped together, to compute the node parameters (step 4); the best split (i.e., attribute-value pairs) or the prediction value if the current node is a leaf node. Next, the applications receive the node parameters from the server and update the local model (step 5). Each party will end with the same global ML model. Note that, the split value is the same as the one found in the left figure.

[0276] C. Investigated Properties

[0277] Our approach can support the verification of various security or custom properties as long as they can be verified using the chosen formal method tool (e.g., Sugar

[0017] utilized in this paper can handle properties formulated using standard first-order logic). To make our discussion more concrete, we provide a brief description of two example properties (which will be required later). Quality of Service (QoS) property - checks if the microservice performance is complaint with the requirements determined in the Service Level Agreement (SLA) agreement between the service provider and the tenant. Detecting the violations of this property, if any, would help Cloud Service Providers (CSPs) to use techniques like horizontal scaling to maintain the QoS and mitigate costly penalty or lose to tenants. The performance is measured using a QoS metrics such availability and response time, which are predefined by the SLA.

[0278] Insurance evaluation property - helps the insurance company to create new or update existing health insurance payment policy regarding the insurance coverage of some types of disease. E.g., if the disease treatment plan of cancer costs 1000 dollars then the insurance will only cover 700 dollars, and the coverage changes with different disease.

[0279] D. Threat Model and Assumptions

[0280] In line with the majority of Federated Learning (FL) approaches, we assume that the data is Independently and Identically Distributed (II D) among the parties involved. We assume that the microservice-based applications and their respective microservices are isolated through suitable security mechanisms. We assume that the privacy of the participants are protected from potential information leaks or inference attacks by using appropriate privacy protection mechanisms for both the exchanged data and histograms, such as encryption algorithms like homomorphic encryption and differential privacy. Additionally, we assume that the exchanged data and histograms are accurate and complete.

[0281] Similar to the prevailing security verification approaches, our scope is limited to attacks that (directly or indirectly) cause violations to given security properties, and we assume our solution is deployed by the microservice provider or owner of the microservice-based application who has access to the essential logs, databases, and configuration data required for conducting security verification (and the integrity of those input data is required with trusted computing techniques (e.g.,

[0028] )). Furthermore, we assume that all the entities involved in the verification process are trustworthy and dependable.

[0282] Under such established assumptions, our in-scope threats include both external attackers who exploit existing vulnerabilities in the microservice architecture to violate the security properties, and insiders such as cloud operators and tenants who cause misconfigurations violating the properties, either through mistakes or by malicious intentions. On the contrary, out-of-scope threats encompass attacks that do not result in breaching the security properties, and attacks launched by adversaries capable of eliminating evidence of their attacks by tampering with the logs, databases, etc. Furthermore, we did not consider insider attacks, which involve participants in the FL training aiming to diminish performance, disrupt the system, or extract information from other parties. Neither outsider attacks targeting the communication channel between participants and the aggregation server, such as eavesdropping.

[0283] We assume that the formal specification of security properties as well as the formal verification approach itself are correct and sound. As a security verification solution, our approach can only identify the violation of given security properties, but is not designed to attribute such a violation to the underlying vulnerabilities (responsibility of vulnerability analysis) or specific attacks (responsibility of intrusion detection). Similar to most existing machine learning approaches, we assume that a dataset required for verifying given security properties has been collected. However, we do not require labeled data, which can be difficult to obtain in a real world cloud environment, as the data records will be labeled by the formal method in our approach.

[0284] III. HORIZONTAL FLFM (H-FLFM) METHODOLOGY

[0285] This section presents an overview of the H-FLFM followed by details on its key components.

[0286] A. Overview

[0287] We propose a horizontal federated machine learning-guided formal verification approach, namely H-FLFM, aiming at fast and provable identification of data records in microservices based applications violating certain security properties while preserving the data privacy of each participant. This approach is qualified as horizontal since the audit data are horizontally distributed among the applications. Figure 4 depicts an overview of H-FLFM with an excerpt of the data, where each application has different data records (identified by ID) but the same attributes (e.g., attribute A 1). First, the ML training stage is performed by each participating application to train a local ML model (using only a small representative portion of the applications’ audit data) with the help of a central authority playing the role of a federated learning server to improve the accuracy of those models based on a global view. Second, the ML application stage applies the global ML model (learned by each application after several iterations) to efficiently reorder the remaining audit data of each application, such that those records that are more likely to violate the property will be verified first. In this approach, only the ML models learning parameters are exchanged between the central authority and the applications.

[0288] The ML Training Stage. As shown in Figure 4 (top-right part inside Application_1), during each iteration of the teacher (FM)-learner (ML) interaction, the teacher initially employs a sampling method to select a small fixed-sized data sample from the audit data (depicted as Sampler) of the respective application after applying the ML model received from the learner in the previous iteration (an initial ML model is provided for the first iteration). Subsequently, the teacher proceeds to verify the data records within this data sample and labels each record according to its verification results (depicted as Formal verifier), and sends the labeled data sample to the learner. The learner integrates this newly received data sample with previously received ones to train a new local ML model, which is then forwarded back to the teacher for the subsequent iteration. The same iterative interaction is performed at every other participating applications. Afterwards, at the end of these iterative interactions by all applications, the central authority coordinates a federated learning approach to increase the accuracy of the locally trained ML models, particularly for predicting the minor class (i.e. , the class that represents the violated records). Specifically, as shown in Figure 4 (top), each participating application sends the learned parameters (e.g., gradients and hessians histograms in case of deploying federated XGBoost model) of its local ML model to the central authority, which aggregates all received parameters (shown as Aggregating gradients histograms in the Figure). Then, the central authority sends the aggregation results back to each participating application so that it updates its local model (shown as Updating ML model inside Application_1). If more training is needed, the updated model is used by the teacherlearner interaction at each application for another round of ML training. This iterative ML training process ends when reaching a predefined condition, e.g., a pre-defined iteration count, or when the accuracy level does not show a significant improvement between two consecutive iterations.

[0289] The ML Application Stage. As Figure 4 (bottom part inside Application_1) shows, the final global ML model obtained from the ML training stage is applied to the remaining audit data (i.e., the data not used for the training) of each application in order to identify data records that are more likely to violate the given security property, namely, the “to be verified” subset, which will be given a higher priority for verification. On the other hand, the “not to be verified” subset will either be verified afterwards, or not verified at all, depending on the use cases (discussed in Section VI).

[0290] B. ML Model Training

[0291] In the following, we provide more details about the local ML model training and the federated global model learning in H-FLFM.

[0292] Local ML Model Training. The local ML model training takes place at each of the participating applications and it is designed to select a small and representative portion of the audit data to be used in an iterative teacher (FM)-learner (ML) interaction (as detailed in Section ll-A) in order to accelerate the building of the global model (using the federated learning approach detailed in next section). Specifically, by utilizing a small number of data records that better represent the characteristics of the property being analyzed to train the ML model, the number of federated learning iterations can be reduced, which also reduces the communication overhead between the application and the central authority. In this iterative interaction, the main objective of the teacher is to help the learner to effectively enhance the ML model over each iteration using a minimal number of labeled data records (as they are labeled using formal verification, which is expensive) that better represent the characteristics of the property being analyzed. The iterative interaction ends when reaching a predefined condition (e.g., a specified number of iterations or no accuracy improvement between two iterations) and the learning parameters of the final local ML model is sent to the central authority to commence a federated learning iteration. The following example provides more details.

[0293] Example 1 : Figure 5 (step 1) shows the local ML training in the participating applications i.e., Uber and Bolt applications. Considering Uber application (the lower left part of the figure), as detailed in the preliminary section (Section ll-A), using the uncertainty sampling method, the sampler (inside the teacher block) selects a sample of size (m = 1) which includes the data record (1). Then, the formal verifier verifies this record and assigns (+) label to the record (1) while the local DT model classifies this same record as (-). Thereafter, record (1) is selected as it is a FN record, therefore it is selected by the teacher to be part of the dataset D (records to be sent to learner and it is removed from the audit data P). Since we have a sample of size (m = 1) in this example, the sample is sent to the learner (as Sizeof(D) < m) which will add it to the existing training data (T) while the teacher empties its dataset (D). The learner uses the new (T) to build a new local DT model, which is more accurate than the previously trained one. Based on the number of iterations performed, either the iterative interaction between the teacher and the learner ends when reaching (n) iterations or the new local DT model is sent back to the teacher for another round. The aforementioned steps are applied simultaneously for all the other participated applications (i.e. , the Bolt application in this example). At the end of the nth iteration the federated learning process commence to build a better model using the statistics produced by all the applications.

[0294] Federated Global Model Learning. The central authority is responsible for coordinating the federated learning process in order to enhance the accuracy of the local ML models built using the iterative teacher (FM)-learner (ML) interaction residing on each of the participating applications. The federated learning process starts at the end of (each set of rounds of) the local ML model training, where the last trained ML model is collaboratively built using the selected training data T. The accuracy of the ML model utilized to guide the formal verification is of significant importance to reduce the required verification time. Local applications’ data may not be large or diverse enough to build such an accurate model. Hence, we utilize a horizontal federated learning method (detailed in Section I l-B) to collaboratively train the ML model across different applications holding different datasets. This learning approach does not require gathering data owned by different applications to a central location (central authority) or sharing this data between the applications themselves. Only the learning parameters are shared by the applications with the central authority, thus preserving the applications data confidentiality and privacy. As a proof of concept, we deploy in this work a federated XGBoost classifier. Therefore, exchanged learning parameters between the applications and the central authority are the gradients and hessians histograms (details about the horizontal federated XGBoost training process are discussed in Section I l-B) and use it to explain the details of federated learning in the following examples. Note that, for the sake of clarity, we show a single DT in the examples.

[0295] Example 2: Following Example 1 , Figure 5 (step 2) shows that at the end of nth iteration of the teacher-learner interaction, each of the participating applications sends the final local ML model parameters (i.e., gradient and hessian histograms, we only display the gradient histograms for simplicity) to the central authority. Specifically, it shows two gradient histograms with three different gradient values i.e., (5, 21 , 7) and (3, 9, 6) sent by the Uber and Bolt applications, respectively.

[0296] Given the collected gradient and hessian histograms from each application, the central authority performs an aggregation operation to merge the received histograms into a final histogram representation. The obtained gradient and hessian values are aggregated by summation i.e., their values are summed within their respective value buckets. Example 3: Following Example 2, Figure 5 (step 3) shows the aggregation of received gradient histograms at the central authority. Particularly, the aggregation results in a histogram with the values (8, 30, 13)

[0297] Once the received histograms are aggregated, the central authority sends the final merged histogram to each of the applications. Each application then uses the received histograms to update its local ML model. Eventually, all applications receiving the same replication of the gradient histograms, and thus end up with a generalized ML model. The central authority and the applications exchange the learning parameters for several iterations, to train a relatively accurate ML model. At each iteration, the updated ML model is utilized by the next iterative teacher (FM)- learner (ML) interaction to locally train a new ML model. Specifically, its utilized by the sampler to select representative data records and by the teacher in order to predict the class of the selected record. The iterations between applications and central authority stops when reaching a predefined condition, e.g., a fixed iteration count, or when some other stopping heuristic is considered. Then, the final ML model resulting from the federated learning will be used in the ML application stage.

[0298] Example 4: Following Example 3, Figure 5 (step 4) shows that the central authority sends the aggregated gradient histograms to the participating applications, which will be used to update the local DT model (step 5). If the specified number of aggregation iteration r is not reached (step 6), the updated DT model will be send to the teacher. Otherwise, the update DT model will be returned to be utilized by the ML application stage afterwards.

[0299] IV. VERTICAL FLFM METHODOLOGY

[0300] This section details the vertical FLFM approach.

[0301] A. Overview

[0302] We propose a vertical federated machine learning-guided formal security verification approach, namely V-FLFM, for fast and provable identification of data records that violate a given security property for microservice-based applications. This approach is qualified as vertical since the attributes of the same audit data record is vertically distributed among different applications. First, the ML training stage employs an iterative interaction between a sampler and a learner (ML) at each participating application from one side and a verifier (FM) and an aggregator at a central authority from the other side. This interaction aims at collaboratively building a training dataset obtained from a small representative portion of the audit data of each of the participated applications and utilizing it with a vertical federated learning algorithm to train a ML model. Second, the ML application stage applies the trained ML model to efficiently reorder the remaining audit data of each application. Depending on the use case (detailed in Section VI), those records, which are more likely to violate the property, will be sent to the central authority to be verified first. In this approach, the ML models learning parameters are exchanged between the central authority and the applications while selected data records from each application is sent to the central authority for formal security verification. Figure 6 depicts an overview of V-FLFM.

[0303] The ML Training Stage. As shown in Figure 6, V-FLFM follows an iterative procedure to obtain the training data and use it to build the ML model. In the first part of each iteration, the sampler and the learner (top-right part inside Application_1) interact with the verifier (left part inside Central authority) to build a training dataset. Specifically, a sampling method (shown as Sampling within the Sampler) is used in each participant application to select a small data sample of a fixed size from the audit data after applying the ML model built by the learner in the previous iteration (an initial ML model is provided for the first iteration). Afterwards, the selected sample is sent to the central authority where each record is first verified using a formal verification approach (depicted as Formal verifier) and then it is labeled based on its verification result. Thereafter, the labeled data sample is sent back to the corresponding application’s learner, which integrates this newly received data sample with the previously received ones. The learner uses this labeled dataset to train a new ML model utilizing a vertical federated learning algorithm. In the second part of each iteration, the learner sends the learned parameters of the local ML model to the aggregator (right part inside Central authority), which aggregates those and computes the node parameters before sending them back to each participating application (shown as Sending node parameters). The latter updates its local model (shown as Updating ML model inside Application_1). If more training is needed, the updated model is used by the sampler at each application for another round of ML training. This iterative ML training process ends upon meeting a pre-defined condition, such as reaching a set iteration count or observing negligible changes in the model’s accuracy between two consecutive iterations.

[0304] The ML Application Stage. As Figure 6 (bottom part inside Application_1) shows, the final ML model obtained from the ML training stage is applied to the remaining audit data (i.e., the data not used for training) of each application in order to identify data records that are more likely to violate the given security property, namely, the “to be verified” subset, which will be given a higher priority for verification. On the other hand, the “not to be verified” subset will either be verified afterwards, or not verified at all, depending on the use cases (discussed in Section VI). Finally, the selected subset to be verified is transmitted to the central authority for performing the verification using the Formal verifier.

[0305] B. V-FLFM ML Model Training The methodology for ML model training in V-FLFM is designed to progressively build an ML model in an iterative way using a small and representative portion of the audit data distributed among different applications. In the following, we provide more details about the ML training of the V- FLFM approach supported by a running example.

[0306] Training Data Building. The ML model training, in each iteration, begins by selecting a representative data sample from the audit data of each participant application using sampling strategies derived from the active learning literature. Since the data is vertically distributed, the attributes (containing essential values for verification) of each data record is gathered from all the participating applications i.e. , the sample is gathered from all the applications simultaneously. The sample’s data records are subsequently forwarded to the central authority for labeling. Each data record is annotated with an additional field indicating their classes i.e., whether they are compliant with, or violate, the given security property. The labels are obtained by performing a formal verification by instantiating the given property (e.g., formulated using first-order logic) with the data records. Subsequently, the central authority transmits these labels associated with the record id to the corresponding application.

[0307] Example 5: Figure 7 shows the ML training over the dataset of the participating applications i.e., Insurance and Medical applications. Considering Insurance application (the lower left part of the figure), the sampler (step 1) first selects a sample of size (m = 1), using the uncertainty sampling method, which includes the data record (ID = 1). As we explained earlier in this section, the sampling is performed at every other participating applications simultaneously to gather all the attributes of each data record that are distributed among these applications, as all the attributes of the same data record is required to verify the compliance of that record. Then, the sample is sent (step 2) to the Verifier (inside the central authority) which verifies this record and assigns (+) label to the record (ID = 1) by utilizing the formal verifier (step 3), the labeled sample is then sent to the Insurance application (step 4) which will later be utilized by the learner as training data.

[0308] ML Model Training. Upon receiving the labeled sample, the learner component within the participant application incorporates this sample into its current training data, which encompasses all previous samples. Subsequently, it employs this augmented training data to construct a new ML model using the vertical federated learning algorithm. The vertical ML algorithm initiates by calculating the gradients and hessians histograms from the training data. As only the participant application that has the labels can compute the raw gradients and hessians, it transmits these values to the central authority (only once for each decision tree, refer to Section I l-B for more details). Subsequently, the central authority forwards these values to the other participants lacking labels, allowing them to compute the corresponding gradients and hessians histograms. Next, the calculated histograms from all participants are forwarded to the central authority for aggregation (through concatenation as discussed in Section I l-B) to compute the node parameters i.e., the best split or the prediction value if the current node is a leaf node, which are then transmitted to the participant applications to update their local models. The central authority and participant applications communicate several times to build the ML model, specifically the XGBoost ML model. Training a single decision tree requires many communication rounds at a node-level between them. If a stopping condition, such as a specified number of iterations, has not been met, the built ML model is employed in the subsequent round of ML training, otherwise, the training ends and the final ML model is passed to the ML application stage.

[0309] Example 6: Following Example 5, Figure 7 (step 5) shows that the participated applications sends the learning parameters (we only display the gradient histograms for simplicity) to the central authority. We exclude the step of sending the gradient and hessian values for simplicity. Specifically, it shows two gradient histograms with three different gradient values i.e., (4, 18, 12) and (6, 17, 10) sent by the Medical and the Insurance applications, respectively. The histograms (step 6) are then concatenated by the Aggregator (inside the central authority), and used to compute the node parameters, which are sent to the participant applications (step 7) to update their local models. The updated ML model will be deployed by the next iteration of the ML training if the number of iterations (r) has not been reached; otherwise, it will be returned and utilized by the ML application stage.

[0310] V. IMPLEMENTATION

[0311] In this section, we describe the architecture and details of our implementation.

[0312] System Architecture. Our FLFM implementation (shown in Figure 8) interacts with the administrative user, which is responsible for overseeing the central authority, to obtain the security property to be verified alongside other inputs like the formal verifier and system parameters (the number of iterations and the sample size, as detailed in Sections III and IV). Furthermore, it interacts with the cloud environment to acquire the necessary audit data for verification. Finally, the system delivers an audit report to the user.

[0313] Data Collection and Processing. We utilize Python to implement this module, which collects audit data from the microservice-based applications and converts it into the necessary input formats for both the formal verifier and ML training.

[0314] FLFM Manager. We utilize Python to implement this module, which is accountable for triggering either Horizontal or Vertical FLFM approach based on the audit property and data distribution. Additionally, it manages and orchestrates the interactions among other system modules specifically for conducting data processing, data sampling, formal verification, ML training, etc., as detailed in Sections III and IV. ML Model Learner. We utilize Python 3.6.9 and Scikit-learn 0.24.1 (an open source ML library written in Python) to implement this module. For both horizontal and vertical federated learning, we opt for the XGBoost classifier

[0015] , a scalable tree boosting algorithm that won many awards in ML and data mining competitions and has seen wide application in real-world for its high accuracy and low false positive rate

[0029] ,

[0030] , We employ FedTree

[0027] , a FL system designed for tree-based models, to implement federated XGBoost. FedTree employs a histogram-sharing strategy for both horizontal and vertical FL. It facilitates distributed computing for practical FL deployment with configurable privacy techniques like Differential Privacy and Homomorphic Encryption, and supports standalone FL simulation on a single machine. Although most of the FL research focus on neural networks, our work excludes them due to their widely recognized higher complexity and longer training time compared to traditional ML models

[0031] , which is not aligned with our main objective of reducing the overall delay before violations can be identified.

[0315] Aggregation. Aggregates different learning parameters received from FLFM participants i.e., the microservice-based cloud applications.

[0316] Sampler. We utilize the modAL framework

[0016] to implement sampling strategies within this module. modAL is an active learning framework for Python3, built on top of Scikitlearn

[0032] , which enables the rapid creation of active learning workflows with flexibility

[0016] , In our implementation, we opt for the uncertainty sampling strategy due to its superior computational efficiency compared to other strategies

[0018] , Moreover, our previous work

[0011] has demonstrated that combining uncertainty sampling with XGBoost achieves the highest verification performance.

[0317] Formal Verifier. We formalize the security properties along with the audit data as a Constraint Satisfaction Problem (CSP), a time-proven technique to express intricate problems. Leveraging CSP permits users to articulate a wide range of security properties (owing to its expressiveness) in a relatively simple manner (as CSP facilitates the uniform representation of audit data and security properties, presenting them in a clear and understandable formalism, such as first-order logic (FOL)

[0033] ). Additionally, there exist many robust and efficient CSP solver algorithms to circumvent the state space traversal

[0034] , which can enhance the scalability of our approach, particularly in larger environments.

[0318] After being formulated as a CSP problem, the security verification is performed using Sugar

[0017] , a well-established SAT-based constraint solver. We opt for Sugar due as it is an award-winning solver of global constraint categories (at the International CSP Solver Competitions in 2008 and 2009

[0035] ). Sugar tackles a finite linear CSP by converting it into a SAT problem through the order encoding method, and then it solves SAT problem using the MiniSat solver

[0036] , an efficient CDCL SAT solver recognized for its effectiveness in narrowing the search space

[0037] , In our future endeavors, we aim to adapt our FLFM framework to other verification methods (such as theorem proving, model checkers, temporal logic, and Datalog) based on the specific requirements of the verification tasks.

[0319] Example 7: The predicate that corresponds to the negation of the QoS property is formulated (by the system admin user, done only once) as Formula 1 , and a predicate instance returned by Sugar to indicate violation is shown as Formula 2 (i.e., the microservice PassengerManagement has ResponseTime greater than 5 second and AverageAvailability less than 95%).

[0320] Vms e Microservices, VRT e ResponseTime, VAV e AverageAvalability : HasRT(ms, RT) A HasAv(ms, AV) A (RT >= 5) A (AvgRT < 95) (1)

[0321] HasRT(PassengerManagement, 1) A HasAv(PassengerManagement, 80) A (9 > 5) A (80 < 95) (2)

[0322] VI. EXPERIMENTS

[0323] This section describes first the use cases of our approach, the used datasets, and the experimental settings. Then, it presents our results of evaluating both H-FLFM and V-FLFM.

[0324] A. Use Cases

[0325] Both horizontal and vertical approaches of FLFM can be employed for two distinct use cases, determined by the verification process applied to the remaining data (i.e., the data not utilized during training), similarly to MLFM

[0011] , The first use case is the partial verification case in which FLFM execution ceases after verifying all the “to be verified” records (which would appear first after the reordering). This can be beneficial when the user seeks rapid violation detection while either avoiding data sharing between participants and the central authority (horizontal scenario) or minimizing shared data to reduce the communication costs (vertical scenario), although it may not guarantee the detection of all violations. The second use case is the priority-based verification case in which FLFM execution stops upon the verification of all records, while verifying the “to be verified” records first. These use cases will be used for the experimental evaluation of our approach detailed next.

[0326] B. Datasets and Experimental Settings

[0327] We first describe the data generation aligned with horizontal and vertical cases, and then detail the experimental settings.

[0328] Application Data Generation. To evaluate the performance of FLFM, we produce multiple sets of synthetic datasets aligned with distinct scenarios, specifically the horizontal case (HFLFM) and the vertical case (V-FLFM). Our evaluation considers the involvement of two applications in the verification process. As such, for each FLFM experiment, we generate two datasets, one for each application, grouped into one set. Specifically, for assessing the performance of H-FLFM, we generate a set of 12 datasets (grouped into six sets), each containing 12,500 audit data records for verifying the QoS property (P1 henceforth, detailed in Section ll-C). Each set has a different level of heterogeneity, to examine H-FLFM under different deployment scenarios. Heterogeneity level denotes the extent of variability or distinctions within the data across various applications in terms of data values. For instance, 100% heterogeneity implies that the data values of different applications are entirely dissimilar.

[0329] Similarly, for assessing the performance of V-FLFM and compare it to the baseline approach, we generate 12 datasets (grouped into six sets), each containing 5,000 audit data records for verifying the insurance evaluation property (P2 henceforth, detailed in Section ll-C). The baseline approach naively reduces the number of shared records with the central authority by locally verifying each application’s audit data against specific sub-security-properties expressed on parts of the attributes to be verified, then the data records identified as violations by these sub-security- properties are sent to the central authority for verification, rather than sending the entire audit data. Those sub-security-properties are formulated for each participating application be decomposing the audited security property (performed by domain experts) based on the attributes owned by those applications. Consequently, these subsecurity-properties possess a degree of generality, meaning that certain data records might be identified as violations even if they do not violate the audited security property and they may not comprehensively identify all violating records, potentially leading to some violations being overlooked. Therefore, we have devised two use cases for comparison purposes. First the partial verification case, in which the records identified by the sub-security-properties as violations are sent for verification at the central authority. Second, the priority-based verification case, in which all the records are sent to the central authority for verification, while sending the records identified by the sub-security-properties as violations first.

[0330] In each generated dataset, we varied the ratio of false violations — these represent compliant data records exhibiting similar traits to non-compliant ones, while maintaining a consistent count of violating records. These dataset were constructed this way to evaluate V-FLFM against the baseline approach, which is susceptible to false violations, and to test the resilience of the ML model used in V-FLFM in the presence of such records. While each dataset contains around 10% of (uniformly distributed) records that violate the corresponding property (for both H-FLFM and V- FLFM), we progressively introduce an extra 10% of false violations for each subsequent set commencing with the second set of datasets (for the V-FLFM case).

[0331] Experimental Setting. All experiments are performed on a SuperServer 6029P-WTR running the Ubuntu 18.04 operating system equipped with Intel(R) Xeon(R) Bronze 3104 CPU @ 1.70GHz and 128GB of RAM without GPUs. All the experiments are performed using Sugar

[0017] as the formal verifier, FedTree

[0027] standalone simulation to simulate the federated settings, and Python 3.6.9 with Scikit-learn 0.24.1 ML packages for the ML method (i.e. , XGBoost classifier

[0015] ). For all experiments, we use the default parameters for the ML models and assume that only two applications participate in the verification. Each experiment is repeated 1 ,000 times to obtain the average results.

[0332] C. H-FLFM Experimental Results

[0333] In the following, we evaluate the impact of data heterogeneity and the different parameters on H- FLFM performance and then compare the performance of H-FLFM with the state-of the-art approach, MLFM

[0011] (Section ll-A), when applicable. As the audit data cannot be gathered centrally, we run MLFM on each application, where it solely relies on the local audit data to construct an ML model and identify the data records that violate the audited security property. Table I Shows the parameters considered in these experiments.

[0334] TABLE I: Main parameters employed in the experiments.

[0335] Impact of Data Heterogeneity. The first set of experiments aims at evaluating the impact of the level of data heterogeneity on the performance of H-FLFM and compare it to MLFM, from both the recall and the execution time point of views. To perform this experiment, we use the best performing parameters of MLFM (i.e., XGBoost with uncertainty sampling, 20% training data, sample size m = 250, and interactive iteration n = 10) and use these same parameters for H- FLFM in addition to specific parameter (i.e., aggregation-iteration r = 5) such that we perform one aggregation iteration after every two local iterations. In order to consistently generate more accurate ML models by leveraging the collective knowledge of multiple distributed datasets. Specifically, Figure 9 (a) shows the recall values for both H-FLFM and MLFM under different levels of heterogeneous data (ranging from 0% to 100%). The results show that H-FLFM achieves higher recall values (i.e., more effective in identifying the violations) than MLFM at all levels of heterogeneity. It also shows that H-FLFM is resistant to heterogeneity, therefore, it can predict both classes (i.e., the class of compliance and the class of violation) with higher accuracy compared to MLFM. At 0% heterogeneity, the accuracy of both approaches is high because the local data of each application includes all variations of data records that would allow the M L model to make good predictions. An increased heterogeneity level from 0% to 40% leads to decreased recall values for both approaches, until reaching their respective lowest values (51% for H-FLFM and 45.9% for MLFM). Then, the recall values start to increase after this threshold. It is worth noting that the recall of MLFM approach is high for large percentages of heterogeneous levels because the majority of the local data stays within the same range of values, therefore, the ML model prediction for the local data remains high. However, the resulted ML model is not general enough to identify all possible data records violating the security property.

[0336] Figure 9 (b) shows the execution time (for the priority-based verification use case) for H-FLFM and MLFM under different levels of heterogeneous data. The results show that, higher heterogeneity levels lead to slower execution time for both MLFM and H-FLFM. It also shows that H-FLFM is faster by nearly 13% on average than MLFM. The execution time continues to increase for both approaches until reaching 60% of heterogeneity level, a threshold after which, the execution time starts decreasing as the improvement of HFLFM increases higher recall values indicate that the model can identify most violations, thus these violations are verified within a shorter time) as illustrated previously.

[0337] In the subsequent experiments, since H-FLFM is designed to deal with highly heterogeneous data (while models created locally lack the generality to identify all data records violating the security property for highly heterogeneous data), we use a dataset with high heterogeneity level (i.e., 80%) to further test the performance of H-FLFM and show it is benefits compared to MLFM. Note that, we did not choose the dataset with 100% heterogeneity level since this case is rare in practice compared to the 80% level.

[0338] Impact of Parameters and Selection of the Best Ones. The aim of this set of experiments is to study the impact of the H-FLFM parameters, i.e., the number of iterations and the sample size (using dataset of 80% heterogeneity level) and then identify the optimal ones. Specifically, Figure 10 (a) shows the effect of the sample size and the number of iterations (involving both local and aggregation iterations occurring alternately after each other, with aggregation occurring once following each local iteration. For instance, 10 iterations entails 10 rounds, with each round consisting of one local iteration followed by one aggregation iteration.) on the execution time of H-FLFM.

[0339] With respect to the effect of sample size, the results show that when the sample size is increasing (i.e., more training data is employed) from 0 to 250 records H-FLFM performance improves owing to the enhanced accuracy of the ML model, where the lowest execution time for H-FLFM is achieved when the sample size is 250, independently of the number of iterations. After 250 records, the improvement decreases, independently of the number of iterations, with larger sample sizes, as the formal verification time of the sample during the training stage increases, where the sample’s influence becomes dominant, and elevates the overall verification time.

[0340] With respect to the effect of number of iterations, the figures shows that the execution time of H- FLFM, for any given sample size, follows an inverted bell curve where smaller number of iterations (e.g., 5 iterations) and larger number of iterations (e.g., 15 iterations) show higher execution time compared to number of iterations in between those values (e.g., 10 iterations). This can be explained as the increase in number of iterations leads to more accurate ML models

[0341] (as more training data is used) and thus the execution time decreases. However, a high number of iterations would lead to contrary results and increase the H-FLFM execution time, particularly when the model from preceding iterations is already reasonably accurate. In such instances, additional iterations primarily extend the training stage time, outweighing the time saved in the application stage, with minimal impact on the model’s accuracy. In summary, the figure shows that the lowest execution time for H-FLFM is achieved when the sample size is 250 and the number of iterations is 10.

[0342] Figure 10 (b) shows the effect of the number of aggregation iterations on the performance of H- FLFM in terms of the execution time (for priority-based verification) using the dataset of 80% heterogeneity and the best performing parameters i.e., (m = 250 and n = 10). It also shows a comparison between the execution time of H-FLFM and MLFM for these same settings. Different numbers of aggregation iterations correspond to varying frequencies at which aggregation processes are executed such that the sum of the local iterations is always 10. The results show that increasing the number of aggregation iterations reduces the verification time significantly, from 76 minutes for 1 aggregation to less than 50 minutes for 10 aggregations. Furthermore, the figure shows that H-FLFM is faster than MLFM and the benefit increases with the number of aggregations, For instance, H-FLFM is 36.7% faster than MLFM at the 10th aggregation iteration.

[0343] Efficiency of H-FLFM. Figure 11 (a) compares the performance of H-FLFM to MLFM for identifying different Percentages of violation (for the priority-based verification) using the dataset of 80% heterogeneity and the best performing parameters (i.e., m = 250, n = 10, and r = 10). The results show that H-FLFM identifies violations faster than MLFM, where it identifies all the violations 39% faster than MLFM. Figure 11 (b) shows the performance of H-FLFM for identifying different percentages of violations under different scenarios. This experiment tests the generality of the resulted ML model and its robustness in handling new data records that are different from the local data (i.e., they contain data records that have different distributions or data ranges). Specifically, its tested using ’’Future reverse data” records i.e., dataset with records that have completely different data ranges from the local data, and ’’Global data” records i.e., dataset with records that have data ranges that cover all possible data ranges of the security property. The results show that H-FLFM performance is the best using the local dataset and its performance decreases when using the Global data compared to local data, however, the performance is worst while verifying the Future reverse data. This is because for ’’Global data” scenario the data ranges could intersect with the ranges in the local data, while in ’’Future reverse data” scenario, the data ranges are completely different from the ones of the local dataset. Thus, fewer intersections between the data ranges lead to lower efficiency in violations identification because of longer verification time. Note that even in H-FLFM’s poorest performance (taking approximately 60 minutes to verify ’’Future reverse data”), it is still 21 % faster than MLFM (depicted in Figure 11

[0344] D. V-FLFM Experimental Results

[0345] In the following, we evaluate the impact of the different parameters (i.e., sample size and the number of aggregation iterations) on V-FLFM performance and compare the performance of V- FLFM with the baseline approach.

[0346] Best Performing Parameters. V-FLFM performance depends on the number of shared records with the central authority. The fewer records to be shared (containing only the violating records), the better is the performance of V-FLFM. Thus, the aim of this experiment is to first study the impact of the different parameters (i.e., sample size and the number of aggregation iterations) on the number of shared records with the central authority and then find out the optimal ones. Furthermore, we compare the performance of V-FLFM with the baseline approach based on these parameters.

[0347] Figure 12 (a) shows the impact of sample size and the number of iterations on the performance of V-FLFM in sharing records with the central authority for the partial verification. It also depicts the percentage of shared records by the baseline approach for partial verification. The results show that the percentage of shared records initially decreases (implying that V-FLFM performance increases in sharing less records) when reaching the sample size of 80 due to increasing the accuracy of the trained ML model. However, after 80 the number of shared records started to increase due to the increase in the sample size sent to the central authority during the ML training stage. It also shows that with more iterations V-FLFM shares more records which is related to sending more samples, in each iteration, to the central authority during the ML training stage. Accordingly the figure propose that V-FLFM performance is the best when the sample size is (80) and the number of iterations is (1). However, the percentage of shared records is not enough to measure the performance of V-FLFM since it doesn’t indicate the number of identified violations which is the second objective of our approach; reduce the number of shared records while identifying most of the violations. Hence, we also consider the FN rate (i.e. , percentage of miss-identified violation records that were not sent to the central authority) in determining the optimal parameters.

[0348] Figure 12 (b) shows the FN rate of both V-FLFM (for different combinations of the sample size and the number of iterations) and the baseline approach for the partial verification. The results show that with more iterations the FN rate of V-FLFM decreases; the accuracy of the built ML model in identifying likely violation records increases. Also, it shows that many pairs i.e., combinations of the parameters (i.e., sample size and the number of iterations) achieves the objectives of our approach. Therefore, the best combination of the parameters could depend on the user accuracy requirements. In our case we choose the pairs (120) and (5) as the optimal samples size and number of iterations, respectively. Consequently, our approach sends 52.23% fewer records compared to the baseline approach which sends 33.4% percent of the records, while achieving a lower FN rate (0.17) compared to the baseline approach (0.36, i.e., V-FLFM achieves 52.78% lower FN rate than the baseline).

[0349] Figure 12 (c) shows the percentage of shared records by V-FLFM (under different combinations of the sample size and the number of iterations parameters) and the baseline approach for priority-based verification. The results show that V-FLFM improvement (i.e., in sharing less records with the central authority) initially increases, due to increasing the accuracy of the trained ML model, and it reaches the lowest value (only 13.7 percent of records are shared) when the used sample size and the number of iterations are (120) and (1), respectively. Then, V-FLFM performance starts to decrease because the number of shared records during the training stage becomes dominant. Also, it shows that with more iterations V-FLFM shares more records which is again attributed to the increase of the number of samples shared with the central authority in each iteration.

[0350] Efficiency of V-FLFM. Figure 13 compares the performance of V-FLFM to the baseline approach for identifying different Percentages of violation (for the priority-based verification) using the best performing parameters (i.e., m =120 and r = 5). V-FLFM outperforms the baseline throughout the percentages, e.g., for priority-based verification, V-FLFM can identify all of the violations in around 17.5 minutes, which takes the baseline around 94 minutes, i.e., it takes around 81.46% less time to detect the same percentage of violations.

[0351] Percentage of records shared using different datasets. Figure 14 compares the performance of V-FLFM to the baseline approach for sharing less records with the central authority using the best performing parameters (i.e., m =120 and r = 5). In each dataset we kept the same violations records however we changed the number of false violations, increase it for each dataset, that could affect the performance of the baseline approach and the V-FLFM approach as well. Figure 14 (a) shows that the false violations (i.e., records that have similar characteristics as the non- compliant records) largely effect the baseline approach performance, also it shows that for all datasets the V-FLFM outperforms the baseline approach (shares almost 44.5% on average less records than the baseline approach). Figure 14 (b) shows that V-FLFM accuracy decreases (hence, the FN rate increases) when the number of false violations increases. Which related to the similar characteristics of the false violations with the true violations, leading to build a ML model that is less efficient to discriminate the true violations. Figure 14 (c) shows that V-FLFM shares less records than the baseline approach over all the datasets (shares almost 62.67% on average less records than the baseline approach). The results also shows that VFLFM and the baseline approach both have lower efficiency when the parentage of false violations are increased, however, V-FLFM is more resistant to them.

[0352] VII. RELATED WORK

[0353] Existing solutions related to security of microservice architecture focus on verifying the correctness of the microservices interactions (e.g., [6],

[0012] ,

[0013] ), anomaly detection (e.g.,

[0038] ,

[0039] ), access control for microservices (e.g., [5],

[0040] ,

[0041] ,

[0042] ), or performance analysis (e.g.,

[0043] ). Those works employ either formal methods (such as [6],

[0012] ,

[0013] ), graph-based methods (such as

[0038] , [5],

[0043] ,

[0042] ), ML methods (such as

[0039] ), sidecar-based methods (such as

[0040] ), or token-based methods (such as

[0041] ). In contrast to existing works, our focus lies in verifying another type of properties that verifies the quality of the microservice or validates user-specific properties using user’s private data stored within microservices. Moreover, unlike FLFM, existing formal method-based solutions do not tackle the delay in verification, their performance worsens as the size and complexity of the verification instance increases), leading to a considerable attack window during which the microservices or infrastructure remain vulnerable.

[0354] Federated learning has been deployed extensively in anomaly (e.g.,

[0044] ,

[0045] ,

[0046] ) and intrusion detection (e.g.,

[0047] ,

[0048] ), mostly within the Internet of Things (loT) architectures. As far as we are aware, there is no existing solution that employs federated learning for compliance verification (directly or indirectly), nor does any combine federated learning and formal methods for fast and effective verification as we propose (or in any other way).

[0355] There also exist security verification solutions for virtual infrastructures, such as NFV, cloud, and SDN (e.g., [9],

[0049] ,

[0010] ,

[0050] ,

[0011] ,

[0051] ,

[0052] ,

[0053] ,

[0054] ,

[0055] ,

[0056] ). Most of the FM-based solutions (e.g., [9],

[0049] ,

[0010] ,

[0050] ,

[0051] ,

[0052] ,

[0053] ,

[0054] ) do not explicitly tackle the delay in verification (so they may benefit from FLFM in this regard), except for NOD [9] which is specifically optimized for large applications. MLFM

[0011] addresses verification delays with ML-guided formal security verification but is limited to centralized environments requiring full data transfer, thus lacking support for modern distributed microservice-based deployments. Unlike formal methods, custom algorithms (e.g., [8] and

[0057] ) benefit from enhanced efficiency for specific properties; however, they often lack the expressiveness found in formal method-based approaches. The proactive approach (e.g.,

[0055] ,

[0056] ), optimize the verification time by performing the verification in advance based on predicted events, which aligns and can be integrated with our approach.

[0356] Table II summarizes the comparison between existing solutions and FLFM. The first and second columns enlist existing works and their verification objective. The next two columns compare the application of these works and their verification methods. The following two columns compare the coverage such as if they work on single microservice (MS-level) or they cover the entire microservice-based application. The last column enlist the type of utilized federated learning (horizontal or vertical), if applicable.

[0357] TABLE II: Summary of existing solutions.

[0358] VIII. CONCLUSION We have presented FLFM, a novel approach to security verification in microservice-based cloud environment that merges the efficiency and privacy-friendliness of federated learning (FL) with the rigor of formal methods for faster identification of security violations within distributed private data. In particular, FLFM operates through two stages. In the initial stage, each application samples a small yet representative subset of its configuration data and assigns labels to this subset through FM verification. This facilitates the joint training of a relatively accurate FL model, utilizing only a modest subset of data from each application. In the second stage, the FL model guides the FM verification on the remaining data of each application, accelerating the identification of security breaches by prioritizing more suspicious candidates. We provided methodologies for both horizontal and vertical FL cases. The experimental results demonstrated that FLFM outperforms the performance of the baseline approaches in identifying security breaches in both horizontal and vertical FL cases.

[0359] REFERENCES

[0360] [1] D. S. Linthicum, “Practical use of microservices in moving workloads to the cloud,” IEEE Cloud Computing, vol. 3, no. 5, pp. 6-9, 2016.

[0361] [2] T. Hoff, “Lessons learned from scaling uber to 2000 engineers, 1000 services, and 8000 git repositories,” available at: https^ Last accessed 6 November 2023.

[0362] [3] M. Benedict and V. Charanya, “How we built a metering and chargeback system to incentivize higher resource utilization of twitter infrastructure,” available at: http: / / bit.ly / 3aETIqs. Last accessed 6 November 2023.

[0363] [4] T. MAURO, “Adopting Microservices at Netflix: Lessons for Architectural Design,” available at: https: / / goo.gl / Dyrtvl. Last accessed 6 November 2023.

[0364] [5] X. Li, Y. Chen, Z. Lin, X. Wang, and J. H. Chen, “Automatic policy generation for {Inter-Service} access control of microservices,” in 30thUSENIX Security Symposium (USENIX Security 21), 2021 , pp. 3971-3988.

[0365] [6] A. Panda, M. Sagiv, and S. Shenker, “Verification in the age of microservices,” in Proceedings of the 16th Workshop on Hot Topics in Operating Systems, 2017, pp. 30-36.

[0366] [7] K. Jayaraman, N. Bjorner, G. Outhred, and C. Kaufman, “Automated analysis and debugging of network connectivity policies,” Microsoft Research, pp. 1-11 , 2014.

[0367] [8] P. Kazemian, M. Chang, H. Zeng, G. Varghese, N. McKeown, and S. Whyte, “Real time network policy checking using header space analysis,” in 10th {USENIX} Symposium on Networked Systems Design and Implementation (NSDI’13), 2013, pp. 99-111.

[0368] [9] N. P. Lopes, N. Bjorner, P. Godefroid, K. Jayaraman, and G. Varghese, “Checking beliefs in dynamic networks,” in 12th {USENIX} Symposium on Networked Systems Design and Implementation (NSDI’15), 2015, pp. 499-512.

[0369]

[0010] A. Oqaily, L. Sudershan, Y. Jarraya, S. Majumdar, M. Zhang, M. Pourzandi, L. Wang, and M. Debbabi, “NFVGuard: Verifying the Security of Multilevel Network Functions Virtualization (NFV) Stack,” in 2020 IEEE International Conference on Cloud Computing Technology and Science. IEEE, 2020, pp. 33-40.

[0370]

[0011] A. Oqaily, Y. Jarraya, L. Wang, M. Pourzandi, and S. Majumdar, “Mlfm: Machine learning meets formal method for faster identification of security breaches in network functions virtualization (nfv),” in Computer Security-ESORICS 2022: 27th European Symposium on Research in Computer Security, Copenhagen, Denmark, September 26-30, 2022, Proceedings, Part III. Springer, 2022, pp. 466-489.

[0371]

[0012] X. Meng, X. Duan, W. Tao, Y. Luan, J. Zhang, and D. Wu, “Modeling and verification of industrial microservice architecture based on formal methods,” in 2021 China Automation Congress (CAC). IEEE, 2021 , pp. 3776-3780.

[0372]

[0013] F. Dai, H. Chen, Z. Qiang, Z. Liang, B. Huang, and L. Wang, “Automatic analysis of complex interactions in microservice systems,” Complexity, vol. 2020, pp. 1-12, 2020.

[0373]

[0014] A. Souri, N. J. Navimipour, and A. M. Rahmani, “Formal verification approaches and standards in the cloud computing: a comprehensive and systematic review,” Computer Standards & Interfaces, vol. 58, pp. 1-22, 2018.

[0374]

[0015] T. Chen and C. Guestrin, “Xgboost: A scalable tree boosting system,” in Proceedings of the 22nd ACM SIGKDD international conference on knowledge discovery and data mining, 2016, pp. 785-794.

[0375]

[0016] T. Danka and P. Horvath, “modAL: A modular active learning framework for Python,” arXiv preprint arXiv: 1805.00979, 2018.

[0376]

[0017] N. Tamura and M. Banbara, “Sugar: A CSP to SAT translator based on order encoding,” Proceedings of the Second International CSP Solver Competition, 2008.

[0377]

[0018] B. Settles, “Active learning literature survey,” 2009.

[0378]

[0019] L. Li, Y. Fan, M. Tse, and K.-Y. Lin, “A review of applications in federated learning,” Computers & Industrial Engineering, vol. 149, p. 106854, 2020.

[0379]

[0020] G. D. P. Regulation, “General data protection regulation (gdpr),” Intersoft Consulting, Accessed in October, vol. 24, no. 1 , 2018.

[0380]

[0021] P. F. Edemekong, P. Annamaraju, and M. J. Haydel, “Health insurance portability and accountability act,” 2018.

[0381]

[0022] E. Goldman, “An introduction to the California consumer privacy act (ccpa),” Santa Clara Univ. Legal Studies Research Paper, 2020.

[0382]

[0023] Q. Yang, Y. Liu, T. Chen, and Y. Tong, “Federated machine learning: Concept and applications,” ACM Transactions on Intelligent Systems and Technology (TIST), vol. 10, no. 2, pp. 1-19, 2019.

[0383]

[0024] K. Cheng, T. Fan, Y. Jin, Y. Liu, T. Chen, D. Papadopoulos, and Q. Yang, “Secureboost: A lossless federated learning framework,” IEEE Intelligent Systems, vol. 36, no. 6, pp. 87-98, 2021 .

[0025] Z. Tian, R. Zhang, X. Hou, J. Liu, and K. Ren, “Federboost: Private federated learning for gbdt,” arXiv preprint arXiv:2011.02796, 2020.

[0384]

[0026] Y. J. Ong, Y. Zhou, N. Baracaldo, and H. Ludwig, “Adaptive histogrambased gradient boosted trees for federated learning,” arXiv preprint arXiv:2012.06670, 2020.

[0385]

[0027] Q. Li, Z. Wu, Y. Cai, Y. Han, C. M. Yung, T. Fu, and B. He, “Fedtree: A federated learning system for trees,” in Proceedings of Machine Learning and Systems, 2023.

[0386]

[0028] N. Schear, P. T. Cable II, T. M. Moyer, B. Richard, and R. Rudd, “Bootstrapping and Maintaining Trust in the Cloud,” in Proceedings of the 32Nd Annual Conference on Computer Security Applications, 2016, pp. 65-77.

[0387]

[0029] Z. Chen, F. Jiang, Y. Cheng, X. Gu, W. Liu, and J. Peng, “XGBoost classifier for DDoS attack detection and analysis in SDN-based cloud,” in IEEE international conference on big data and smart computing (BigComp), 2018, pp. 251-256.

[0388]

[0030] F. Neutatz, M. Mahdavi, and Z. Abedjan, “Ed2: A case for active learning in error detection,” in Proceedings of the 28th ACM International Conference on Information and Knowledge Management, 2019, pp. 2249-2252.

[0389]

[0031] P. Maji and R. Mullins, “On the reduction of computational complexity of deep convolutional neural networks,” Entropy, vol. 20, no. 4, p. 305, 2018.

[0390]

[0032] O. Kramer, “Scikit-learn,” in Machine learning for evolution strategies. Springer, 2016, pp. 45-53.

[0391]

[0033] M. Ben-Ari, Mathematical logic for computer science. Springer Science & Business Media, 2012.

[0392]

[0034] I. Sassi, S. Anter, and A. Bekkhoucha, “A graph-based big data optimization approach using hidden markov model and constraint satisfaction problem,” Journal of Big Data, vol. 8, no. 1 , pp. 1-29, 2021.

[0393]

[0035] “Sugar: a SAT-based Constraint Solver,” Last accessed 8

[0394] November 2021.

[0395]

[0036] N. Een and N. S ' orensson, “An extensible sat-solver,” in ” International conference on theory and applications of satisfiability testing. Springer, 2003, pp. 502-518.

[0396]

[0037] W. Gong and X. Zhou, “A survey of sat solver,” in Proceedings of AIP Conference, vol. 1836, no. 1. AIP Publishing LLC, 2017, p. 020059.

[0397]

[0038] M. M. Ghorbani, F. F. Moghaddam, M. Zhang, M. Pourzandi, K. K. Nguyen, and M. Cheriet, “Malchain: Virtual application behaviour profiling by aggregated microservice data exchange graph,” in 2020 IEEE International Conference on Cloud Computing Technology and

[0398] Science (CloudCom). IEEE, 2020, pp. 41-48.

[0399]

[0039] M.-O. Pahl and F.-X. Aubet, “All eyes on you: Distributed multidimensional iot microservice anomaly detection,” in 2018 14th International Conference on Network and Service Management (CNSM). IEEE, 2018, pp. 72-80.

[0400]

[0040] C. Meadows, S. Hounsinou, T. Wood, and G. Bloom, “Sidecar-based path-aware security for microservices,” in Proceedings of the 28th ACM Symposium on Access Control Models and Technologies, 2023, pp. 157-162.

[0401]

[0041] A. Venckauskas, D. Kukta, S. Grigaliunas, and R. Bruzgiene, “Enhancing microservices security with token-based access control method. 23 (6), 3363,” 2023.

[0402]

[0042] M.-O. Pahl, F.-X. Aubet, and S. Liebald, “Graph-based iot microservice security,” in NOMS 2018-2018 IEEE / IFIP Network Operations and Management Symposium. IEEE, 2018, pp. 1-3.

[0403]

[0043] Z. Zhang, M. K. Ramanathan, P. Raj, A. Parwal, T. Sherwood, and M. Chabbi, “{CRISP}: Critical path analysis of {Large-Scale} microservice architectures,” in 2022 USENIX Annual Technical Conference (USENIX ATC 22), 2022, pp. 655-672.

[0404]

[0044] V. Mothukuri, P. Khare, R. M. Parizi, S. Pouriyeh, A. Dehghantanha, and G. Srivastava, “Federated-learning-based anomaly detection for iot security attacks,” IEEE Internet of Things Journal, vol. 9, no. 4, pp. 2545-2554, 2021.

[0405]

[0045] Y. Zhao, J. Chen, D. Wu, J. Teng, and S. Yu, “Multi-task network anomaly detection using federated learning,” in Proceedings of the 10thinternational symposium on information and communication technology, 2019, pp. 273-279.

[0406]

[0046] Y. Liu, S. Garg, J. Nie, Y. Zhang, Z. Xiong, J. Kang, and M. S. Hossain, “Deep anomaly detection for time-series data in industrial iot: A communication-efficient on-device federated learning approach,” IEEE Internet of Things Journal, vol. 8, no. 8, pp. 6348-6358, 2020.

[0407]

[0047] D. C. Attota, V. Mothukuri, R. M. Parizi, and S. Pouriyeh, “An ensemble multi-view federated learning intrusion detection for iot,” IEEE Access, vol. 9, pp. 117 734-117 745, 2021.

[0408]

[0048] Z. He, J. Yin, Y. Wang, G. Gui, B. Adebisi, T. Ohtsuki, H. Gacanin, and H. Sari, “Edge device identification based on federated learning and network traffic feature engineering,” IEEE Transactions on Cognitive Communications and Networking, vol. 8, no. 4, pp. 1898-1909, 2021.

[0409]

[0049] G. Marchetto, R. Sisto, J. Yusupov, and A. Ksentini, “Virtual network embedding with formal reachability assurance,” in 14th International Conference on Network and Service Management, 2018, pp. 368-372.

[0410]

[0050] S. Spinoso, M. Virgilio, W. John, A. Manzalini, G. Marchetto, and R. Sisto, “Formal verification of virtual network function graphs in an sp-devops context,” in European Conference on Service- Oriented and Cloud Computing. Springer, 2015, pp. 253-262.

[0411]

[0051] T. Madi, Y. Jarraya, A. Alimohammadifar, S. Majumdar, Y. Wang, M. Pourzandi, L. Wang, and M. Debbabi, “ISOTOP: auditing virtual networks isolation across cloud layers in OpenStack,” ACM Transactions on Privacy and Security (TOPS), vol. 22, no. 1 , pp. 1-35, 2018.

[0052] T. Madi, S. Majumdar, Y. Wang, Y. Jarraya, M. Pourzandi, and L. Wang, “Auditing security compliance of the virtualized infrastructure in the cloud: Application to OpenStack,” in Proceedings of the Sixth ACM Conference on Data and Application Security and Privacy, 2016, pp. 195-206.

[0412]

[0053] S. Majumdar, T. Madi, Y. Wang, Y. Jarraya, M. Pourzandi, L. Wang, and M. Debbabi, “Security compliance auditing of identity and access management in the cloud: Application to OpenStack,” in IEEE 7thInternational Conference on Cloud Computing Technology and Science,

[0413] 2015, pp. 58-65.

[0414]

[0054] - , “User-level runtime security auditing for the cloud,” IEEE Transactions on Information

[0415] Forensics and Security, vol. 13, no. 5, pp. 1185-1199, 2017.

[0416]

[0055] S. Majumdar, Y. Jarraya, T. Madi, A. Alimohammadifar, M. Pourzandi, L. Wang, and M. Debbabi, “Proactive verification of security compliance for clouds through pre-computation: Application to OpenStack,” in European Symposium on Research in Computer Security. Springer,

[0417] 2016, pp. 47-66.

[0418]

[0056] S. Majumdar, Y. Jarraya, M. Oqaily, A. Alimohammadifar, M. Pourzandi, L. Wang, and M. Debbabi, “LeaPS: Learning-based proactive security auditing for clouds,” in European Symposium on Research in Computer Security. Springer, 2017, pp. 265-285.17

[0419]

[0057] Y. Wang, T. Madi, S. Majumdar, Y. Jarraya, A. Alimohammadifar, M. Pourzandi, L. Wang, and M. Debbabi, “TenantGuard: Scalable runtime verification of cloud-wide VM-level network isolation,” in The Network and Distributed System Security Symposium, 2017.

[0420] The following pages of the detailed description provide additional information regarding the distributed node, the central node and the methods discussed herein, and their implementation. These pages reproduce the text of an article “FLFM: Security Verification for Microservices Using Federated Learning-Guided Formal Method”. Figure numbers referred to in the following pages correspond to the Figures appended to this disclosure as follows: Article Figures 1 to 15 referred to below comprise Figures 26 to 40 of the Figures appended to this disclosure. The claims of the present application follow this text.

[0421] ABSTRACT

[0422] The microservice architecture divides a single application into loosely coupled, autonomous microservices to allow for independent development, deployment, and scaling of different functionalities. The architecture is widely adopted in modern cloud environments due to its numerous benefits, such as enhanced scalability, flexibility, and cost efficiency in application development and maintenance. On the other hand, the sheer scale and distributed nature of microservice-based applications may also lead to novel challenges for existing security solutions. Particularly, the standard practice of using formal methods to provide rigorous mathematical proof about security compliance may face two major challenges in the context of microservices. First, large scale microservice applications can cause formal methods to become very slow in identifying security breaches, which may leave a wide attack window. Second, the prohibitive overhead and potential privacy concerns may both prevent the collection of data from all the microservices for performing security verification at a central location. In this paper, we propose FLFM, a novel approach that combines the efficiency and privacy-friendliness of federated learning (FL) and the rigor of formal method (FM) for security verification in microservices. Specifically, FLFM works in two stages. First, each application samples a small but representative subset of its configuration data, and then labels such data using FM verification. This allows a relatively accurate FL model to be jointly trained by all the applications using only a small subset of data from each application. Second, the FL model can then be applied by each application to its remaining data in order to “guide” the FM verification for identifying security breaches faster, through prioritizing more suspicious candidates. We provide detailed methodologies for both the horizontal FL and vertical FL cases. We implement our solution based on the federated XG-Boost algorithm, the uncertainty sampling method, and a constraint satisfaction problem solver. Our experimental results demonstrate that FLFM can identify security breaches much faster than the baseline (e.g., 39% faster than the baseline approach in the horizontal FL case and 81.46% faster in the vertical FL case).

[0423] Index Terms — Microservices, Federated learning, Security verification, Formal methods.

[0424] I. INTRODUCTION

[0425] The microservices architecture [1], a widely adopted software development architectural style, organizes and implements modern cloud applications as a collection of small, loosely coupled services, namely microservices, with well-defined interfaces and operations. Each microservice can be developed, deployed, upgraded, and scaled independently, thereby significantly improving the scalability and flexibility of application development and maintenance at less costs. As a result, the microservices architecture has become a de facto standard for developing large-scale commercial cloud applications, as evidenced by its adoption by many well- known companies (e.g., Uber [2], Twitter [3], and Netflix [4]).

[0426] Despite their benefits, microservices can pose novel security and privacy challenges. Since real-world microservices-based applications (mApps) can become very large and complex (e.g., 1 ,000 microservices for the case of Uber [2], and O(105) different microservices scaled to O(103) service instances (in production, administrators may use multiple identical instances of a microservice to improve performance and provide high availability [5]) for Twitter in 2016 [3]), they may suffer from a larger attack surface and a higher risk of misconfiguration compared to their monolithic counterparts. For instance, communications among microservices, which were previously conducted through local invocations within a monolithic application, are now exposed through the network, which increases the security risks for the entire application. Consequently, an adversary can exploit the exposed inter-service communications to attack the entire application by sending malicious requests from one compromised microservice to the other microservices [5], The timely identification of such security threats is important to ensure the security of the microservices-based applications.

[0427] In this regard, formal method-based security verification solutions (e.g., [6], [7], [8], [9],

[0010] ,

[0011] ,

[0012] ,

[0013] ) are widely adopted to provide rigorous evidence about the compliance or violation (alongside counterexamples showing security breaches) of configurations w.r.t. given security properties. However, applying formal methods to microservice applications may face two major challenges. First, the sheer scale of microservice applications can exacerbate the inherent complexity of formal methods

[0014] and cause them to experience significant delay in identifying security breaches. This delay could result in a wide attack window inside which the microservice applications will remain vulnerable. Second, due to the distributed nature of microservice applications, it may be infeasible to perform security verification at a central location. Collecting configuration data from all the microservices could either be expensive (in terms of high communication costs) or impossible (e.g., due to data confidentiality and privacy concerns, considering the fact that such configuration data may be highly sensitive as they may reveal security flaws, and are typically governed by different organizations or administrative domains who are reluctant to share such data).

[0428] Motivating example

[0429] We further illustrate this issue through an example, shown in Figure 1 . Specifically, Figure 1 shows two cases of data distribution, where the horizontal case (left) means the audit data of the two microservice applications share the same attributes (i.e. , ID and Requests) but may have different ranges of values (e.g., assume Transportation company A tends to have higher requests rate than Transportation company B), and the vertical case (right) means the two applications have different attributes (i.e., ID and DevicelD for Banking institution, but ID and UserRole for Equifax). The top of each side shows the property to be verified, while the middle and bottom demonstrate the challenges faced by an existing solution

[0011] , and the key ideas of our solution, respectively. More specifically, for the horizontal case (left), suppose we need to verify whether the Transportation company A and Transportation company B microservice applications are compliant with the following property, i.e., the number of Requests per second should be less than or equal to 1 ,000. To that end, MLFM

[0011] is an existing work designed to reduce the verification delay through guiding the formal method verification using a machine learning model. However, as illustrated in the figure (middle left), since the Requests value of the Transportation company A tends to be higher than that of the T ransportation company A application, the machine learning model trained locally using each individual application’s data will not be very accurate due to such data heterogeneity. Consequently, the model is ineffective in prioritizing (through reordering) the data records such that likely security breaches (represented by grey bars in the figure) can be verified first.

[0430] In contrast, our solution (lower left) leverages federated learning (FL) such that the two applications can transmit local model parameters (instead of the raw data) to the central authority, which then aggregates such parameters to obtain a more accurate FL model, e.g., by taking the average of the Requests thresholds (Step 1). This FL model can then be applied by each application to more effectively prioritize (reorder) its data records to reduce the verification time. The vertical case (right) is similar, except that the challenge faced by MLFM

[0011] is caused by data unavailability (as each application lacks certain attributes) instead of data heterogeneity, and that the central authority needs to perform global verification (in addition to parameter aggregation), which will be detailed later in Section IV.

[0431] The main contributions of this paper are as follows.

[0432] • We propose the novel concept of guiding formal methods (FM) with federated learning (FL), namely FLFM, for faster identification of security breaches in microservice applications, without requiring each application to share its sensitive local data. We believe this concept can potentially be applied to other distributed environments.

[0433] • We provide detailed methodologies for both the horizontal and vertical FL cases, and we implement our solution based on a federated XGBoost algorithm

[0015] , uncertainty sampling technique

[0016] , and a constraint satisfaction problem solver, namely, Sugar

[0017] ,

[0434] • We evaluate FLFM through experiments and compare its performance to a state-of-the- art approach, MLFM

[0011] , Our results confirm the effectiveness of FLFM (e.g., it can identify security breaches up to 39% faster than MLFM in the horizontal FL case, and 81.46% faster in the vertical FL case).

[0435] The remainder of the paper is organized as follows. Section II provides the background and threat model. Sections III and IV detail the horizontal and vertical FLFM methodologies, respectively. Section V describes our implementation. Section VI presents experimental results. Section VII reviews the related work. Finally, Section VIII concludes the paper.

[0436] II. PRELIMINARIES

[0437] This section provides necessary background information and defines our threat model.

[0438] A. MLFM

[0439] We briefly review MLFM

[0011] since we will compare our work to this existing approach through experiments in Section VI. MLFM is an existing security verification approach that combines the efficiency of Machine Learning (ML) and the rigor of Formal Methods (FM) for fast and provable identification of security breaches in Network Functions Virtualization (NFV). First, during the ML training stage, MLFM employs an iterative teacher (FM)-learner (ML) interaction as follows. The teacher (FM) provides representative verification results as training data over several iterations, such that the learner (ML) can gradually train a relatively accurate ML model using only a small portion of the audit data. Second, during the ML application stage, the trained ML model can then be applied to the remaining data (i.e. , the data not used for training) in order to identify data records that are more likely to violate the given property, and hence prioritize the verification of those records.

[0440] Figure 2 is an example illustrating the key methodology of MLFM. Figure 2 details the teacher-learner interaction. The left side of the figure shows a simplified example of the audit data (P) with two attributes, R ID and X. In each iteration of the teacher-learner interaction, the teacher (Sampler) first applies a sampling method (such as uncertainty sampling

[0018] ) based on the ML model received from the previous iteration (e.g., the initial Decision Tree DTo) to select a representative data sample of fixed size (m = 2) from the audit data, e.g., the (shaded) records (1) and (3). The teacher (Formal Verifier) then formally verifies the sampled data records, and labels each record based on the verification result, e.g., record (1) is labeled with “+” (i.e., the verification result shows it is compliant with the given security property) and record (3) is labeled as (i.e., it violates the property).

[0441] Next, the ML model received from the previous iteration (DTo) is applied to the labeled records. By comparing its results to the labels assigned by the formal verifier, the teacher can identify the records that are incorrectly classified, i.e., false negatives (FNs) and false positives (FPs), and add them to a new dataset D, as more representative training data to be sent to the learner (those records are then deleted from the audit data to prepare for the next iteration), e.g., record (1) is a FN (since it is labeled as by the ML model, while it is a violation according to the verification), and should be added to the dataset D, whereas (3) is a TN and should not be added. Finally, the teacher will repeat the aforementioned steps until it has accumulated m records in D, which will then be sent to the learner. The learner adds those new records to its existing training data (T) to build a more accurate ML model (DTi) for the next iteration. We will utilize this teacherlearner interaction of MLFM in our work, while focusing on the novel challenges of federated learning.

[0442] B. XG Boost

[0443] In this paper, we employ XGBoost as the main ML model (although our methodology can be extended to other models). XGBoost

[0015] is an optimized implementation of the Gradient Boosted Decision Trees (GBDT) which utilize an ensemble of sequentially trained decision trees to make the predictions. The training of a single tree would require to first calculate the gradient (g) and hessian (h) values for each data sample. Then, at the node level, it builds a gradient (and hessian) histogram for each attribute and finds the value that maximizes the gain i.e., the value that best split the samples by maximizing the loss reduction after split. Next, it finds the attribute with the maximal gain for the current node and splits the samples accordingly. If the tree reaches a predefined restrictions such as the maximum depth or the gain being always smaller than zero, then the current node is considered as a leaf node that holds the prediction result. The gradient (and hessian) histogram show a small number of cut points as possible split candidates. The samples are sorted based on their attribute values and arranged into q buckets corresponding to the cut points. The gradient (or hessian) of each cut point is the sum of the gradients of the samples that fall into its bucket.

[0444] Figure 3 is an example illustrating XGBoost training. Figure 3 shows an example of finding the best split for a single node. Given the dataset identified by record ID, the gradients (and hessians, which are omitted for simplicity) are first calculated. Then, the gradient histograms are built using the calculated gradients. The histogram of A 1 has two cut points (3,10), the gradient of each cut point consists of the sum of the gradients of the samples that fall into its bucket e.g., the sample identified by ID (1) falls under that cut point (3). Since the value of its attribute (i.e., A 1) is less than the cut point (3). Therefore, the gradient of cut point (3) is the gradient of the sample, i.e., (8). Afterward, the gain is calculated for each cut point of the histograms, and the cut point with the highest gain for each histogram is chosen i.e., (10) for histogram of A 1 and (17) for histogram of A 2. Finally, the attribute with the maximal gain is chosen i.e., A 1. Accordingly, the current attribute-value pairs that best split the dataset for the current node are (A 1 ,10).

[0445] C. Federated Learning

[0446] Federated Learning (FL) enables collaborative decentralized privacy-preserving training of machine learning models among multiple parties to address the data privacy and security issues

[0019] raised by regulations (e.g., the General Data Protection Regulation (GDPR)

[0020] , Health Insurance Portability and Accountability Act (HIPAA)

[0021] , and California Consumer Privacy Act (CCPA)

[0022] ). FL generally requires the participants to train a local ML model with their local data, and send the local model parameters (also called local updates) to a central server through a secure channel. The server (also known as aggregator or coordinator) fuses the local updates to create a global model, which is often sent back to the participants. This process could be repeated for several iterations to achieve a desired performance, or until reaching a stopping condition. Federated Learning can be categorized into Horizontal Federated Learning (HFL), Vertical Federated Learning (VFL), and Federated Transfer Learning (FTL) according to the distribution of data

[0023] , In this paper, we focus on the HFL and VFL cases. Specifically, HFL means all participants share the same attributes, but they may have different data samples. In contrast, VFL means all participants share the same data samples, although they may have different attributes.

[0447] Figure 4 is an example illustrating XGBoost training in the HFL (left) and VFL (right) settings. Figure 4 (left) shows an example of XGBoost training in the HFL settings (most of the solutions that utilize XGBoost in the FL settings exchange the gradients, hessians, and / or attribute-value split candidates between the parties and the server

[0024] ,

[0025] ,

[0026] , and we focus on the gradients and hessians histograms in this paper). Specifically, the dataset (bottom left) is divided horizontally between Application 1 and Application 2. First, in each round, communicating for each node, the applications locally compute the histograms and then send the histograms to the server (step 1). Then, the server aggregates the histograms through summation, i.e. , the gradient (and hessian) values that fall inside a specific bin interval are summed within their respective value buckets (step 2). Next, the applications receive the aggregated histograms from the server to update the local models (step 3). Eventually, each application will end up with histograms that are created as if it had the entire dataset (e.g., the histogram of attribute A 1 at the top of the figure is identical to the histogram of the same attribute on the left).

[0448] Figure 4 (right) shows an example of the XGBoost training algorithm in the VFL settings. The dataset (bottom right) is divided vertically between the applications. Only the application that has the labels (usually called the active participant), i.e., Application 1 , can compute the gradients (and hessians). Therefore, this application sends the gradients (and hessians) values to the server (step 1), once for each tree

[0027] , Then, the server sends these to the other applications that do not have the label (Application 2) such that they can compute the corresponding gradients (and hessians) histograms (step 2). Similar to the HFL case, in each round, communicating for each node, the applications send the histograms to the server (step 3), which then aggregates the histograms through concatenation i.e., grouping together the histograms of all attributes, to compute the node parameters (step 4). The best split (i.e., attribute-value pairs) or the prediction value if the current node is a leaf node. Finally, the applications receive the node parameters from the server and update the local models (step 5). Each party will end up with the same global ML model (e.g., the split value at the top is the same as the one on the left).

[0449] D. Threat Model and Assumptions

[0450] Following the majority of federated learning and microservice approaches, we make the following assumptions. First, the microservice applications are properly isolated and can only communicate with the central server through a secure channel. Second, the data is independently and identically distributed (HD) among all the applications. Third, while FL protects the privacy of the applications by not exchanging the raw data, potential information leaks or inference attacks on the exchanged information (e.g., histograms) may still be possible, and are assumed to be prevented, e.g., using homomorphic encryption or differential privacy. Also, following the security verification literature, we assume our solution is deployed by the microservice provider or owner who has reliable access to the required logs, databases, and configuration data, and the formal specification of security properties as well as the formal verification approach itself are both sound. Finally, as a security verification solution, our approach is only designed to identify security violations, and we assume it can work in tandem with other security solutions to attribute such violations to the root causes (e.g., vulnerabilities or attacks).

[0451] Under such assumptions, our in-scope threats include both external attackers who exploit existing vulnerabilities in the microservice architecture to violate security properties, and insiders such as cloud operators and tenants who cause misconfigurations violating those properties, as well as the provider or owner of a microservice application who may be curious to learn about other applications’ data. On the contrary, our out-of-scope threats encompass attacks that do not result in breaching any security properties, attacks launched by adversaries capable of eliminating the evidence of their attacks (e.g., logs and databases) or tampering with the cloud infrastructure or our solution itself, and attacks launched by malicious insiders such as cloud operators / tenants and microservice application providers / owners (e.g., deviating from the FL procedure, poisoning the training data with adversarial samples, and eavesdropping the communication channel).

[0452] III. HORIZONTAL FLFM (H-FLFM) METHODOLOGY

[0453] This section first presents an overview of our horizontal FLFM (H-FLFM) approach, and then details its components.

[0454] A. Overview

[0455] The horizontal case of FLFM (H-FLFM) is designed for verifying a security property across several microservice applications that share the same attributes, but have different data values, e.g., one application tends to have larger values than other applications for the same attribute. In such a case, as illustrated in our motivating example (Section I), the machine learning models of MLFM trained locally using each application’s own data may not be accurate enough due to data heterogeneity. Therefore, H-FLFM utilizes Horizontal Federated Learning (HFL) to allow the applications to collaboratively train a global ML model to more accurately reflect the collection of all applications’ data. As detailed in Section ll-C), HFL allows the global model to be trained without the need for sharing each application’s data either with the central authority, or between the applications themselves. Instead, only certain learning parameters will be exchanged between the applications and the central authority, thereby preserving the confidentiality and privacy for the applications.

[0456] At a high level, as demonstrated in Figure 5, H-FLFM has two stages. First, during the ML training stage, an iterative teacher (FM)-learner (ML) interaction (as detailed in Section ll-A) is utilized to train a local ML model using a small portion of the applications’ audit data. Subsequently, the learning parameters of each application are sent to, and aggregated by the central authority. The aggregated parameters are then sent back to the applications to refine their models for higher accuracy. Those steps are repeated until a pre-defined stopping condition is met. Second, in the ML application stage, the final ML model of each application is applied to the remaining local audit data (i.e., the data not used during training) to prioritize the verification of those data records that are more likely to violate the property. The remainder of this section provides more details and examples for our H-FLFM methodology.

[0457] B. Training Stage - Local Model Training

[0458] The local ML model training occurs concurrently at each microservice application following the iterative teacher (FM)-learner (ML) interaction introduced in Section ll-A. The goal is for the teacher to select a minimal yet representative (with respect to the current ML model) set of records in each iteration, such that the learner can obtain a relatively accurate ML model using a small amount of data. Figure 5 shows an overview of the horizontal FLFM approach. Specifically, as shown in Figure 5 (lower-right inside Application 1), in each teacher-learner iteration, the teacher employs a sampling method to select a small fixed-sized data sample from the audit data (depicted as Sampler) by applying the ML model received from the learner in the previous round (an initial ML model is provided for the first iteration). This sample is verified by the Formal verifier to label its records according to the verification results (depicted as Labeled data) before being sent to the learner. The learner adds this new sample of labeled data to the previously received ones to train a new local ML model, which is then sent back to the teacher for the next iteration. This iterative interaction ends when reaching a predefined condition (e.g., a fixed iteration count, or lack of significant improvement in the accuracy of the model).

[0459] Example 1 : Figure 6 (step 1 ) shows an example of the local ML training at both the Transportation company A and Transportation company B applications. For Transportation company A (lower middle), using the uncertainty sampling method, the sampler (inside the teacher block) selects a sample of size (m = 1), and assume data record (1) is selected. Then, the formal verifier verifies this record, and assume it assigns the (+) label to the record. On the other hand, assume the local DT model classifies this same record as (-). Therefore, record (1) is a FN record containing representative data, which is selected by the teacher to be part of D (which contains records to be sent to the learner, and removed from the audit data P). Since we assume a required sample size of (m = 1) in this example, the sample is sent to the learner and added to the existing training data (T), while the teacher empties its (D). The learner uses (T) to build a new (more accurate) local ML model, which is sent back to the teacher for the next iteration, until the iteration count has reached a predefined count (n). This happens similarly at the Transportation company B application in parallel (only the differences are highlighted in the figure).

[0460] C. Training Stage - Global Model Learning

[0461] The federated global model learning starts at the end of each iteration of the teacher (FM)- learner (ML) interaction. The goal is for the applications to send their ML model parameters to the central authority, who then aggregates those parameters and sends the result back for the applications to refine their local ML models. Specifically, Figure 5 (lower left inside Application 1 and top) illustrates those steps using a federated XGBoost classifier (detailed in Section ll-B). First, the applications send to the central authority their learning parameters, i.e., the gradients and hessians histograms (as detailed in Section ll-C). Second, the central authority performs an aggregation operation (i.e., summation of values within their respective value buckets in this case) on the gradient and hessian histograms received from all the applications to obtain a final histogram representation. The central authority then sends the final histogram back to each application. Third, each application uses the received histograms to update its local ML model to obtain a more accurate model better reflecting global knowledge. Finally, the updated local ML model is utilized by the next iterative teacher (FM)-learner (ML) interaction to locally train a new ML model. The central authority and the applications may repeat this process for several iterations, until a stopping condition is reached (e.g., a predefined iteration count, or when the histograms see no significant change between two consecutive iterations).

[0462] Example 2: Figure 6 shows an example of the horizontal FLFM training. Following Example 1 , Figure 6 (step 2 ) shows that, at the end of the nth iteration of the teacher-learner interaction, each application sends its local ML model parameters (i.e., gradient and hessian histograms) to the central authority (for clarity, the figure only shows the gradient histograms). Specifically, two gradient histograms, each with three gradient values i.e., (5, 21 , 7) and (3, 9, 6), are sent by the Transportation company A and Transportation company B applications, respectively. Next, step 3 shows the aggregation of the received gradient histograms at the central authority. Particularly, the aggregation (i.e., summation) results are represented in a histogram with the values (8, 30, 13), which are then sent back to the applications (step 4 ). Step 5 shows that each application uses the received aggregated gradient histograms to update its local model. If a pre-defined number (r) of aggregation iterations is not yet reached (step 6 ), the updated local model is provided to the teacher to trigger a new iteration of the teacher (FM)-learner (ML) interaction for local ML model training. Otherwise, the updated local model will be utilized by the ML application stage (Step 7 ).

[0463] D. Application Stage

[0464] As Figure 5 (bottom of Application 1) shows, the final ML model obtained from the ML training stage is applied to the remaining audit data (i.e., the data not used for the training) of each application in order to identify data records that are more likely to violate the given security property, namely, the “to be verified” subset, which is then given a higher priority for verification. On the other hand, the other records, i.e., the “not to be verified” subset, will either be verified afterwards, or not verified at all, depending on the use cases (discussed in Section VI).

[0465] IV. VERTICAL FLFM (V-FLFM) METHODOLOGY

[0466] This section first presents an overview of our vertical FLFM (V-FLFM) approach, and then details its components.

[0467] A. Overview

[0468] The vertical case of FLFM (V-FLFM) is designed for verifying a security property across several microservice applications that share the same data sample, but under different attributes. In such a case, as illustrated in our motivating example (Section I), each application lacks certain attributes, and thus the machine learning models of MLFM trained locally using each application’s limited collection of attributes would not be accurate due to data unavailability. Therefore, V-FLFM utilizes Vertical Federated Learning (VFL) to enable the applications to collaboratively train a global ML model that can more accurately reflect the collection of all applications’ attributes. Similar to HFL (Section I l-C), VFL allows the global model to be trained without the need for sharing data with other applications, with only a small amount of data and learning parameters exchanged with the central authority, thereby preserving confidentiality and privacy for the applications.

[0469] Similar to H-FLFM approach, V-FLFM also has two stages, i.e. , the ML training stage and the ML application stage, as depicted in Figure 7. Figure 7 shows an overview of the vertical FLFM approach. What is unique to V-FLFM is the fact that the formal verification can only be performed at the central authority by collecting all the attributes from the applications. Specifically, first, during the ML training stage, the sampler identifies a small representative data sample, which is sent to the central authority for labeling (utilizing the verifier). The labeled samples are then sent back to the corresponding applications and used by the Learner as a training dataset for building a global ML model. The Learner of each application calculates the learning parameters and sends them to the central authority for aggregation. The aggregated parameters are subsequently returned to the applications to refine their local models. Second, in the ML application stage, the final ML model of each application is applied to the remaining local audit data (i.e., the data not used during training) to prioritize the verification of those data records that are more likely to violate the property. Such data records are then sent to the central authority for verification utilizing the Formal verifier. The remainder of this section provides more details and examples for our V-FLFM methodology.

[0470] B. Training Stage - Training Data Building

[0471] V-FLFM requires the applications and the central authority to collaboratively obtain the training data and build the ML model (in contrast, H-FLFM does not involve the central authority for obtaining the training data). Specifically, as shown in Figure 7 (top-right inside Application 1), at the beginning of each iteration, the sampler interacts with the verifier (left inside Central authority) to build a training dataset. First, a sampling method is used to select a small representative data sample of fixed size from the audit data after applying the ML model built by the learner in the previous iteration (an initial ML model is provided for the first iteration). Second, since the data is vertically distributed, the attributes of each data record that are essential for the verification are gathered from the applications holding those attributes. The central authority then reassembles those samples into complete data records and verifies them using a formal verification approach. Thereafter, the data records labeled with the verification results are divided into data samples, and re-distributed to the corresponding applications. The learner of each application then adds this newly received data sample to its existing training data (i.e., the collection of all previous samples), and utilizes this enriched training data to build a new ML model using a vertical federated learning algorithm.

[0472] Example 3: Figure 8 is an example of the vertical FLFM training. Figure 8 shows an example of the ML training over data vertically distributed between two applications, i.e., Banking institution and Financial institution. First, in step 1 , the sampler selects a sample of size (m = 1), using the uncertainty sampling method, which is assumed to include the data record (1) in this example, for both applications. Next, in step 2 , the sample from each application is sent to the Verifier inside the central authority (omitted at the Financial institution side for simplicity). The Verifier reassembles those samples into a complete data record, and then verifies the record and labels it based on the verification result (step 3 ). Then, the labeled data record is divided into samples and sent back to the corresponding applications (step 4 ), which utilize those new samples to build a new ML model.

[0473] C. Training Stage - Global Model Learning

[0474] The federated global model learning starts when each application receives the new labeled sample. Figure 7 (lower left inside Application 1 and top) illustrates this using a vertical federated XGBoost classifier (detailed in Section ll-C). First, the VFL algorithm requires the application holding the labels to transmit them to the central authority, who then forwards these to the other applications for them to compute the corresponding gradients and hessians histograms (which is only performed once for each model, as detailed in Section ll-C). Second, the histograms are sent by the applications to the central authority for aggregation through concatenation (detailed in Section ll-C). The aggregated histograms are utilized to compute the node parameters, i.e., the best split or the prediction value if the current node is a leaf node, which are then sent back to the applications to update their local models. Finally, the updated local ML model is utilized by the Sampler to train a new ML model. This ML training process may be repeated for several iterations based on a predefined condition.

[0475] Example 4: Following Example 3, Figure 8 (step 5 ) shows that the two applications send their learning parameters, i.e., (4, 18, 12) and (6, 17, 10) (only the gradient histograms is shown for clarity), to the central authority. The histograms (step 6 ) are then concatenated by the Aggregator (inside the central authority), and used to compute the node parameters. Next, those parameters are sent back to the applications (step 7 ) to update their local models. The updated ML model is utilized by the next iteration of the ML training if the number of iterations (r) has not been reached; otherwise, it will be returned to be utilized by the ML application stage.

[0476] D. Application Stage

[0477] As Figure 7 (bottom of Application 1) shows, similar to H-FLFM, the final ML model obtained from the ML training stage is applied to the remaining audit data (i.e., the data not used for training) of each application to identify the “to be verified” subset (data records more likely to violate the given security property), which will be given a higher priority and sent first to the central authority for verification. On the other hand, the “not to be verified” subset will either be verified later, or not verified at all, depending on the use cases (discussed in Section VI).

[0478] V. IMPLEMENTATION

[0479] This section details our implementation of FLFM.

[0480] Architecture

[0481] Figure 9 overviews our implementation of FLFM (the FLFM architecture). Specifically, FLFM interacts with users to obtain the inputs including the security property to be verified and the system parameters, such as the number of iterations and the sample size (as detailed in Sections III and IV), and to deliver to users an audit report as the output. Furthermore, FLFM also interacts with the cloud environment hosting the microservice applications to acquire the necessary audit data for verification. The following details the components of FLFM.

[0482] Data Collection and Processing

[0483] This module (implemented in Python 3.6.9) collects audit data from the microservice-based applications and converts it into the necessary input formats for both the formal verifier and ML training.

[0484] FLFM Manager

[0485] This module (also implemented in Python 3.6.9) triggers either the horizontal or vertical FLFM approach based on the audit property and data distribution. Additionally, it manages and orchestrates the interactions among other modules for conducting data processing, data sampling, formal verification, ML training, etc., as detailed in Sections III and IV.

[0486] ML Model Learner

[0487] We utilize Python 3.6.9 and Scikit-learn 0.24.1 (an open source ML library written in Python) to implement this module. For both horizontal and vertical federated learning, we choose the XGBoost classifier

[0015] , a scalable tree boosting algorithm that has seen wide application in real- world for its high accuracy and low false positive rate, with many awards in ML and data mining competitions

[0028] ,

[0029] , We employ FedTree

[0027] , an FL system designed for tree-based models, to implement federated XGBoost. FedTree employs a histogram-sharing strategy for both horizontal and vertical FL. It facilitates distributed computing for practical FL deployment with configurable privacy techniques like Differential Privacy and Homomorphic Encryption, and supports standalone FL simulation on a single machine. Although many FL studies focus on neural networks, our work excludes them due to their widely recognized higher complexity and longer training time compared to traditional ML models

[0030] , which is not aligned with our main objective of reducing the overall delay before violations can be identified.

[0488] Aggregation

[0489] This module (implemented in Python 3.6.9) aggregates the learning parameters received from the microservice-based applications.

[0490] Sampler

[0491] We utilize the modAL framework

[0016] to implement sampling strategies within this module. modAL is an active learning framework for Python3, built on top of Scikitlearn

[0031] , which enables the rapid creation of active learning workflows with flexibility

[0016] , In our implementation, we opt for the uncertainty sampling strategy due to its superior computational efficiency compared to other strategies

[0018] , Moreover, our previous work

[0011] has demonstrated that combining uncertainty sampling with XGBoost achieves the highest verification performance.

[0492] Formal Verifier

[0493] We formalize the security properties along with the audit data as a Constraint Satisfaction Problem (CSP), a time-proven technique to express intricate problems. Leveraging CSP permits users to articulate a wide range of security properties (owing to its expressiveness) in a relatively simple manner, since CSP can facilitate the uniform representation of audit data and security properties, presenting them in a clear and understandable formalism, such as first-order logic (FOL)

[0032] ). As a future work, FLFM may also be integrated with other robust and efficient CSP solver algorithms, which can circumvent the costly state space traversal

[0033] to further enhance the scalability, particularly in larger environments.

[0494] After being formulated as a CSP problem, the security verification is performed using Sugar

[0017] , a well-established, award-winning SAT-based constraint solver (e.g., the global constraint categories at the International CSP Solver Competitions in 2008 and 2009

[0034] ). Sugar tackles a finite linear CSP by converting it into a SAT problem through the order encoding method, and then it solves the SAT problem using the MiniSat solver

[0035] , an efficient CDCL SAT solver recognized for its effectiveness in narrowing the search space

[0036] , A future direction is to adapt the FLFM framework to other verification methods (such as theorem proving, model checkers, temporal logic, and Catalog) based on the specific requirements of the verification tasks.

[0495] VI. EXPERIMENTS

[0496] This section first describes the investigated properties. Then it covers the experimental settings, use cases of our approach, and the datasets used. Finally, it presents our evaluation results for both H-FLFM and V-FLFM. A. Investigated Properties

[0497] Our approach can support the verification of various security or custom properties as long as they can be verified using the chosen formal method tool. To make our discussion more concrete, we present two example properties (which will be used to evaluate our approach later in this section).

[0498] Rate Limiting Property - Ensures that applications adhere to predefined thresholds for request rates, such as a specified number of requests that are allowed within a given time frame. It serves as a security mechanism to protect networks by regulating traffic flow, preventing excessive rates that could lead to congestion or overload, and mitigating risks such as API abuse through excessive calls

[0037] , Additionally, it safeguards systems from malicious activities like Denial of Service (DoS) attacks

[0038] and ensures fair resource allocation among services. Therefore, verifying rate limits is crucial for maintaining the security, stability, and quality of service in cloud-based networking environments.

[0499] In our work, we assume that the cloud provider hosts several applications for different clients and enforces traffic rate limits on certain applications (e.g., no more than 1 ,000 requests per second for banking applications). Our objective is to compare the actual request rate against ratelimiting policies to ensure the compliance of these applications. Specifically we verify the following:

[0500] Vid e Application! D, Vr e Requests, Vt e time : AppRequestCount(id, r, t) <= RateLimit (1) where AppRequestCount denotes the number of requests r made by an application with ID id at a specific time interval ending at time t, and RateLimit is a constant representing the rate limit.

[0501] Access Control Property.

[0502] In our work, we assume that two organizations (each with its own MS applications) work on a shared project. One of them is the project lead (say organization A) hence it holds higher priority e.g., owns sensitive data for the project, or manages role assignments and access control (e.g., issuing permissions). On the other hand, the other organization (say organization B) uses the data or shared resources provided by “organization A” and maintains its own users access information. For instance, the two organizations could be a bank and financial institution that performs some tasks on behalf of the bank, such as risk assessment, credit scoring, or fraud detection.

[0503] Our objective is to ensure the compliance of established access control policies across these applications. For instance, one such policy might state: ’’Only users with the role Analyst from Organization B are permitted to access Shared ResourceX, and only if they are using a device that has been explicitly approved and registered by organization A”. Which would be represented as follows:

[0504] Vid e ResourcelD, Vdev e DevicelD, Vur e Roles : ResourcellserRole(id, ur) A (ur == “Analyst”) A UsedDevicelD(id, dev) A ApprovedDevices(id, dev) (2) where ResourcellserRole represents the role (ur) of the user who accessed the SharedResourceX identified by its ID (id), UsedDevicelD represents the used device (dev) to access resource (id), and Approved Devices represent the approved devices by organization A to access resource (id) from.

[0505] B. Experimental Settings and Datasets

[0506] Experimental Settings

[0507] All experiments are performed on a SuperServer 6029P-WTR running the Ubuntu 18.04 operating system equipped with Intel(R) Xeon(R) Bronze 3104 CPU@1.70GHz and 128GB of RAM without GPUs. All the experiments are performed using Sugar

[0017] as the formal verifier, FedTree

[0027] standalone simulator to simulate the federated settings, and Python 3.6.9 with Scikit- learn 0.24.1 ML packages for the ML method (i.e. , XGBoost classifier

[0015] ). For all experiments, we use the default parameters for the ML models. Each experiment is repeated 1 ,000 times to obtain the average results.

[0508] We evaluate FLFM under two use cases, one for the shortest verification time and the other for more complete results. First, in the partial verification use case, FLFM will stop after verifying all the “to be verified” records (i.e., the “not to be verified” records will not be verified, as detailed in Sections lll-D and IV-D). This use case may apply when the user wants to find violations as quickly as possible (but not necessarily all the violations). Second, the priority-based verification use case means that FLFM will not stop after verifying the “to be verified” records, but instead will continue to verify the remaining (“not to be verified”) records. This use case applies when the user requires complete verification results (at the cost of a longer running time).

[0509] Datasets

[0510] To evaluate the performance of FLFM in the horizontal case (H-FLFM), we generate six sets of datasets, with each set containing two datasets, one for each application. Each dataset contains 12,500 data records for verifying the rate limiting property (P1 henceforth). Since data heterogeneity is the key factor affecting the ML accuracy in the horizontal case, the six sets of datasets are designed to have an increasing level of heterogeneity, e.g., the last set has 100% heterogeneity, i.e., the two applications do not share any common data values. Finally, each dataset contains around 10% of (uniformly distributed) records that violate the corresponding property.

[0511] For the vertical case (V-FLFM), we also generate six sets of datasets for both applications. Each dataset contains 5,000 data records for verifying the access control property (P2 henceforth). Unlike the horizontal case (where data heterogeneity is the key factor), the ML accuracy in V-FLFM is mainly affected by the missing attributes in each application. Each subsequent set of datasets is designed to have 10% more records that result in false prediction by the ML model due to the lack of attributes (e.g., data records that are identified by ML as “to be verified” but do not violate the given property). Finally, similar to the horizontal case, each dataset also contains around 10% of (uniformly distributed) records that violate the corresponding property.

[0512] C. H-FLFM Experimental Results

[0513] We evaluate the H-FLFM performance and how it may be impacted by data heterogeneity and other parameters. We also compare the performance of H-FLFM with a state-of-the-art approach, MLFM

[0011] , which runs at each application to construct an ML model and identify the data records that violate the given property based on the local data. Table I lists the parameters evaluated in those experiments.

[0514] TABLE I: Main parameters evaluated in the experiments.

[0515] Impact of Data Heterogeneity. The first set of experiments evaluates the impact of different levels of data heterogeneity on the performance of H-FLFM in comparison to MLFM, with respect to the execution time and the recall, respectively. This experiment is performed using the best performing parameters of MLFM as reported in

[0011] (i.e., XGBoost with uncertainty sampling, 20% training data, sample size m = 250, and iteration count n = 10) for both MLFM and H-FLFM.

[0516] Figure 10 shows the execution time (in hours) (a) and recall (b) for identifying violations in datasets with different levels of heterogeneity by H-FLFM and by MLFM

[0011] ,

[0517] First, Figure 10 (a) shows the execution time for identifying violations (under the prioritybased verification use case) for both H-FLFM and MLFM on datasets with different levels of data heterogeneity (ranging from 0% to 100%). The results show that H-FLFM is faster than MLFM across all levels of data heterogeneity, with an average of around 13% better performance for H- FLFM. This is expected as the federated global model learning of H-FLFM allows the applications to build more accurate ML models and consequently to prioritize the verification of data records more effectively than MLFM does. The results also show a similar trend for both approaches, i.e., as the level of data heterogeneity increases, the execution time first increases and then decreases passing around 60% data heterogeneity. This can be explained by a similar trend in the accuracy of the ML models, as detailed below.

[0518] Second, Figure 10 (b) shows the recall values for both HFLFM and MLFM under different levels of data heterogeneity. The results show that H-FLFM achieves higher recall values (i.e., more effective in identifying the violations) than MLFM across all levels of heterogeneity. The results also show a similar trend for both approaches, i.e., as the level of data heterogeneity increases, the recall values first decrease and then increase. This can be explained by the fact that a medium level of heterogeneity (e.g., 40%) means the local data of an application contains an imbalanced mixture of data from different ranges, which makes the ML training more challenging; conversely, the ML training is easier either at a very low level of heterogeneity since the local data has a well balanced mixture of data from different ranges, or at a very high level of heterogeneity since the local data is mostly from the same range. This also explains the diminishing difference between H-FLFM and MLFM as the heterogeneity approaches 100% (i.e., the local model is good enough on local data from the same range). In the subsequent experiments, we choose datasets with a high heterogeneity level (i.e., 80%) since this is the most challenging case for H-FLFM (i.e., with the minimum benefit compared to MLFM).

[0519] Impact of Parameters

[0520] The goal of this set of experiments is to study the impact of the H-FLFM parameters as listed in Table I. Figure 11 shows the execution time of H-FLFM (in hours) for different sample sizes and for various numbers of iterations (aggregation and local iterations) (a) and the execution time (in minutes) of HFLFM using the best performing parameters (i.e. , m = 250 and n = 10), while varying the number of aggregation iterations and compared to the execution time of MLFM using the same applicable parameters (b)

[0521] First, Figure 11 (a) shows the effect of the sample size under various numbers of both the local iteration (n) and global (aggregation) iteration (r), where we choose n = r (i.e., each local iteration is followed by an aggregation).

[0522] With respect to the effect of sample size, the results show that, with the sample size increasing (i.e., more training data is employed during each iteration) from 0 to 250 records, the HFLFM performance improves owing to the enhanced accuracy of the ML model, where the lowest execution time for HFLFM is achieved when the sample size reaches around 250, independently of the number of iterations. The improvement starts to diminish passing 250 records, since with larger sample sizes, the verification time during the training stage becomes more dominant (compared to the time saved during the application stage), leading to overall a longer time.

[0523] With respect to the effect of the number of iterations, the results show that, for any given sample size, the execution time of H-FLFM is the lowest under a medium number of iterations (e.g., 10 iterations), while a smaller number (e.g., 5 iterations) leads to the highest execution time. This can be explained by the fact that the increase in the number of iterations initially leads to more accurate ML models (as more training data is used) and consequently a lower execution time, while further increase in the number of iterations reverses the trend, since the accuracy improvement will diminish and the increase in training time due to the additional iterations will outweigh the time saved in the ML application stage. Therefore, we can conclude with the optimal H-FLFM parameters of (m = 250, n = 10, and r = 10).

[0524] Figure 11 (b) further studies the effect of the number of aggregation iterations on the execution time (for priority-based verification) of H-FLFM in comparison to MLFM, using the dataset of 80% heterogeneity. Here we fix the sample size and the number of local iterations at the best performing parameters of H-FLFM, i.e., (m = 250 and n = 10), while varying the number of aggregation iterations by performing the aggregation after multiple local iterations. The results show that increasing the number of aggregation iterations can significantly reduce the execution time, e.g., from 76 minutes for 1 aggregation to less than 50 minutes for 10 aggregations (i.e., aggregation is performed after every local iteration). The results also show that H-FLFM is always faster than MLFM, and the difference grows almost linearly in the number of aggregations, e.g., H-FLFM is 36.7% faster than MLFM with 10 aggregation iterations.

[0525] Performance and Robustness

[0526] The goal of this set of experiments is to further study the performance of H-FLFM in terms of execution time in comparison to MLFM, and the robustness in handling new data with different characteristics. Figure 12 shows the execution time (in minutes) for identifying different percentages of violations by H-FLFM and MLFM (a), and shows the time (in minutes) for identifying different percentages of violations by H-FLFM under different scenarios (b).

[0527] First, Figure 12 (a) compares the execution time of H-FLFM to MLFM that is needed to identify different percentages of violation (for the priority-based verification) using the dataset of 80% heterogeneity and the best performing parameters (i.e., m = 250, n = 10, and r = 10). The results show that H-FLFM is always faster than MLFM in identifying violations, and HFLFM takes around 39% less time than MLFM for identifying all the violations.

[0528] Second, Figure 12 (b) studies the robustness of H-FLFM and the generality of its ML model for handling new data records that have different distributions or data ranges from the local data. Specifically, Local data in the figure refers to the normal scenario used in previous experiments, i.e., H-FLFM applies its trained ML model to data records with similar distributions and value ranges as the training data. In addition, we test H-FLFM under two more challenging scenarios, i.e., Future reverse data which means the ML model trained at one application is applied to data records with distributions and value ranges similar to the other application, and Global data which means the ML model is applied to data records that have mixed distributions and value ranges from both applications. As expected, H-FLFM performs the best for the local data scenario. The performance becomes worse under the Global data scenario, and decreases further under the Future reverse data scenario. Nonetheless, even in the last case, by taking approximately 60 minutes, H-FLFM is still around 21% faster than MLFM (depicted in Figure 12 (a), which requires around 76 minutes).

[0529] D. V-FLFM Experimental Results

[0530] We evaluate the V-FLFM performance and how it may be impacted by different parameters. We also compare the performance of V-FLFM with the baseline approach (i.e., applying MLFM on the local data, without the federated global learning step of V-FLFM).

[0531] Impact of Parameters

[0532] As mentioned in Section IV, under the vertical case of FLFM (V-FLFM), the formal verification is performed at the central authority by collecting all the attributes from the applications. Therefore, one aspect of the VFLFM performance is the percentage of data records that need to be shared with the central authority. Figure 13 shows the percentage of records shared with the central authority by V-FLFM and the baseline approach for the partial verification case (a), and shows the FN rate of V-FLFM and the baseline approach for the partial verification case (b). Specifically, Figure 13 (a) shows the impact of the V-FLFM parameters (i.e., the sample size and the number of iterations) on the percentage of shared records for the partial verification case. It also compares V-FLFM to the baseline approach under the same parameters. The results show that V-FLFM performs better than the baseline (in terms of a lower percentage of shared records) in most cases. For V-FLFM, the percentage of shared records initially decreases until the sample size reaches around 80. This shows that a larger sample size allows V-FLFM to be more effective in identifying violations due to the increasing accuracy of its ML model. As the sample size further increases, the trend reverses, i.e., the percentage of shared records also starts to increase, since the improvement in model accuracy diminishes while the increase in the percentage of shared records due to larger samples becomes more dominant. The results also show that a larger number of iterations generally means more shared records, and hence a single iteration (with the sample size of (80)) would yield the lowest percentage of shared records.

[0533] In addition to the percentage of shared records, another aspect of the V-FLFM performance is the false negative (FN) rate, i.e., the percentage of records that violate the property, but are not shared with the central authority due to inaccuracy of the ML model. Specifically, Figure 13 (b) shows the FN rate of both V-FLFM and the baseline approach for the partial verification case. The results show that, contrary to the aforementioned trend about shared records (i.e., more iterations lead to more shared records), the FN rate of V-FLFM decreases with more iterations, since the accuracy of the ML model generally increases with more iterations of training. The results also show that different combinations of the sample size and number of iterations can achieve similar FN rates. Therefore, the best combination of the parameters could depend on the users’ preferences (e.g., less shared records or lower FN rate). In our experiments, we choose the sample size of (120) and iteration count of (5) as the optimal parameters, which means our approach shares 52.23% fewer records compared to the baseline approach, while achieving a 52.78% lower FN rate compared to the baseline approach.

[0534] Figure 14 shows the percentage of records shared with the central authority by V-FLFM and the baseline approach for the priority-based verification case (a), and shows the execution time (in minutes) for identifying different percentages of violations by V-FLFM and the baseline approach (b).

[0535] Figure 14 (a) shows the percentage of records that are shared by V-FLFM and the baseline approach for the priority-based verification (note that the count of records is taken as soon as all the violations are identified, and also we do not evaluate the FN rate since it is always zero in this case). The results show that both V-FLFM and the baseline approach lead to more shared records than in the partial verification case (due to the need for verifying the “not to be verified” records). VFLFM shows a similar trend as before, i.e., the percentage of shared records initially decreases due to more accurate ML models (with the lowest value of around (13.7%) under the sample size of (120) and the number of iterations of (1)), and then the trend reverses as the increase in shared records due to larger samples becomes more dominant.

[0536] Performance

[0537] The goal of this set of experiments is to further study the performance of V-FLFM using the best performing parameters in terms of both the execution time and shared records in comparison to the baseline approach. First, Figure 14 (b) compares the execution time of V-FLFM to the baseline approach for identifying different Percentages of violations (for the priority-based verification) using the best performing parameters (i.e. , m =120 and r = 5). The results show that V-FLFM outperforms the baseline in all cases, e.g., V-FLFM can identify all the violations in around 17.5 minutes, which takes the baseline around 94 minutes, i.e., V-FLFM takes around 81.46% less time to identify the same percentage of violations.

[0538] Figure 15 shows the percentage of shared records by V-FLFM and the baseline approach for partial verification (a) and priority-based verification (b) using different datasets, and shows the FN rate for the partial verification case using different datasets (c).

[0539] Figure 15 compares the percentage of shared records by V-FLFM and the baseline approach using the best performing parameters (i.e., m =120 and r = 5) on six different datasets. As mentioned in Section Vl-B, each subsequent dataset contains 10% more records that are mistakenly identified by ML as “to be verified”, i.e., false violations (while all the datasets contain 10% of true violations). Figure 15 (a) shows that the increase in false violations more significant affects the baseline approach than V-FLFM for the partial verification, and V-FLFM outperforms the baseline approach on all the datasets (on average, V-FLFM shares almost 44.5% less records than the baseline approach). Figure 15 (b) shows similar results for the priority-based verification case. Although both approaches lead to more shared records in this case, V-FLFM shares almost 62.67% less records on average than the baseline approach over all the datasets. Finally, Figure 15 (c) shows that the FN rate of V-FLFM increases when the number of false violations increases (which cause the ML model to become less accurate) although it remains to be lower than the baseline approach.

[0540] VII. RELATED WORK

[0541] Existing security solutions for the microservice architecture mostly focus on verifying the correctness of the microservices interactions (e.g., [6],

[0012] ,

[0013] ), anomaly detection (e.g.,

[0039] ,

[0040] ), access control for microservices (e.g., [5],

[0041] ,

[0042] ,

[0043] ), or performance analysis (e.g.,

[0044] ). Those works employ either formal methods (such as [6],

[0012] ,

[0013] ), graph-based methods (such as

[0039] , [5],

[0044] ,

[0043] ), ML methods (such as

[0040] ), sidecar-based methods (such as

[0041] ), or token-based methods (such as

[0042] ). In contrast to those existing solutions, we tackle two unique challenges in the microservice architecture, i.e., the inherent complexity of formal security verification solutions may prevent them from handling the sheer scale of microservice applications, which can cause considerable delay in identifying security violations, and collecting data from all the microservice applications to perform security verification at a central location may be infeasible due to data confidentiality and privacy concerns.

[0542] Federated learning has been extensively leveraged in many security applications, such as anomaly (e.g.,

[0045] ,

[0046] ,

[0047] ) and intrusion detection (e.g.,

[0048] ,

[0049] ), mostly within the Internet of Things (loT) architectures. To the best of our knowledge, there do not exist solutions that employ federate learning for compliance verification (directly or indirectly), nor does any work combine federated learning with formal methods for faster verification as we propose in this work.

[0543] Security verification solutions have also been developed for various virtual infrastructures, such as NFV, cloud, and SDN (e.g., [9],

[0050] ,

[0010] ,

[0051] ,

[0011] ,

[0052] ,

[0053] ,

[0054] ,

[0055] ,

[0056] ,

[0057] ). Most of the FM-based solutions (e.g., [9],

[0050] ,

[0010] ,

[0051] ,

[0052] ,

[0053] ,

[0054] ,

[0055] ) do not explicitly tackle the delay in verification (so they may benefit from FLFM in this regard), except for NOD [9], which is specifically optimized for large applications (NOD can potentially benefit from our approach, as shown in

[0011] ), and MLFM

[0011] , which is less efficient than our work, as shown through experiments in Section VI. Unlike formal methods, custom algorithms (e.g., [8] and

[0058] ) benefit from enhanced efficiency for specific properties; however, they often lack the expressiveness found in formal method-based approaches. The proactive approach (e.g.,

[0056] ,

[0057] ) optimizes the verification time by performing the verification in advance based on predicted events, which is parallel to and can be integrated with our approach.

[0544] Table II summarizes the comparison between existing solutions and FLFM. The first and second columns enlist existing works and their objectives. The next two columns compare their applications and verification methods. The following two columns compare the coverage in terms of whether they work on a single microservice (MS-level) or they can support multiple microservice applications (App-level) as addressed in our work. The last column enlists the type of utilized federated learning (horizontal or vertical), if applicable.

[0545]

[0546] TABLE II: Summary of existing solutions.

[0547] VIII. CONCLUSION We have presented FLFM, a novel approach designed to more quickly identify security violations for microservice applications. FLFM combined the efficiency and privacy-friendliness of federated learning (FL) with the rigor of formal methods (FM). In particular, in the training stage, each microservice application first sampled a small yet representative sample of its configuration data and labeled this sample based on their FM verification results. Then, the applications leveraged federated learning to jointly train a global ML model based on the collection of their samples. In the application stage, the global ML model was then applied to guide the applications to prioritize more suspicious data for earlier verification. We provided detailed methodologies for both the horizontal and vertical FL cases, and our experimental results demonstrated that FLFM outperforms the performance of the baseline approach.

[0548] REFERENCES

[0549] [1] D. S. Linthicum, “Practical use of microservices in moving workloads to the cloud,” IEEE Cloud Computing, vol. 3, no. 5, pp. 6-9, 2016. [2] T. Hoff, “Lessons learned from scaling uber to 2000 engineers, 1000 services, and 8000 git repositories,” available at: https: / / qoo.gL Last accessed 6 November 2023.

[0550] [3] M. Benedict and V. Charanya, “How we built a metering and chargeback system to incentivize higher resource utilization of twitter infrastructure,” available at: http: / / bit.ly / 3aETIqs. Last accessed 6 November 2023.

[0551] [4] T. MAURO, “Adopting Microservices at Netflix: Lessons for Architectural Design,” available at: https: / / goo.gl / Dyrtvl. Last accessed 6 November 2023.

[0552] [5] X. Li, Y. Chen, Z. Lin, X. Wang, and J. H. Chen, “Automatic policy generation for {InterService} access control of microservices,” in 30thUSENIX Security Symposium (USENIX Security 21), 2021 , pp. 3971-3988.

[0553] [6] A. Panda, M. Sagiv, and S. Shenker, “Verification in the age of microservices,” in Proceedings of the 16th Workshop on Hot Topics in Operating Systems, 2017, pp. 30-36.

[0554] [7] K. Jayaraman, N. Bjorner, G. Outhred, and C. Kaufman, “Automated analysis and debugging of network connectivity policies,” Microsoft Research, pp. 1-11 , 2014.

[0555] [8] P. Kazemian, M. Chang, H. Zeng, G. Varghese, N. McKeown, and S. Whyte, “Real time network policy checking using header space analysis,” in 10th {USENIX} Symposium on Networked Systems Design and Implementation (NSDI’13), 2013, pp. 99-111.

[0556] [9] N. P. Lopes, N. Bjorner, P. Godefroid, K. Jayaraman, and G. Varghese, “Checking beliefs in dynamic networks,” in 12th {USENIX} Symposium on Networked Systems Design and Implementation (NSDI’15), 2015, pp. 499-512.

[0557]

[0010] A. Oqaily, L. Sudershan, Y. Jarraya, S. Majumdar, M. Zhang, M. Pourzandi, L. Wang, and M. Debbabi, “NFVGuard: Verifying the Security of Multilevel Network Functions Virtualization (NFV) Stack,” in 2020 IEEE International Conference on Cloud Computing Technology and Science. IEEE, 2020, pp. 33-40.

[0558]

[0011] A. Oqaily, Y. Jarraya, L. Wang, M. Pourzandi, and S. Majumdar, “Mlfm: Machine learning meets formal method for faster identification of security breaches in network functions virtualization (nfv),” in Computer Security-ESORICS 2022: 27th European Symposium on Research in Computer Security, Copenhagen, Denmark, September 26-30, 2022, Proceedings, Part III. Springer, 2022, pp. 466-489.

[0559]

[0012] X. Meng, X. Duan, W. Tao, Y. Luan, J. Zhang, and D. Wu, “Modeling and verification of industrial microservice architecture based on formal methods,” in 2021 China Automation Congress (CAC). IEEE, 2021 , pp. 3776-3780.

[0560]

[0013] F. Dai, H. Chen, Z. Qiang, Z. Liang, B. Huang, and L. Wang, “Automatic analysis of complex interactions in microservice systems,” Complexity, vol. 2020, pp. 1-12, 2020.

[0561]

[0014] A. Souri, N. J. Navimipour, and A. M. Rahmani, “Formal verification approaches and standards in the cloud computing: a comprehensive and systematic review,” Computer Standards & Interfaces, vol. 58, pp. 1-22, 2018.

[0562]

[0015] T. Chen and C. Guestrin, “Xgboost: A scalable tree boosting system,” in Proceedings of the 22nd ACM SIGKDD international conference on knowledge discovery and data mining, 2016, pp. 785-794.

[0563]

[0016] T. Danka and P. Horvath, “modAL: A modular active learning framework for Python,” arXiv preprint arXiv: 1805.00979, 2018.

[0564]

[0017] N. Tamura and M. Banbara, “Sugar: A CSP to SAT translator based on order encoding,” Proceedings of the Second International CSP Solver Competition, 2008.

[0565]

[0018] B. Settles, “Active learning literature survey,” 2009.

[0566]

[0019] L. Li, Y. Fan, M. Tse, and K.-Y. Lin, “A review of applications in federated learning,” Computers & Industrial Engineering, vol. 149, p.106854, 2020.

[0567]

[0020] G. D. P. Regulation, “General data protection regulation (gdpr),” Intersoft Consulting, Accessed in October, vol. 24, no. 1 , 2018.

[0568]

[0021] P. F. Edemekong, P. Annamaraju, and M. J. Haydel, “Health insurance portability and accountability act,” 2018.

[0569]

[0022] E. Goldman, “An introduction to the California consumer privacy act (ccpa),” Santa Clara Univ. Legal Studies Research Paper, 2020.

[0570]

[0023] Q. Yang, Y. Liu, T. Chen, and Y. Tong, “Federated machine learning: Concept and applications,” ACM Transactions on Intelligent Systems and Technology (TIST), vol. 10, no. 2, pp. 1-19, 2019.

[0571]

[0024] K. Cheng, T. Fan, Y. Jin, Y. Liu, T. Chen, D. Papadopoulos, and Q. Yang, “Secureboost: A lossless federated learning framework,” IEEE Intelligent Systems, vol. 36, no. 6, pp. 87-98, 2021.

[0572]

[0025] Z. Tian, R. Zhang, X. Hou, J. Liu, and K. Ren, “Federboost: Private federated learning for gbdt,” arXiv preprint arXiv:2011.02796, 2020.

[0573]

[0026] Y. J. Ong, Y. Zhou, N. Baracaldo, and H. Ludwig, “Adaptive histogrambased gradient boosted trees for federated learning,” arXiv preprint arXiv:2012.06670, 2020.

[0574]

[0027] Q. Li, Z. Wu, Y. Cai, Y. Han, C. M. Yung, T. Fu, and B. He, “Fedtree: A federated learning system for trees,” in Proceedings of Machine Learning and Systems, 2023.

[0575]

[0028] Z. Chen, F. Jiang, Y. Cheng, X. Gu, W. Liu, and J. Peng, “XGBoost classifier for DDoS attack detection and analysis in SDN-based cloud,” in IEEE international conference on big data and smart computing (BigComp), 2018, pp. 251-256.15

[0576]

[0029] F. Neutatz, M. Mahdavi, and Z. Abedjan, “Ed2: A case for active learning in error detection,” in Proceedings of the 28th ACM International Conference on Information and Knowledge Management, 2019, pp. 2249-2252.

[0577]

[0030] P. Maji and R. Mullins, “On the reduction of computational complexity of deep convolutional neural networks,” Entropy, vol. 20, no. 4, p. 305, 2018.

[0578]

[0031] O. Kramer, “Scikit-learn,” in Machine learning for evolution strategies. Springer, 2016, pp. 45-53.

[0579]

[0032] M. Ben-Ari, Mathematical logic for computer science. Springer Science & Business Media, 2012.

[0580]

[0033] I. Sassi, S. Anter, and A. Bekkhoucha, “A graph-based big data optimization approach using hidden markov model and constraint satisfaction problem,” Journal of Big Data, vol. 8, no. 1 , pp. 1-29, 2021.

[0581]

[0034] “Sugar: a SAT-based Constraint Solver,” Last accessed

[0582] 8 November 2021.

[0583]

[0035] N. Een and N. S ' orensson, “An extensible sat-solver,” in ” International conference on theory and applications of satisfiability testing. Springer, 2003, pp. 502-518.

[0584]

[0036] W. Gong and X. Zhou, “A survey of sat solver,” in Proceedings of AIP Conference, vol. 1836, no. 1. AIP Publishing LLC, 2017, p. 020059.

[0585]

[0037] A. El Malki, U. Zdun, and C. Pautasso, “Impact of api rate limit on reliability of microservices-based architectures,” in 2022 IEEE International Conference on Service-Oriented System Engineering (SOSE). IEEE, 2022, pp. 19-28.

[0586]

[0038] J. Castro, N. Laranjeiro, and M. Vieira, “Detecting dos attacks in microservice applications: Approach and case study,” in Proceedings of the 11th Latin-American Symposium on Dependable Computing, 2022, pp. 73-78.

[0587]

[0039] M. M. Ghorbani, F. F. Moghaddam, M. Zhang, M. Pourzandi, K. K. Nguyen, and M. Cheriet, “Malchain: Virtual application behaviour profiling by aggregated microservice data exchange graph,” in 2020 IEEE International Conference on Cloud Computing Technology and Science (CloudCom). IEEE, 2020, pp. 41-48.

[0588]

[0040] M.-O. Pahl and F.-X. Aubet, “All eyes on you: Distributed multidimensional iot microservice anomaly detection,” in 2018 14th International Conference on Network and Service Management (CNSM). IEEE, 2018, pp. 72-80.

[0589]

[0041] C. Meadows, S. Hounsinou, T. Wood, and G. Bloom, “Sidecar-based path-aware security for microservices,” in Proceedings of the 28th ACM Symposium on Access Control Models and Technologies, 2023, pp. 157-162.

[0590]

[0042] A. Venckauskas, D. Kukta, S. Grigaliunas, and R. Bruzgiene, “Enhancing microservices security with token-based access control method. 23 (6), 3363,” 2023.

[0043] M.-O. Pahl, F.-X. Aubet, and S. Liebald, “Graph-based iot microservice security,” in NOMS 2018-2018 I EEE / IFI P Network Operations and Management Symposium. IEEE, 2018, pp. 1-3.

[0591]

[0044] Z. Zhang, M. K. Ramanathan, P. Raj, A. Parwal, T. Sherwood, and M. Chabbi, “{CRISP}: Critical path analysis of {Large-Scale} microservice architectures,” in 2022 USENIX Annual Technical Conference (USENIX ATC 22), 2022, pp. 655-672.

[0592]

[0045] V. Mothukuri, P. Khare, R. M. Parizi, S. Pouriyeh, A. Dehghantanha, and G. Srivastava, “Federated-learning-based anomaly detection for iot security attacks,” IEEE Internet of Things Journal, vol. 9, no. 4, pp. 2545-2554, 2021.

[0593]

[0046] Y. Zhao, J. Chen, D. Wu, J. Teng, and S. Yu, “Multi-task network anomaly detection using federated learning,” in Proceedings of the 10thinternational symposium on information and communication technology, 2019, pp. 273-279.

[0594]

[0047] Y. Liu, S. Garg, J. Nie, Y. Zhang, Z. Xiong, J. Kang, and M. S. Hossain, “Deep anomaly detection for time-series data in industrial iot: A communication-efficient on-device federated learning approach,” IEEE Internet of Things Journal, vol. 8, no. 8, pp. 6348-6358, 2020.

[0595]

[0048] D. C. Attota, V. Mothukuri, R. M. Parizi, and S. Pouriyeh, “An ensemble multi-view federated learning intrusion detection for iot,” IEEE Access, vol. 9, pp. 117 734-117 745, 2021.

[0596]

[0049] Z. He, J. Yin, Y. Wang, G. Gui, B. Adebisi, T. Ohtsuki, H. Gacanin, and H. Sari, “Edge device identification based on federated learning and network traffic feature engineering,” IEEE Transactions on Cognitive Communications and Networking, vol. 8, no. 4, pp. 1898-1909, 2021.

[0597]

[0050] G. Marchetto, R. Sisto, J. Yusupov, and A. Ksentini, “Virtual network embedding with formal reachability assurance,” in 14th International Conference on Network and Service Management, 2018, pp. 368-372.

[0598]

[0051] S. Spinoso, M. Virgilio, W. John, A. Manzalini, G. Marchetto, and R. Sisto, “Formal verification of virtual network function graphs in an sp-devops context,” in European Conference on Service-Oriented and Cloud Computing. Springer, 2015, pp. 253-262.

[0599]

[0052] T. Madi, Y. Jarraya, A. Alimohammadifar, S. Majumdar, Y. Wang, M. Pourzandi, L. Wang, and M. Debbabi, “ISOTOP: auditing virtual networks isolation across cloud layers in OpenStack,” ACM Transactions on Privacy and Security (TOPS), vol. 22, no. 1 , pp. 1-35, 2018.

[0600]

[0053] T. Madi, S. Majumdar, Y. Wang, Y. Jarraya, M. Pourzandi, and L. Wang, “Auditing security compliance of the virtualized infrastructure in the cloud: Application to OpenStack,” in Proceedings of the Sixth ACM Conference on Data and Application Security and Privacy, 2016, pp. 195-206.

[0601]

[0054] S. Majumdar, T. Madi, Y. Wang, Y. Jarraya, M. Pourzandi, L. Wang, and M. Debbabi, “Security compliance auditing of identity and access management in the cloud: Application to OpenStack,” in IEEE 7thInternational Conference on Cloud Computing Technology and Science,

[0602] 2015, pp. 58-65.

[0603]

[0055] - , “User-level runtime security auditing for the cloud,” IEEE Transactions on

[0604] Information Forensics and Security, vol. 13, no. 5, pp. 1185-1199, 2017.

[0056] S. Majumdar, Y. Jarraya, T. Madi, A. Alimohammadifar, M. Pourzandi, L. Wang, and

[0605] M. Debbabi, “Proactive verification of security compliance for clouds through pre-computation: Application to OpenStack,” in European Symposium on Research in Computer Security. Springer,

[0606] 2016, pp. 47-66.

[0607]

[0057] S. Majumdar, Y. Jarraya, M. Oqaily, A. Alimohammadifar, M. Pourzandi, L. Wang, and M. Debbabi, “LeaPS: Learning-based proactive security auditing for clouds,” in European Symposium on Research in Computer Security. Springer, 2017, pp. 265-285.

[0608]

[0058] Y. Wang, T. Madi, S. Majumdar, Y. Jarraya, A. Alimohammadifar, M. Pourzandi, L. Wang, and M. Debbabi, “TenantGuard: Scalable runtime verification of cloud-wide VM-level network isolation,” in The Network and Distributed System Security Symposium, 2017.

Claims

CLAIMS1. A method performed by a distributed node in a distributed system, for facilitating formal verification of compliance of a security property in the distributed system, the method comprising: determining whether a distributed dataset represents a horizontal distribution of datapoints in the distributed system or a vertical distribution of datapoints in the distributed system, wherein a plurality of datapoints forming a distributed dataset are distributed amongst a plurality of distributed nodes in the distributed system, wherein each datapoint represents an instance to be verified as to its compliance to the security property, and wherein the distributed node has access to a local subset of the distributed dataset; iteratively performing a number of operations, for a predetermined number of iterations N, to form a training dataset comprising a number of datapoints of the local subset, and to obtain a Machine Learning, ML, model for predicting violation of the security property; forming a modified local subset comprising the datapoints of the local subset that are absent from the training dataset; classifying, using the ML model, each of the datapoints of the modified local subset into one of a first subset and a second subset, wherein the first subset includes datapoints that are predicted as having violating characteristics with respect to the security property, and the second subset includes datapoints that are predicted as having non-violating characteristics with respect to the security property; and responsive to determining that the distributed dataset represents a horizontal distribution of datapoints: formally verifying whether each datapoint in the first subset violates the security property, and generating a list of datapoints in the first subset that violate the security property; or responsive to determining that the distributed dataset represents a vertical distribution of datapoints, transmitting the first subset to a central node in the distributed system, wherein the central node is configured to formally verify whether each datapoint in the first subset violates the security property and to generate a list of datapoints in the first subset that violate the security property.

2. The method of claim 1 , wherein, prior to iteratively performing the number of operations, the method further comprises: selecting, at the distributed node, an initial training set of datapoints, or receiving, from the central node, an initial training set of datapoints; and training the ML model using the initial training set of datapoints.

3. The method of claim 1 or 2, wherein, in response to determining that the distributed dataset represents a horizontal distribution of datapoints, the method further comprises: formally verifying whether each datapoint in the second subset violates the security property, and generating a list of datapoints in the second subset that violate the security property.

4. The method of claim 1 or 2, wherein, in response to determining that the distributed dataset represents a vertical distribution of datapoints, the method further comprises: transmitting the second subset to the central node, wherein the central node is further configured to formally verify whether each datapoint in the second subset violates the security property and to generate a list of datapoints in the second subset that violate the security property.

5. The method of any of claims 1-3, wherein, in response to the determining that the distributed dataset represents a horizontal distribution of datapoints, the number of operations comprise: selecting a predetermined number M of samples from the local subset; formally verifying whether each of the selected samples violate the security property; assigning a positive verification tag or a negative verification tag to each of the selected samples, wherein the positive verification tag indicates that the respective instance represented by the respective sample violates the security property, and the negative verification tag indicates that the respective instance represented by the by the respective sample does not violate the security property; classifying each of the selected samples as a positive instance or a negative instance, using the ML model; identifying, from the selected samples, a subset of samples by comparing the respective assigned verification tag and the respective classification for each selected sample, wherein the subset of samples includes any samples that are incorrectly classified as negative instances, and any samples that are incorrectly classified as positive instances; and updating the training dataset by adding the identified subset of samples in the current iteration to the training dataset.

6. The method of claim 5, wherein the method further comprises: training the ML model using the updated training dataset; obtaining one or more learning parameters of the ML model; anddetermining whether to repeat the number of operations for a further N iterations, based on the one or more learning parameters.

7. The method of any of claims 1-3, 5 or 6, wherein the distributed node is further configured to perform iteratively the following steps for a predetermined number of iterations P: sending one or more learning parameters of the ML model to the central node; receiving one or more aggregated learning parameters from the central node; and updating the ML Model using the received aggregated learning parameters to obtain a global ML model.

8. The method of any of claims 1 , 2 or 4, wherein, in response to determining that the distributed dataset represents a vertical distribution of datapoints, the number of operations comprise: selecting a sample from the local subset; sending, to the central node, the sample; receiving, from the central node, the sample with an assigned positive verification tag or negative verification tag, wherein the positive verification tag indicates that the instance represented by the sample violates the security property, and the negative verification tag indicates that the instance represented by the by the sample does not violate the security property; updating the training dataset by adding the sample with its assigned verification tag to the training dataset; and training the ML model using the updated training dataset; sending one or more learning parameters of the ML model to the central node; receiving one or more aggregated learning parameters from the central node; and updating the ML Model using the received aggregated learning parameters to obtain a global ML model.

9. The method of any of claims 2-8, wherein the initial training set of datapoints comprises a first datapoint and second datapoint, the first datapoint representing an instance which violates the security property, and the second datapoint representing an instance which does not violate the security property.

10. The method of claim 9, wherein the first datapoint is assigned a positive verification tag, and wherein the second datapoint is assigned a negative verification tag.

11. The method of any of claims 1-3, 5-7, 9 or 10, wherein the method further comprises, in response to the determining that the distributed dataset represents a horizontal distribution of data points: generating a compliance report comprising the list of instances that violate the security property.

12. The method of any preceding claim, wherein the step of determining whether the distributed dataset represents a horizontal distribution of datapoints in the distributed system, or a vertical distribution of datapoints in the distributed system comprises: receiving, from the central node, an identifier indicating whether the distributed dataset represents a horizontal distribution or a vertical distribution.

13. A method performed by a central node in a distributed system, for facilitating formal verification of compliance of a security property in the distributed system, the method comprising: receiving, from each distributed node, a sample from a respective local subset available at the distributed node, wherein a plurality of datapoints forming a distributed dataset are distributed amongst a plurality of distributed nodes in the distributed system, wherein each datapoint represents an instance to be verified as to its compliance to the security property, and wherein each distributed node has access to a respective local subset of the distributed dataset, and wherein the distributed dataset represents a vertical distribution of datapoints in the distributed system; merging the received samples; formally verifying whether each of the received samples violates the security property; assigning a positive verification tag or a negative verification tag to each of the received samples, wherein the positive verification tag indicates that the respective instance represented by the respective sample violates the security property, and the negative verification tag indicates that the respective instance represented by the by the respective sample does not violate the security property; and transmitting, to each distributed node, the respective sample received from the distributed node and the verification tag that has been assigned to the respective sample.

14. The method of claim 13, wherein the method further comprises:receiving, from each distributed node, a respective first subset including datapoints of the local subset available at distributed node that are predicted as having violating characteristics with respect to the security property; merging the received datapoints; formally verifying whether each received datapoint violates the security property; and generating a list of datapoints that violate the security property.

15. The method of claim 14, the method further comprising: receiving, from each distributed node, a respective second subset including datapoints of the local subset available at distributed node that are predicted as having nonviolating characteristics with respect to the security property; merging the received datapoints; formally verifying whether each received datapoint violates the security property; and generating a list of datapoints that violate the security property.

16. The method of any of claims 13-15, wherein the method further comprises: determining whether the distributed dataset represents a horizontal distribution of datapoints in the distributed system, or a vertical distribution of datapoints in the distributed system; and transmitting, to at least one distributed node, an identifier indicating whether the distributed dataset represents a horizontal distribution or a vertical distribution.

17. A method performed by a distributed node in a distributed system, for facilitating formal verification of compliance of a security property in the distributed system, wherein a horizontal distribution of datapoints in the distributed system represent a distributed dataset, wherein a plurality of datapoints forming the distributed dataset are distributed amongst a plurality of distributed nodes in the distributed system, wherein each datapoint represents an instance to be verified as to its compliance to the security property, and wherein the distributed node has access to a local subset of the distributed dataset, the method comprising: iteratively performing a number of operations, for a predetermined number of iterations N, to form a training dataset comprising a number of datapoints of the local subset, and to obtain a Machine Learning, ML, model for predicting violation of the security property;forming a modified local subset comprising the datapoints of the local subset that are absent from the training dataset; classifying, using the ML model, each of the datapoints of the modified local subset into one of a first subset and a second subset, wherein the first subset includes datapoints that are predicted as having violating characteristics with respect to the security property, and the second subset includes datapoints that are predicted as having non-violating characteristics with respect to the security property; formally verifying whether each datapoint in the first subset violates the security property; and generating a list of datapoints in the first subset that violate the security property.

18. A method performed by a distributed node in a distributed system, for facilitating formal verification of compliance of a security property in the distributed system, wherein a vertical distribution of datapoints in the distributed system represent a distributed dataset, wherein a plurality of datapoints forming the distributed dataset are distributed amongst a plurality of distributed nodes in the distributed system, wherein each datapoint represents an instance to be verified as to its compliance to the security property, and wherein the distributed node has access to a local subset of the distributed dataset, the method comprising: iteratively performing a number of operations, for a predetermined number of iterations N, to form a training dataset comprising a number of datapoints of the local subset, and to obtain a Machine Learning, ML, model for predicting violation of the security property; forming a modified local subset comprising the datapoints of the local subset that are absent from the training dataset; classifying, using the ML model, each of the datapoints of the modified local subset into one of a first subset and a second subset, wherein the first subset includes datapoints that are predicted as having violating characteristics with respect to the security property, and the second subset includes datapoints that are predicted as having non-violating characteristics with respect to the security property; and transmitting the first subset to a central node in the distributed system, wherein the central node is configured to formally verify whether each datapoint in the first subset violates the security property and to generate a list of datapoints in the first subset that violate the security property.

19. A computer program product comprising a computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, onexecution by a suitable computer or processor, the computer or processor is caused to perform the method of any of claims 1-18.

20. A distributed node configured to perform the method of any of claims 1-12, 17 or 18.

21. A distributed node, comprising a processor and a memory, said memory containing instructions executable by said processor whereby said distributed node is operative to perform the method of any of claims 1-12, 17 or 18.

22. A central node, configured to perform the method of any of the claims 13-16.

23. A central node comprising a processor and a memory, said memory containing instructions executable by said processor whereby said central node is operative to perform the method of any of claims 13-16.

24. A distributed node, comprising: processing circuitry configured to cause the distributed node to perform any of the steps of any of claims 1-12, 17 or 18; and power supply circuitry configured to supply power to the processing circuitry.

25. A central node, comprising: processing circuitry configured to cause the central node to perform any of the steps of any of claims 13-16; power supply circuitry configured to supply power to the processing circuitry.

Images