Literature shows that trust typically relies on knowledge about the communication partner. Federated learning is an approach for collaboratively improving machine learning models. It allows collaborators to share Machine Learning models without revealing secrets, as only the abstract models and not the data used for their creation is shared. Federated learning thereby provides a mechanism to create trust without revealing secrets, such as specificities of local industrial systems. A fundamental challenge, however, is determining how much trust is justified for each contributor to collaboratively optimize the joint models. By assigning equal trust to each contribution, divergence of a model from its optimum can easily happen-caused by errors, bad observations, or cyberattacks. Trust also depends on how much an aggregated model contributes to the objectives of a party. For example, a model trained for an OT system is typically useless for monitoring IT systems. This paper shows first directions how heterogeneous distributed data sources could be integrated using federated learning methods. With an extended abstract, it shows current research directions and open issues from a cyber-analyst's perspective.
A common cybersecurity goal is thwarting attackers through detection of their actions, understanding of their methodologies, and increasing the resilience before their next attempts. However, the considerable variety, thus complexity, of the tools and techniques used by attackers drown their traces in the high volume of legitimate network trafic and endpoints logs. One way used by defenders (often called “Blue teams”) to act against threat actors is sharing knowledge about their abuses. However, knowledge gathered during security monitoring or incident response is often coupled with private data which cannot be shared for confidentiality reasons (GDPR, NDA, etc.).
Machine Learning (ML) approaches can help here, as they result in abstract models that are typically not reversible to their input data [1]. A fundamental problem for observation-based security is the amount of data needed for having a trustable and reliable impression. Typically, more data allows for better behavior characterization, thus improving either anomaly detection, or event classification. Collecting data requires either a long observation time or many data sources, as comprehensiveness is dificult to reach.
Federated Learning (FL) has been introduced to enable the sharing of local models and to federate them towards better joint models. Each participant computes on its own an ML-model using its own data. The resulting model is aggregated with the ones of other participants, typically by a trusted party, then the new model is shared between each of them.
Consequently, all parties benefit from each other while no one have access to their private data and algorithms. Sharing models however still faces issues as models can be modified with backdoors [2], poisoned with adversarial approaches [3] or simply sufers from bad quality training dataset.
This paper discusses FL sharing approaches through aggregation issues. Section 2 introduces the concept of Machine Learning (ML) based intrusion detection, and Federated Learning (FL) as a collaboration enabler. In Section 3, we summarize the literature around federated intrusion detection, with an extended abstract of a survey. Section 4 outlines an experimental use-case for Federated Intrusion Detection System (FIDS) application. Section 5 discusses open issues and the envisioned solutions. Section 6 concludes our proposition.
One prominent application of FL in the cybersecurity field is for security monitoring and collaborative intrusion detection. This section defines the basis for the remainder of the paper.
Security monitoring systems frequently use signature-based Intrusion Detection Systems (IDSs) to detect known attacks to safeguard companies [4]. However, this strategy sufers from serious limitations against zero-day and one-day attacks, as well as Advanced Persistent Threats (APTs), such as Stuxnet [5]. Furthermore, the IoT’s heterogeneity and irregular trafic cause IDSs to be less efective or inadequate [ 6]. As a result, researchers began to look into anomaly detection as a way to improve detection systems.
Here, multiple approaches coexist, depending on objectives and available data. On the one hand, anomaly-based detection systems compare monitored events to a baseline profile trained on nominal trafic to assess whether they are malicious or not [ 7]. On the other hand, patternbased classification, aims at extracting patterns from known attacks that have been previously labelled as such, and then characterize input data according to the extracted patterns. Therefore, anomaly-based approaches are particularly relevant to detect unknown behaviors, whereas supervised ones are more equipped for threat characterization.
The source of data will also influence the available features for detection. For example, endpoint-oriented sensors such as Sysmon monitor processes, use of windows’ registry key or system calls while network-oriented sensors provides a lot of information about protocols, packet length, or IP addresses. Preprocessing can be used to extract additional features from the raw data, to provide more information. The literature distinguishes three key non-exclusive approaches: feature extraction, feature embedding, and feature selection [8].
In the context of knowledge sharing, the choice of the input feature is critical to transfer knowledge between participants. For instance, IP addresses are specific to the local layout of the network, and might have another meaning in another environment, if they even exist. On the other hand, given one class of devices, inter-arrival time (IAT) should not vary much between networks, thus making potentially making it a good choice for transferring knowledge.
With a designated set of features and an input dataset, one can establish a model of the data. A model is an abstraction that can be used afterward for other tasks, such as characterization. Algorithmically speaking, a model is a set of mathematical parameters that are inferred from input data by an algorithm. It can be the statistical parameters of a distribution function, the condition nodes in a decision tree, or the weights and biases of a neural network. The ability of a model to be shared partly depends on how easily these parameters can be aggregated.
Over the years, ML have been applied to intrusion detection with substantial results. Three
approaches coexist:
(
For efective training, a balanced labeled dataset is required. However, because local
training data is infrequently labeled and models can be afected by unbalanced class
distribution, supervised learning is more dificult to apply in real-world scenarios [ 9].
(2) For unlabeled data, unsupervised learning is more appropriate. In the case of IDS, we
assume that (i) benign trafic is substantially more common in the testing set than
anomalies [10]; and (ii) abnormal packets are statistically diferent from normal packets.
(
However, ML algorithms also require a lot of training data to avoid learning biased model, from the lack of exhaustively or from an overrepresentation of a class in the training set.
To cope with the limitations of ML, especially when training data is locally collected, collaborative IDSs have emerged in the literature. However, they are almost always built in a centralized manner, which induces its own set of issues: (i) centralizing a system typically introduce a single point-of-failure (SPoF) [11]; (ii) centralized IDSs imply sending local data for training or detection, increasing the risk of information disclosure [12]; (iii) communicating data over networks also increase bandwidth consumption and latency, which are critical for intrusion detection [13].
Introduced in 2016 by Google [14], FL promises to cope with these issues. In FL, model learning is distributed among the participants of the federation. Therefore, local data stay in the participant’s system, and collaboration is achieved by sharing and aggregating the generated models. Aggregation can be done by a server [6], [15]–[17], but it might lead to concerns with trust and privacy. Due to challenges in terms of traceability, integrity, privacy, and trust, recent research has favored the usage of trusted distributed ledgers [18], [19], multi-party computation (MPC) [20], and privacy-preserving mechanisms like Diferential Privacy (DP) [ 21].
Since its introduction, FL has been applied to multiple domains, such as intrusion detection, whose presence is increasing in the literature. In this context, FL allows local detection of attacks—thus ofering low latency and bandwidth—while jointly enriching participant’s models and preserving data privacy.
This section is an extended abstract of the study published in IEEE Transactions on Network
and Service Management (TNSM) [8]. Contributions of the study are as follows: (
Section 3.1 presents the results of the study and the established taxonomy, whereas Section 3.2 reviews identified research directions.
The study performs two analyses of the literature. The quantitative analysis is based on objective metrics that can be extracted from the literature, such as publication date and venue. Figures 1a and 1b show the evolution of the literature on FL and IDS over time, both being building blocks of FIDSs.
2000 2005 2015
2020
The qualitative analysis is based on the comparison of existing approaches, using the proposed taxonomy. They can be grouped into four categories: data, local operation, federation, and aggregation. A fith meta-category is dedicated to the implementation and evaluation of the approach.
The taxonomy (Figure 2) provides twelve characteristics on which all approaches can be compared: 1. Data source and type: what data is collected and how; heavily depends on the use case. 2. Preprocessing: strategies for data curation, such as normalization and feature selection. 3. ML location: where the ML model is trained and executed. 4. Local algorithms: how the ML model is trained, and its impact on performance. 5. Defense capabilities: the ability of the approach to mitigate attacks. 6. Federation strategy: how the federation is organized; e.g. client selection, architecture. 7. Communication: how data (i.e. models) is exchanged between participants, including protection mechanisms. 8. FL type: type of FL strategy, depending on the objectives and available data. 9. Aggregation strategy: how models are aggregated, especially with heterogeneous clients. 10. Model target: i.e. the balance between specialization and generalization. 11. Analyzed dataset: the dataset used to evaluate the approach; often Information Technology (IT)-focused, and not always available. 12. Costs and metrics: how the approach is evaluated, depending on the use case and objectives.
The structure provided by the taxonomy also allows comparing the selected works. Table 1 summaries the results of the comparison. It shows that most approaches focus on IT network trafic, using a gateway to collect data and host both learning and detection processes. Most also use Deep Learnings (DLs) to perform supervised learning and classify trafic. A majority use unmodified FedAvg for the aggregation, which is the initial FL algorithm that was proposed by Google [14].
As the FL topic gets more mature, research tends to focus on secondary aspects, such as security and privacy, or on the application of FL to other use cases. This subsection summaries the open issues and research directions; more details are available in [8].
(i) Performance — Like any detection system, FIDSs are looking for an absolute performance: a system with a perfect classification score, producing no false positives or negatives. To this end, several avenues have been identified in the literature, such as the use of Generative Adversarial Networkss (GANs) or the improvement of feature selection as input to the model. Moreover, the link between the performance of the system and its hyper- and meta-parameters is not yet established.
Taxonomy of FIDS
Federation Data Local operation Experimentation Aggregation 9. Aggregation strategy 1. Data source and type 2. Preprocessing 3. ML location 4. Local algorithms 5. Defense capabilities 6. Federation strategy 7. Communication 8. FL type 10. Model target 11. Analyzed dataset 12. Costs and metrics
Distribution Source Dimensionality reduction Feature extraction Feature selection On server Dedicated device On gateway On device Unsupervised ML (ii) Adaptability and scalability — Distributed systems such as FL are often used to cope with resource limitations, especially in terms of computation and bandwidth. However, as pointed out by several selected works, FL faces limitations when dealing with numerous clients. Therefore, further research is needed on FIDSs client selection: dynamic fusion based on score or time, reputation, number of detected attacks, etc. (iii) Knowledge transfer — Current solutions focus on federating training and detection for devices and resources that belong in the same domain. Therefore, open issues include the
technologies such as Software-defined networking (SDN) ofer rapid resiliency capabilities; and recent work studies the efectiveness of such defense mechanisms. New emerging applications such as self-defense and self-healing systems could benefit from FIDSs and other FL-based technologies. (vi) Model convergence — Models can difer from one client to another, especially in heterogeneous contexts like intrusion detection. Consequently, model convergence is made more dificult. Current research focus on optimizing parameters by considering aggregation as an optimization problem. For instance, Charles et al. [42] use meta-learning to infer the right parameters, thus optimizing the aggregation afterward. Weighting mechanisms are also present in the literature to improve the convergence [43]. (vii) Dataset representativity — Existing public datasets are not representative of FIDSs potential deployment environments. Indeed, they are often datasets produced for traditional machine learning algorithms but split for federated purposes, like NSL-KDD [44], UNSW-NB15 [45], or CIC-IDS2017 [46]. However, this approach introduces biases, as features or times series are all related to the same original event. Similar approaches using adversarial examples for malware analysis which modify features instead of original binaries faces the inverse feature-mapping problem [47], [48].
Some of these issues depend on works from other related fields, such as ML for performance or FL for scalability. However, specificities of the FIDSs use case require more concrete research questions. Especially, the topics of security, trust, and resilience, are critical for a collaborative security use case.
As introduced in Section 2, FL can be used in multiple cybersecurity settings and use cases, from distributed statistic inference [49] to authentication [50]. Even in the more specific context of intrusion detection (i.e. FIDS), numerous use cases are studied, e.g. IT networks [29], Industrial Internet of Things (IIoT) [15], or smart healthcare [51]. This variety in use cases comes with various data types, architectures, and constraints. Making knowledge transferable among heterogeneous use cases and data is a long-term goal for FIDSs (see Section 3.2).
However, heterogeneity is currently a major challenge for FL [52]. Therefore, we focus on a specific use case, namely FIDS in IT networks. We study the impact of heterogeneity on FL in this setting, and research solutions to mitigate it.
We consider a typical use case inspired from the industry, where actors invested in collaboration are organizations aiming at improving their local detection. We assume that each organization has interests in sharing information, but has highly sensitive data that cannot be shared. For example, Security Operation Centers (SOCs) perform security monitoring through the processing of customer data (which can contain personal identifiable information) that cannot be shared. On the opposite, with the rise of cyber-criminal services [53], attackers tend to lead similar attacks against diferent information systems. Two SOCs in such situation would share their Indicators of Compromise (IoCs) or corresponding ML-models to detect all attacks after the first that succeed. In this context, FL can be used to train a FIDS model on a distributed dataset, while preserving the privacy of each organization. For instance, existing structures such as Information Sharing and Analysis Centers (ISACs) or inter-SOCs could benefit from such a system, which enables collaboration while protecting company secrets.
This setting is called cross-silo [52], as opposed to cross-device. It is worth noting that FIDSs
do not exclude cross-device settings, for instance in endpoint detection [5]. However,
crosssilo is more relevant for our use case, as it is more relatable for the industry, and it is easier to
implement in a testing infrastructure. In cross-silo, fewer clients (
We firstly also focus on horizontal federated learning (HFL), where participants have the same features, but diferent samples. In HFL, participants have similar objectives ( i.e. ML tasks) and want to improve their models, but cannot build a centralized dataset due to privacy or legal concerns. This is the most common setting in FIDSs, as it serves the goal of improving behavior characterization, and having access to knowledge that cannot be inferred with only local data. We also start with unsupervised learning algorithms, as the presence of labels not guaranteed in real-world settings.
Figure 3 depicts an example topology, inspired by IT networks from the industry. We assume that each organization has a dedicated IT network, that might vary in terms of architecture, probe location, or services (see Section 4.2).
The chosen use case inherently highlights two of the seven open issues identified in the
literature: heterogeneity and trust. Furthermore, as mentioned in Section 3.2, the lack of a dataset
that is representative of this use case undermines existing works on the topic. Therefore, we
ifrst focus on two complementary tasks: (
To cope with the lack of appropriated dataset in the literature, we propose to build a new dataset generation platform with federation and distributed systems in mind. The platform relies on virtualization topologies to generate normal trafic [ 54], and defined attack scenarios to evaluate the detection performance. These topologies will be notably used to generate benign trafic and train local unsupervised learning algorithms—literature typically use autoencoders for this task [28], [38], [55]. The trafic generated at this step must be representative of a real IT-focused network with users, internal resources (such as file sharing and web applications), administration and supervision services, and access to the Internet.
We then aim to evaluate existing approaches on this more realistic and demanding use case.
We expect most of them to yield less promising results, even when they claim to be able to deal with heterogeneity. On the other hand, FL literature abounds of works on heterogeneous data, and aggregation algorithms, such as FedProx [56] or Fed+ [57], might provide good results. In this case, proving empirically that such approaches are able to cope with the realistic heterogeneity of our use case remains a major contribution.
At the same time, we develop a new FL approach that deal with heterogeneity and trust. Section 5 presents strategies envisioned to achieve this goal. When considered as a collaboration system, FL is highly connected to research on trust and reputation systems. Hence, we plan to leverage existing works on the topic, such as [58], to provide a reputation-aware FL system. This approach will be evaluated on the new dataset, and compared to existing strategies.
To measure the ways in which heterogeneity can manifest itself, we define varying parameters that are used to generate the topologies. This can be used to generate a worst-case scenario, where all the parameters are set diferently in each topology.
In regard to the use case presented in Section 4.1, we consider the following parameters: (i) architecture — the network architecture of the topology defines how services are interconnected, how the trafic is captured, and where data collection is performed. For example, a topology with a single main gateway which captures trafic, and several services on the same network, will produce a diferent dataset when compared with a star-shaped topology with multiple subnets. Appropriated metrics are required to characterize the impact of these diferences, e.g. size (number of hosts, of subnets), mean number of hops between a service and the last gateway, and so on. (ii) services — diferent services can rely on diferent protocols, and therefore generate different kind of data, with diferent behaviors. For example, a service using TCP will induce connection establishment, and therefore a lot of trafic back-and-forth, whereas something based on UDP will produce a more continuous stream of data. Therefore, diferent services (and protocols) might have diferent normal behaviors, causing heterogeneity among participants. The list of considered services must be adapted depending on the considered attack scenarios. (iii) maturity — security practices vary between organizations, depending on their threat model, previous expertise, and budget. For example, a company might have a dedicated security team, and therefore be able to implement a more mature security policy, whereas a small company might not have the resources to do so. This parameter is important to consider, as it can impact the quality of the dataset, e.g. by having unseen attacks in the training data, supposed to be benign trafic. (iv) probe location — while we assume that all participants extract the same features (due to HFL settings, see Section 4.1), the location of the probes can vary. In the same architecture, one collection point at the gateway, or distributed probes in each subnet, will produce diferent datasets.
WAN / Internet user-pc .2.3
Furthermore, some services are required to build working topologies, such as NTP, DHCP, or DNS. We use a typical SME topology as a starting point for the experiments, which is presented in Figure 3. This topology is composed of a dozen of machines, divided between employee workstations, servers, etc. Variations of this topology will be also generated, and will be used as other participants.
To evaluate approaches on any dateset, we measure their ability to detect relevant attack scenarios. Typical attacks targeting such infrastructures are automated, like ransomware and botnets. A lone attacker doing recognition and enumeration in the network is also to be considered, but more advanced attacks such as APTs are out of the scope of this use case.
To make a rigorous evaluation, we rely on the state of the art to select attacks, such as the MITRE ATT&CK framework [59], or the most used attacks in dataset literature. The list of attacks that are considered on a given topology is deeply correlated to the services available in this topology. For instance, cache poisoning requires cache-based service in the topology, such as a DNS relay-server. On the other hand, organizations establish threat models depending on the services they host or use. Considered attacks may include: Distributed Denial of Service (DDoS) on the internet-facing web services, host and port scan,or web vulnerability exploitation (injections, ...).
Experiments are conducted on a private infrastructure. The test bed consist of three servers, two for the virtualization, and one for computation that will be dedicated to executing the required ML algorithms. While in real-world settings, the computation is performed on the participants’ devices, we ofload the computation to a dedicated server. This allows us to focus on the aggregation and trust aspects of the problem, and to avoid the complexity of the distributed computation. To enable sound experiments [60], we plan to provide access to all produced artifacts, including the dataset, the code, and the topology specifications, as well as to the testbed itself.
As the literature shows, FIDSs falter at aggregating heterogeneous models. Therefore, the experiments detailed in section 4 provide means to measure and quantify the issue. While literature on FL contains works on dealing with heterogeneous clients, this is still an issue in the context of intrusion detection. Hence, we expect state-of-the-art approaches to perform rather poorly, when compared to the results obtained on a homogeneous dataset. We consider several approaches to cope with these issues.
First, metric-based model weighting could be used to give less importance to models that deviate too much from the others. Zhang et al. [18] use a centroid-distance weighting algorithm that cope with the heterogeneity in IIoT. More generally, weighting algorithms can help to merge only relevant models, depending on a set of defined metrics. Other metrics could be used to further tune the model aggregation, like a numerical estimation of how much information the model can bring.
Another related topic is the measurement of the training data’s quality. In fact, as the learned model is an abstraction of the data upon which it was trained, low-quality data would lead to a low-quality model. Bringing a low-quality model in a federation could undermine every one’s security. However, we must define what makes training data of quality, and how this quality can be measured. Furthermore, weighting models according to their quality means the system needs to be able to compare them, thus having access to the other’s data.
Moreover, existing works on federated learning rely on participant clustering [58], [61] to improve model specialization. Often, these approaches aim at either reducing heterogeneity between clients, or detecting and excluding malicious participants. Part of the challenge here reside in the metrics to chose to build clusters. Aforementioned metrics such as data quality, or information estimation, could be also used in clustering. In the context of intrusion detection, the formation of clusters can have an indirect impact on participants’ security.
Finally, the lack of information inherent to the abstract nature of the model is a major hurdle to estimate its value for aggregation. Therefore, we also consider adding metadata around models, describing what the model contains without giving out too much information about local data and configurations Such metadata would allow choosing which models one client is interested in, depending on its use case. We believe an à-la-carte model aggregation would help to cope with heterogeneity issues.
In this paper, we focused on the application of federated learning to the cybersecurity field. Federated learning increases trust among partners as they do not need to share data, contrarily to traditional ML-approaches. However, federated learning faces some limitations when federating models built on heterogeneous data. We therefore ofer to address this issue within experiments conducted on a platform with appropriate generated datasets. This platform displays several use-cases with diferent partners in order to study aggregation-models parameters. We then outline envisioned solutions which will be subjects of future work.
These contributions can have a significant impact on increasing the security of organizations. In fact, while existing research has addressed the privacy aspects of collaboration through federated learning and other privacy-preserving mechanisms, maintaining trust in heterogeneous collaboration is still a challenge. We showed that federated learning can help with the creation of a common trusted security model for systems that are inherently distributed. Our approach enables non-trusting parties to collaborate for the joint goal of increasing their cybersecurity without revealing critical internals. [15]
B. Li, Y. Wu, J. Song, R. Lu, T. Li, and L. Zhao, “DeepFed: Federated Deep Learning for Intrusion Detection in Industrial Cyber-Physical Systems,” IEEE Transactions on Industrial Informatics, 2020. [17] [18] Q. Qin, K. Poularakis, K. K. Leung, and L. Tassiulas, “Line-Speed and Scalable Intrusion Detection at the Network Edge via Federated Learning,” en, 2020.
Z. Chen, N. Lv, P. Liu, Y. Fang, K. Chen, and W. Pan, “Intrusion Detection for Wireless Edge Networks Based on Federated Learning,” en, IEEE Access, 2020. (visited on 10/25/2021). X. Hei, X. Yin, Y. Wang, J. Ren, and L. Zhu, “A trusted feature aggregator federated learning for distributed malicious attack detection,” en, Computers & Security, 2020. (visited on 10/25/2021). K. Li, H. Zhou, Z. Tu, W. Wang, and H. Zhang, “Distributed Network Intrusion Detection System in Satellite-Terrestrial Integrated Networks Using Federated Learning,” en, IEEE Access, 2020. (visited on 10/25/2021).
Y. Qin and M. Kondo, “Federated Learning-Based Network Intrusion Detection with a Feature Selection Approach,” en, in 2021 International Conference on Electrical, Communication, and Computer Engineering (ICECCE), Kuala Lumpur, Malaysia: IEEE, 2021. (visited on 10/04/2021). H. Liu, S. Zhang, P. Zhang, X. Zhou, X. Shao, G. Pu, and Y. Zhang, “Blockchain and Federated Learning for Collaborative Intrusion Detection in Vehicular Edge Computing,” en, IEEE Transactions on Vehicular Technology, 2021. (visited on 10/04/2021). [32]