dataesr/scientific-paragraphs-categorization huggingface dataset:
Moreover, we propose a framework for detecting network-level attacks based on Graph Neural Networks (GNN) to exploit our network representation. The framework comprises three main steps that aim to extract and embed attacks topological features with flow's attributes. The obtained information characterizes the graph's topology with the nodes' attributes and enhances the capabilities of the decision-making module in distinguishing between normal and malicious flows. The availability of datasets for the flow classification problem and the high complexity of packet-level IDSs endorses our choice to work on a flow-based approach. Our main contributions can be summarized as follows: • We propose a novel flow-based graph structure that provides relevant information about malicious behavior patterns and enables the model to attend a higher accuracy in distinguishing between normal and malicious flows.
NIDS Problem Statement Our objective is to propose a Network-level IDS (NIDS), as illustrated in Fig. 1. The NIDS's role is to classify the network flows into normal and malicious and report any abnormal behavior to the system administrator (SA). The SA is then responsible for analyzing the reported network flows and reacting to prevent potential attacks. Meanwhile, the flows classified as malicious are stored in a specific dataset for further processing. The NIDS collects packets from the network in the firewall's internal interface. The collected packets will then be transformed into communication flows, identified by the source Internet Protocol (IP) address, source port number, destination IP address, destination port  ✗ ✗ ✗ ✗ ✗ ✗ Relevant topological information ✗ ✗ ✗ ✗ Cover Multi-step attacks ✗ ✗ ✗ ✗ ✗ ✗ IP Spoofing immunity ✗ ✗ ✗ ✗ ✗ ✗.
Proposed Framework In Fig. 3 , we present a flowchart of the proposed IDS framework where we highlight the main steps. The goal is to detect abnormal network behavior and alert the SA to intervene and prevent possible attacks. To this end, data-extraction devices collect information regarding all the communication flows in the network. The collected data contains several types of information that will be used by the model to detect malicious activities. These features provide information about the used protocols, such as the time of the packet connections, the number of original packets, SSL activity, HTTP activity, DNS activity, violation activity, etc. This information is fed then to the IDS framework, which detects any malicious activity and reports it to the SA administrator. Prior to the IDS, in the pre-processing phase, the data is processed and transformed into a format consumable by the IDS.
The first step of the IDS, namely the graph creation phase, is responsible for processing and transforming the data into a flow-based graph. This graph is structured in a specific manner that will be described later in Sect. 4. 2. The second step of the IDS exploits the flow-based graph to extract and embed relevant spatial and non-spatial information. In this step, we have three main modules: -Graph Structure-Agnostic (GSA): this module is responsible for embedding the node attributes (flows-related features) to extract the most relevant information. -Attention-based Feature extractor (AFE): this module exploits the embedded features generated by the GSA layer to aggregate neighbors data while assigning an importance score to each one of them. -Spatial Feature Extractor (SFE): this module extracts the spatial information from the graph using a convolutional graph network GCN.
In this work, we investigate two datasets: CICIDS 2017 dataset  [12]  and ToN IoT dataset  [1]. For instance, both datasets are highly unbalanced, which makes the model biased toward the majority class, the normal flows in our case. The undersampling technique will reduce the number of the normal flows only to have a lesser degree of unbalance for the training and the testing. It is worth mentioning that it is not recommended to perform harsh undersampling and transform the data to be fully balanced. In this latter case, the risk is that the transformed data would no more accurately represent real-world scenarios. Hence, the obtained results would be worthless in practice.
Phase 2: Feature Extraction Phase This phase exploits the graph structure and the nodes' features to extract pertinent information to be fed to the decision-making module for the intrusion detection task. The feature extraction is performed using three different modules: the graph structure-agnostic module, the attention-based feature extractor, and the spatial feature extractor. These models are detailed in what follows. Graph Structure-Agnostic (GSA) Module: The nodes' attributes of malicious flows are similar to those of normal flows. Thus, learning a discriminative embedding is required to enable the model to distinguish between normal and abnormal flows. The graph structure-agnostic module, as the name states, does not rely on the topological information of the graph. Instead, it considers only the flow data to extract a discriminative embedding of ordinary and malicious behaviors.
Evaluation Procedure In this section, we present and analyze two of the most used datasets in previous works to assess the quality of their proposed IDS solutions. We also discuss the existing evaluation approaches and highlight their drawbacks. Two major datasets are exploited in the literature: -CICIDS 2017 dataset  [12]  By reviewing the literature on these datasets, we find some flaws with the creation procedure of the CICIDS 2017 dataset. For example, the authors in  [5]  stated that the creation procedure has some issues in the CICFlowMeter tool that violate the correct implementation of network traffic. Moreover, they mentioned that CICFlowMeter suffers from an inaccurate labeling strategy that caused several mislabeled flows, which could mislead the learning of ML models. The ToN IoT dataset is more recent, and no previous work highlights any problem that could affect the performance of machine learning models.
We have conducted a thorough analysis of both datasets. For the CICIDS 2017, we notice that elementary models, like the decision tree-based model, can perfectly distinguish malicious flows. Moreover, these models have relatively good validation metrics since their first iterations, which is unusual in the learning process of ML models. Furthermore, we notice that during training, the validation metrics are higher than the training metrics. This behavior of ML models alerts on significant issues with the dataset or the validation methodology. In addition, for the CICIDS 2017, we observe a high similarity between flows of the same user. We explain this by the improper termination of TCP sessions as explained in  [5]. Indeed, due to these issues, a single attack could be segmented into several flows, and evidently, these segments would be highly correlated.
The ToN IoT is also slightly affected by this issue. It is tough to avoid such a problem while transforming the packet-based dataset into the flow-based one. Nevertheless, the problem is boosted in the case of CICIDS 2017 since the distribution of malicious flows per attacker is highly unbalanced. This means that some attackers are responsible for most of the attacks. Table  2  presents the number of flows labeled as malicious per attacker for both datasets. We notice that the distribution of attackers is not balanced for the case of CICIDS 2017, and we have one single IP address (the firewall IP address) assigned to the four exterior IP addresses. Hence, this is a massive issue in the graph structure because one node represents all the external users. More specifically, in the CICIDS 2017, all the flows come from the external network (.
i. e, users with IP addresses: 205. 174. 165. 73, 205. 174. 165. 69, 205. 174. 165. 70, 205. 174. 165. 71) are assigned the 127. 16. 0. 1 IP address. The ToN IoT dataset has better distributed malicious flows per attacker, which is clearly observed in Table  2. The classic evaluation procedure that randomly splits users' flows between training and testing sets is not recommended in this situation. In fact, due to the similarity between the flows of the same user and the segmentation of a single communication into multiple flows, we can conclude that this procedure is biased by seeing correlated data in the training and testing. To ensure reliable validation, we evaluate our model using an IP-based evaluation procedure. The idea consists in splitting the datasets into train and test sub-data using the distribution of malicious flows per attacker and the type of attacks.
Experimental Settings We have implemented the proposed framework in a python environment. The Pytorch Geometric and Netwrokx libraries are used to develop the proposed GNN-based algorithms. The training and testing are performed using an Nvidia GTX 1080 Ti graphic card. Table  3  presents the parameters required to rebuild our proposed work. The model comprises 2 MLP layers for the discriminative layers, 2 GCN layers, and one GATv2 layer. The score generation is performed using a 3-layer MLP. For the training, we employ the Cross-Entropy Loss as the performance measure of the classification problem  [15]  and Adam as the parameters' optimizer.
Results This section presents the numerical and graphical results to illustrate the performance of our intrusion detection framework and highlight its efficiency. First, we illustrate, in Fig. 6 , a visualization of a flows subset taken from the Ton IoT dataset using our proposed representation described in Subsect. 4. 2 (i. e. weights are not presented in the Figure ). In this Figure, we have nodes colored in red that represent the malicious flows in the network and nodes colored in green that represent normal flows. The graph of flows provides several spatial information, including clusters, sparse nodes, inter-cluster relations through nodes, etc. The spatial information does not have a unique explanation. In other words, the cluster, for example, could be created if a group of flows are included in the same communication, in different communications but related between each other (e.
This model should be avoided in practice since having a high FPR will cause tremendous computational power and human resources (i. e. cybersecurity engineers' efforts), which can be wasted on irrelevant alerts. The presence of data leakage issue is clearly seen when performing an evaluation of several models using the classical validation procedure. To lucidly show the presence of the issue, we select several models in a manner to have a basic model (i. e. , XGBoost model), a deep learning model (i. e. , MLP-based model), and two advanced models (i. e. , GNN-based models). For each model, we calculate the F1-score on the testing subset that contains flows chosen randomly from the ToN IoT dataset. The results showed that all the evaluated models reached high F1-scores. For example the model proposed in  [3, 15]  reached respectively 0.
: CICIDS2017 is a labeled network flows dataset alongside a full packet version in PCAP format. It covers the most common network attacks such as DoS, HULK, DDoS, FTP-Patator, DoS Slowloris, and SSH-Patator attacks. CICIDS 2017 is created by capturing five days network stream. CICIDS 2017 flow-based version is created using the CIC-FlowMeter [12]. -ToN IoT dataset [1]: ToN IoT is a heterogeneous dataset released in 2020 by the Intelligent security group UNSW Canberra, Australia. The dataset contains a huge number of realistic attack scenarios such as scanning, DoS, Ransomware, and Backdoor attacks. Ton IoT network flow-based version is created using the NetFlow.
The present knowledge on CaCO 3 precipitation makes it difficult to parametrize this term in a model  (Aumont et al. , 2005). We are aware that future refinements will have to take it into account as it could lead notably to an underestimation of air-to-sea CO 2 flux. Sensitivity tests to this term were performed (see Sect. 2. 1. 4) and are presented in Sect. 5. In this study, in the carbonate chemistry model the dissociation equilibriums of carbonates, water, ammonium, phosphate, silicate, and borate were taken into account. The thermodynamic equilibrium constants of the carbonate system were calculated as a function of temperature, salinity, and pressure as in  Millero (1995)  with typographical correction from the CO2SYS program  (Lewis and Wallace, 1998). In particular, carbonic acid dissociation constants are calculated as  Mehrbach et al.
1 ), in the Ligurian Sea, in 2013  (Antoine et al. , 2006; Merlivat et al. , 2018). Temperature and salinity were measured using a Seabird SBE 37-SMP MicroCat instrument. The sensors were cross-calibrated before and after each mooring deployment with the ship CTD, by performing a high temporal resolution sampling cast with 30 min long time series at the fixed depths of 300 and 1000 m. This allows for high accuracy of 0. 001°C in temperature and 0. 005 in salinity  (Houpert, 2013). fCO 2 measurements were monitored using a CARIOCA sensor whose accuracy is estimated at 2 µatm. A detailed description of these data is given in  Merlivat et al. (2018). We also used monthly vertical profiles of temperature, salinity, dissolved oxygen, dissolved inorganic carbon, and total alkalinity collected from September 2012 to September 2013 at the EMSO-DYFAMED site (43°25' N; 7°52' E; depth: 2350 m, black star in Fig.
1 )  (Coppola et al. , 2020) , located 5 km from the BOUSSOLE site. Note that temperature and salinity were collected using a Seabird SBE911. Dissolved oxygen measurements were performed using Winkler titration at each CTD cast and were used to correct the SBE43 sensor data by adjusting the calibration coefficients  (Coppola et al. , 2018). DIC and total alkalinity were measured via potentiometric titration following the methods described by  Edmond (1970)  and  DOE (1994)  with an accuracy estimated between 1. 5 and 3 μmol kg -1. They were analyzed by the SNAPO-CO 2 national service (Service National d'Analyse des Paramètres Océaniques du CO 2 ). pCO 2 and pH T (pH at total scale) were deduced from total alkalinity and total inorganic carbon using the carbonate system CO2SYS program  (Lewis et Wallace, 1998; Heuven et al.
3e ). The increase in winter is also found in observations and CANYON-MED results. In summer the model underestimates both datasets by ~10-15 µmol kg -1. The pH T seasonal variation in observations, simulation and CANYON- synthesis study: 300-570 µatm for pCO 2 , 2200-2340 µmol kg -1 for DIC, 2510-2600 µmol kg -1 for alkalinity and 7. 9-8. 2 for pH T.
Acknowledgments We want to acknowledge the scientists and crews of the  Flotte Océanographique Française  (https://www. flotteoceanographique. fr/) who contributed to the cruises carried out in the framework of the DEWEX project and  MOOSE program  ( CNRS-INSU). We thank  Nicolas Metzl  from  LOCEAN  for helpful discussions, and the  Service National des Paramètres Océaniques du CO2 (SNAPO-CO2, LOCEAN ,  Sorbonne University-CNRS, France)  for the total inorganic carbon and total alkalinity analyses. We thank  Thibaut Wagener  from  MIO  for his help on data analysis and his useful comments on an earlier version of the manuscript. We are grateful to Dariia Atamanchuk from Department of https://doi. org/10. 5194/bg-2022-219 Preprint. Discussion started: 15 November 2022 c Author(s) 2022. CC BY 4.
Oceanography at Dalhousie University for her help in the calculation of air-sea CO 2 fluxes. We also thank Xin Lan and Edward Dlugokencky from NOAA Global Monitoring Laboratory for the flask-air CO 2 data. We thank Marta Álvarez from IEO and collaborators for making available the CARIMED database to us. This study is a contribution to the MerMex (Marine Ecosystem Response in the Mediterranean Experiment) project of the MISTRALS international program and has been supported by the European Union's Horizon 2020 EuroSea project (grant agreement No 862626). The numerical simulations were performed using the SYMPHONIE model, developed by the SIROCCO group (https://sirocco. obs-mip. fr/), and computed on the cluster of Laboratoire d'Aérologie and HPC resources from CALMIP grants (P1325, P09115 and P1331).
In addition, efficiency gained through automation can help researchers to perform more research within the budget and effort constraints imposed by their projects. This paper presents the main software release of FabSim3, and explains how our automation toolkit can improve and simplify a range of tasks for researchers and application developers. FabSim3 helps to prepare, submit, execute, retrieve, and analyze simulation workflows. By providing a suitable level of abstraction, FabSim3 reduces the complexity of setting up and managing a large-scale simulation scenario, while still providing transparent access to the underlying layers for effective debugging. The tool also facilitates job submission and management (including staging and curation of files and environments) for a range of different supercomputing environments.
FabSim3 overview FabSim3 is an automation toolkit that is intended to support computational researchers, particularly those who run simulations, but who also do development on these simulations and their workflows. To accomplish this, our objectives are to: • Flexibly automate scientific workflow simulation processes to improve development and user productivity. Here "flexibly" means that users can easily modify existing automated tasks for re-use in new contexts. This can involve e. g. (a) preparation, (b) execution and monitoring, and (c) post-processing and analysis, • Reduce the risk of human error, e. g. by automating data management tasks and the management of ensemble and replicated simulations. • Make workflows easier to debug by transparently and systematically curating key inputs, outputs, scripts, local and remote environment variables.
• Reduce the required skill level and expertise for users to perform complex simulation workflows, including e. g. coupled or ensemble simulations, by introducing short-hand commands and flexible Python functions. • Provide fully automated functionalities for important or common workflows, enabling users to perform these from preparation to post-processing and results analysis with a single command. • Make workflows easier to port to different platforms by systematically organising platform-specific details of each application and workflow, and by pooling user-independent settings in a repository for shared use. • Improve the reproducibility of research results by providing an organised environment that encapsulates all relevant scripts, configuration details, environment settings and inputs for key studies.
Moreover, FabSim3 is a community project: machine-specific configuration information is shared and once a new feature or bugfix is finalized by one developer, it can be embedded and used by all others in their own plugins. FabSim3 is one of the main components in SEAVEAtk (formerly known as the VECMA toolkit), which is an application-agnostic software toolkit for the verification, validation and uncertainty quantification of high-performance computing simulation workflows. 1.
Related work FabSim3 relates to a wide range of tools that automate and support complex workflows. Many of these tools are taken up in the multiscale computing community, where the workflows are generally more complex due to the presence of multiple coupled models. A systematic analysis of multiscale computing tools and their added value is provided by Groen et al. [1]. Many of the tools mentioned there relate to FabSim3 in one form or another. In this section we will highlight the most relevant tools. The Automated Interactive Infrastructure and Database for Computational Science (AiiDA)  [2]  is perhaps one of the most closely related tools. Similarly to FabSim3, it provides an environment which helps to automate and curate complex workflows. AiiDA differs from FabSim3 in several areas. First, AiiDA is mainly geared towards use in materials science (as evidenced by the plugin list), while FabSim3 has a broad scope across domains.
Second, the tool focuses on enabling workflows using directed acyclic graphs, whereas FabSim3 focuses on enabling both acyclic and cyclic workflows. Third, the tool is more extensive, as for example its API also incorporates a wide range of database functionalities. Fourth, FabSim3 enables users to efficient execute large ensembles of jobs through a pilotjob manager, while AiiDA relies solely on submitting jobs directly to supercomputer schedulers, and therefore can only support ensembles of limited size. MaestroWF  [3]  is another, more generic tool for creating and managing simulation workflows. Similar to AiiDA, it supports a range of HPC scheduling systems, but does not (to our knowledge) interface to a pilotjob manager. In addition, MaestroWF relies on YML for simulation workflow definitions, while FabSim3 plugins have Python functions that define the workflows.
Both approaches have their advantages, with our Python-based plugin approach being more flexible, while a YML-defined simulation workflow as used in MaestroWF is easier to verify syntactically. Similarly, the A-/B-/O-MUSE frameworks  [4, 5]  provide a multi-purpose simulation workflow environment in respectively the astrophysical, biological and oceanographic domain. No general-purpose implementation currently exists, but the underlying design is adaptable to different domains  [5]. AMUSE and its variations provide a wide range of domain-specific added values, but share similarities with FabSim3 in that they also contribute towards making complex simulation workflows easier to execute and modify. FabSim3 is built on top of Fabric2, 2  a Python library for executing shell commands remotely over SSH, and therefore shares automation and remote access features with Fabric 2 and other system-level automation tools such as Ansible 3  and Homebrew.
Base components Base components deliver the application-agnostic and platform-agnostic functionalities in FabSim3. These include essential functionalities such as job submission, ensemble execution, file staging or local script execution. The functionalities in the base components are tied to FabSim3 itself, but it does leverage pattern code that is entirely tool-agnostic. These tool-agnostic functionalities are part of the patterns. Base components rely on the functionalities provided by the Fabric2 library and serve to simplify machine selection, provide essential command-line tools, expose a unified API to external Python scripts, and provide building blocks for job submission and management for the other parts of the toolkit.
Remote applications execution To submit a job for execution, FabSim3 prepares a platform-specific job script using a two-phase template system, which inserts machine-specific instructions, followed by application-specific instructions (containing machine-specific variables). This script is then submitted to the remote batch system, such as SLURM or PBS. We use a Python3 built-in pyTemplate substitution system  5  to generate the required script for job submission. Similar to machine-specific configurations, we also need a proper template script for job submission for each type of machine and/or batch system. This template script contains scheduler-specific commands for job definition. By using the template system, FabSim3 loads and combines the required variables from the machine and user specific configurations yaml files, � fabsim localhost avail_plugin machine_config_info prints the defaults and user overwritten values of the target host.
Command-line interface FabSim3 exposes a range of command-line functionalities through the Fabric2 library. 6 It allows users to define their own FabSim commands as well, mapping Python function directly to the command-line interface. All FabSim3 commands adhere the following structure: ∠ fabsim <machine_name> <task name>[:<arg1=x1>,. ,<argN=xN>] When a user invokes a fabsim command, (a) the remote machine name, (b) the called task name, and (c) all input arguments for the task (if exists) are extracted from the context of that command. We describe a number of tasks commonly used in FabSim3 in Table  1.