dataesr/scientific-paragraphs-categorization huggingface dataset:
B. CONTRIBUTIONS AND INNOVATIONS We now summarize our main contributions and contrast them with existing work. While existing studies usually focus on a specific and fragmented aspect of cybersecurity in IIoT (e. g. , homomorphic encryption, deep learning application for a specific attack type, etc. ), there is a limited body of literature that reports on design and deployment of end-toend cybersecurity systems for a targeted industrial domain. We contribute to bridging this gap by providing design, deployment, and evaluation of a comprehensive end-to-end cybersecurity system for the targeted industrial application, namely the smart logistics and the smart factory use cases in the manufacturing context. We report here on the system architecture and its integrative parts' descriptions, and we illustrate and report on the system operation and deployment on real industrial data for 1) detecting anomalies in IIoT readings; and 2) generating response to data manipulation attacks.
D. EDGE, FIELD GATEWAY, AND CLOUD LAYERS We now describe the overall system from the 3 layers perspective (Figure  1 ). The edge node layer includes the devices and sensors that provide the data that feed the whole framework in both Smart Factory (based on Raspberry Pi like devices) and Smart Logistics (based on in-house designed IoT devices) use cases. It also features lightweight anomaly detection modules and hardware-enabled security. The devices are described in more detail in Sections II-K and II-L. Field gateway (FG) is an intermediate (fog) layer of our architecture (Figure  1 ), acting as an element that communicates with the edge nodes on one side and the cloud on the other. FG possesses intermediate computational power compared to the low power edge node layer and the high power cloud layer.
E. COMMUNICATION THROUGH LAYERS -DATA FUSION BUS (DFB) For all layers of the architecture it is very important to have safe and reliable means of internal communication. For this reason our proposed architecture uses the Data Fusion Bus component which is a secure message queue implementation based on Apache Kafka. Distributed message queues such as Apache Kafka allow for easy to implement message-based communication in large systems. They also allow asynchronous communication where needed and they are often designed with high-throughput, scalable and high availability systems in mind. This characterstic combined with extensive usage of container and container management software (Kubernetes 2  was used for our system) allows for very high and dynamic, adjustable scalability of our system.
Apache Kafka is also very compatible with various platforms and programming languages, and it offers various built-in stream operations for advanced message processing, filtering and so on. All system components which we describe in following sections use this single message bus to communicate with each other. Components publish information to various message queue topics, and other components subscribe to topics which are relevant to them. The messages are also permanently stored for future analysis. It is important to clarify that the IIoT data (or payload, which is to be found in various messages) is encrypted so even in case of a system breach the data remains private. This process of payload encryption will be described in Section II-F.
F. DECENTRALIZED ACCESS CONTROL The C4IIoT architecture includes a decentralized access control (DAC) solution, allowing to control the access to data by various entities, to enable auditability of various events and policies, and to verify the integrity of data items. One core element of the DAC is applying encryption in order to restrict access to data such as sensor readings. We apply ciphertextpolicy attribute-based encryption (CP-ABE), a type of publickey encryption where data consumers, such as the C4IIoT analytics service (BACS, Section II-N), are each granted with a personal secret key that is associated with a set of attributes characterizing its holder (for example: organization, role, purpose of consuming the data, etc. ). Entities generating the sensor readings encrypt them with a public key and specify an access policy to the encrypted data as part of the process, describing who shall be allowed to decrypt it in the ''language of attributes''.
This mechanism has built-in elements of decentralization. Once a data item is encrypted, no central authority is required to evaluate the access policy and grant access to the data. The decentralized access control also relies on Hyperledger Fabric (HLF), which is a permission-enabled blockchain with support for executing smart contracts. HLF enables auditability of events and access policies as well as assure the integrity of data in C4IIoT. When sensor readings are created in the edge nodes, or when being stored on the cloud storage service, a corresponding record is logged in the HLF channel. These tamper-proof records include a pointer to the place where the data item is stored, a hash of the data taken in the time when it was created, and the CP-ABE access policy used to encrypt it. This solution allows the entities involved in C4IIoT to monitor and verify the integrity of the data and detect data manipulation attacks.
G. SECURITY ASSURANCE MODULE The Security Assurance Module (SAM) is a model driver tool responsible for monitoring, testing, and assessing the runtime operations of the C4IIoT architecture. This component is auditing critical components and processes of the infrastructure while leveraging monitoring mechanisms developed in the context of project. SAM provides an evidence-based view of the security posture of the C4IIoT architecture, with accountability provisions for changes that occur in said posture and the analysis of their cascading effects, supporting the runtime checking based on sets of associated claims and assessments. The real time, continuous assessment of the security posture of the C4IIoT architecture is enabled by a purpose-built Event Captor Module based on Elasticsearch  [25] (ELK stack), which is responsible for creating and aggregating events as the required evidence from multiple sources related to the operation of individual components, as well as the overarching processes where these components are involved in.
Those events are digested by the EVEREST tool (details are described below in this section), where specific rules are set end checked in real-time for violations. This way, SAM supports several built-in security assessments addressing the CIA principles along with custom metrics. In more detail, the SAM is comprised of five primary modules: 1) Cyber System Asset Loader: The component responsible for receiving the system's asset model for the target organization. This model includes the assets of the organization and their relations, security properties for these assets, the threats that may violate these properties, and the security controls that protect the assets and is based on STS's Assurance Model. 2) Vulnerability Analyzer (VA): The Vulnerability Analyzer is responsible to identify known vulnerabilities of assets defined within an organisations' asset model based on the well established National Vulnerability Database (NVD) of NIST  [26].
The module includes two components, (a) the vulnerability loader and (b) the vulnerability database. 3) Dynamic Tester: The component responsible for executing dynamic testing assessment (e. g. penetration testing). The module incorporates varies open-source tools such as OpenVAS  [27] , in order to assess the occurrence and exploitability of identified vulnerabilities in the target system. 4) Event Captor (EC) Module: The Event Captor Module is a tool that creates a variety of event types related with the assured system (e. g. user logins and, file accesses) and pushes them towards EVEREST for evaluation. Data and events are mostly collected through Elasticsearch based on lightweight shippers (namely Beats), such as Filebeat, Metricbeat, Packetbeat, etc. , that forwards and centralizes log data.
As seen in Figure  2 , MEDICI consists of three services called Request, Response, and Network. The role of the Request Server is to handle incoming offloading requests from the edge devices and forward them to the Decision Maker where the actual decision on which anomaly detection model should be triggered is made. Whenever an anomaly detection task is executed, relevant execution history information (e. g. inference times, task size and confidence levels) and network data (e. g. round-trip latency and transmission times) are gathered by the Response Server and Network Server respectively. History information and network data are then stored in dynamic storage (Execution Map and Network Map) to inform future decisions.
1) CONTINUOUS VERIFICATION (BINSEC) BINSEC is a platform for static analysis of software binaries using formal methods. BINSEC operates at binary level, i. e. on executable programs (e. g. exe files) after they have been compiled from source, which is typical for programs written in languages like C, C++, Rust, Go, Fortran, Ada or Pascal. Binary executables contain machine code, a combination of low-level instructions, designed for execution by a specific processor. Therefore, BINSEC must analyse for different hardware architectures which have different instruction sets. Typical examples of its usage include vulnerability discovery (finding new security bugs in existing programs), vulnerability analysis (finding the specific conditions under which a vulnerability can be exploited by an attacker, e.
g. Stuxnet-alike  [30] ), reverse engineering (understanding the behaviour of a program without access to its source code), malware analysis (reverse engineering on obfuscated binary code produced to make reverse engineering more difficult), program verification at the binary level (proving that a binary program meets some property, for instance that a binary program does not suffer from buffer overflows), program verification in programs containing assembly/binary fragments (verifying a program at the source level, using BINSEC to help it understand the assembly parts or external binary-only libraries used by the program). For integration of BINSEC in the system architecture, the key constraints for integrating a binary code analysis for continuous verification in the mitigation engine are automation (minimal intervention from the user), precision (low rate of false positives), and security guarantees (necessity to not trade security for less automation).
A Prometheus database that stores the gathered metrics. A Grafana UI that displays the infrastructure's state. For the smart factory use case, the SDN fabric is built as shown in the Fig. 3. Some Raspberry Pi mimics the communicating factory hardware. Some COTS hosts act as the rack mounted network switches. They run an Open vSwitch  [33]  daemon. It listens to OpenFlow rules and steer the data path accordingly to the SDN rules. The Cyber-Attack Runtime Mitigation Action Search (CAR-MAS) component is presented in detail in  [34]. It takes as input from the Advanced Visualization Toolkit (AVT), a set of detected attack actions, each accompanied with the business loss that they would bring about if left unmitigated. It produces and sends as response to the AVT a proposed list of network reconfiguration action sets to mitigate the input attack, in decreasing order of their estimated business loss reduction.
CARMAS assembles five sub-components in a Docker containerized REST web service: 1) The Inference Engine (IE), a general-purpose, application-independent, rule-based artificial intelligence automated reasoner  [35]  to interpret applicationspecific, Knowledge Bases (KB) in a formal yet executable language that parsimoniously integrates the constraint  [36] ,  [37] , logic  [38] ,  [39] , objectoriented  [40] ,  [41]  and service-oriented programming paradigms  [42] , resulting in what we coin Constraint Object-Oriented Logic Programming as a Service (COOLPS); 2) The ontology, a COOLPS KB representing an application-independent, conceptual model of IIoT networks, vulnerabilities, attack actions and network reconfiguration mitigation actions and their relations; 3) The Constraint Optimization Problem (COP) builder, a COOLPS KB which interpretation by the IE builds the COP of finding the best mitigation for the input suspected ongoing cyberattack; 4) The COP solver, a COOLPS KB which interpretation by the IE solves the built COP; 5) The service-oriented wrapper, a COOLPS KB which interpretation by the IE starts a web server to communicate with the AVT, and then, for each REST request, (a) convert its JSON payload into a query submitted to the COP builder, (b) forwards the builder's answer as a query to the COP solver, (c) converts the solver's answer into a JSON payload for the REST response that (d) the web server then sends back to the AVT.
K. SMART FACTORY EDGE DEVICES The edge node for the Smart Factory use case is designed following the established requirements, according to which, these nodes are placed on autonomous ground vehicles (AGVs). The AGVs are located in the factory, where they have virtually unlimited energy. These vehicles have a big energy consumption, as for example a direct tap a power input or a set a big batteries, hence, the IoT devices embedded in these vehicles do not have particular power restrictions. Due to this feature, IoT nodes contain a relatively powerful microprocessor, such as the ones found on Raspberry Pi devices. Attached to it, there are different connected devices, which form the node and add a hardware security layer. This layer is achieved through the use of several Hardware Security Modules (HSMs).
L. SMART LOGISTICS EDGE DEVICES The edge node devices for Smart Logistics use case have been custom built, designed and manufactured in-house within the C4IIoT project, aiming to be low power due to battery-powered operation, but still capable of running lightweight anomaly detection tasks. The CPU is a low-power ARM Cortex M0+ operating at 16MHz with 32kB/256kB of SRAM/FLASH memory for the data/application code. Such limited resources are fit for the required tasks of sensor data acquisition, secured communication with the field gateway, and lightweight anomaly detection. For wireless connectivity, it features NB-IoT and LTE-M, new 3GPP communication standards. Where LTE carrier might be unavailable, EGPRS fallback is supported to ensure connectivity in such areas. Geolocalization is supported by the integrated GNSS module.
M. HARDWARE ENABLED SECURITY Hardware-enabled security plays a significant role in the C4IIoT architecture, since it forms the base for many modules that are built on top of it, including the decentralized access control (DAC) technologies. The Hardware Security Module (HSM) that has been added in the edge nodes offers robustness and trustworthiness both in the operations and the data collected from the IoT devices. There are different HSMs included in the two scenarios: Smart Factory and Smart Logistics. The main difference between these two scenarios is the constraints of the IoT devices themselves. In the Smart Factory use case, the IoT devices are placed in automatic guided vehicles (AGVs). The work is carried out inside the factory, hence there are no energy constraints, enabling IoT nodes to contain a high power microprocessor, such as a Raspberry Pi platform.
In the inbound Smart Logistics scenario, the IoT devices are attached to containers, which results to significant power restrictions due to the fact the devices are powered by batteries only. In this case, IoT devices developed with low-power microcontrollers are essential. Both the hardware and software running on IoT devices is conditioned by this feature. In the case of software the anomaly detection mechanisms are lighter than in other layers of the architecture. Furthermore, the hardware elements embedded in the IoT device also vary from the different scenarios. In the Smart Factory use case the hardware security module used in the Raspberry Pi is the Infineon OPTIGA TM VOLUME 10, 2022 TPM2. 0. OPTIGA TM TPM2. 0, as we will see later, is a suitable HSM for the Raspberry Pi, as it offers more robust operations and provides more advanced mechanisms for operating system devices.
1) HORIZONTAL DEVICE-TO-DEVICE SECURITY Within the C4IIoT architecture, data aggregated by the IIoT devices (edge nodes) may not be shared among different devices or with data federation partners in raw form. Furthermore, a data federation partner may want to protect its data and analytics results from its competitors, or to monetize its data selectively. This, Level-2 security, of the C4IIoT framework has been built upon multiple technologies brought by the partners in order to support this. One of them is IBM's decentralized access control (DAC) solution that utilizes distributed ledger technologies (Blockchain) and attribute-based encryption (ABE) in order to restrict access to data using privacy-aware policies, enable auditability of events and access policies and assure the integrity of data in C4IIoT.
N. COGNITIVE SECURITY The Behavioural Analysis & Cognitive Security (BACS) Framework includes behavioural models based on advanced deep learning techniques to provide more contextual information and form an advanced anomaly detection model for the entire IoT ecosystem. The framework takes into account that each device is not isolated and includes its interactions with other devices. BACS is depicted in Fig. 5  and it consists of the following three main packages: • BACSCL (BACS Cloud Layer) performing anomaly detection based on deep autoencoder forests (unsupervised Anomaly Detection (AD)) and deep neural network forests (supervised AD) implemented in Python using the Tensorflow 2 library. • BACSPY providing anomaly detection based on outlier detection, classification and representation learning algorithms implemented in Python using Tensorflow 2, scikit-learn and PyOD libraries • BACSC contains lightweight anomaly detection routines implemented in C for constrained microcontroller and based on IIoT devices planned for the Smart Logistics use case.
In order to preserve private information in privacy-sensitive data, we deploy differentially private methods. A method that analysis certain data at the input and produces a certain output is said to be differentially private, if by looking at the output, one cannot determine whether any individual's data was included in the original dataset or not for analysis. In other words, the guarantee of a differentially private algorithm is that its behavior hardly changes when a single individual joins or leaves the dataset -anything the algorithm might output on a database containing some individual's information is almost as likely to have come from a database without that individual's information. Some of the common practices to achieve differential privacy are i) adding noise to the samples during the training process (indistinguishability of samples); and ii) adding noise to the gradient computed on a sample (indistinguishability of gradients of samples).
P. USER INTERFACE The C4IIoT user interface offers active real-time monitoring, historical analysis and possible mitigation actions for specific attacks. The real-time monitoring consists on data produced by the edge enriched with information from the applied anomaly detection mechanisms, and information from the network traffic analysis. An alerting mechanism informs the end-user about detected attacks and provides the option to select among suggested mitigation actions. Finally, the historical analysis help users to understand the evolution of the edge devices behaviour and look for potential relationships or behavioural patterns among the monitored assets.
III. SYSTEM PERFORMANCE AND VALIDATION We now present several evaluation results for the C4IIoT framework. Specifically, we demonstrate validity and performance of the framework by considering anomaly detection validity and performance, as well as the overall system and communication performance. The C4IIoT framework supports detection of various types of cybersecurity attacks, through the utilization of its different components (Figure  1 ). Table  1  shows the mapping between various types of attacks and the responsible components. In this paper, we demonstrate the framework capabilities on a concrete example of the Data Manipulation Attack. We next proceed by describing the setup and data preparation for the subsequent evaluations (for anomaly detection). Then, the overall system and communication performance will be described in more detail in Section III-A, the anomaly detection performance is discussed in III-B, and the data Manipulation Attack testing will be detailed in Section III-C.
For anomaly detection components, a thorough evaluation of both unsupervised and supervised BACS models was planned to be done on labeled real datasets. While real data for nominal operation in the industrial environment has been acquired, acquisition of labeled data with positive labels that correspond to real anomalies in the industrial environment is difficult to acquire. Henceforth, we work with real nominal (normal operation) data and generate on top of it synthetic anomalies. We evaluated the BACS component with synthetic anomalies, where one can differentiate between i) isolated, and ii) continuous anomalies. • Single (isolated) anomalies are formed in a single timestamp via one of 3 strategies, which are discussed bellow. This type of anomalies reflect the anomalous behaviour of sensors.
• Continuous anomalies stretch over a time interval and they affect 10 distinct consecutive data samples. This type of anomalies reflect the behaviour of physical values that are measured by the sensors. The strategy that we use to form anomalies is to replace a value x from the column c in the original dataset with: • make_zero -zero; • make_small -a sample from distribution X small = x (1 -U [0. 1, 0. 4)); • make_large -a sample from distribution X large = x (1 + U [0. 1, 0. 4)); • randomize -a sample from distribution X randomize = U [min x {x|x ∈ c}, max x {x|x ∈ c}). Here, U [a, b) denotes the uniform distribution on the interval [a, b), b > a. A. COMMUNICATION PERFORMANCE Speed and reliability, along with data integrity, are important aspects of the architecture. The Data Fusion Bus is a component based on Apache Kafka  [46] , which offers management capabilities of the system through an API, which offers a fast, reliable and secure way to transfer data between the components and the layers of C4IIoT architecture.
In the testing environment, using approximately ten simulated devices sending a message every 7-9 seconds a traffic of 5kB/s was measured. This kind of throughput is very low for Kafka infrastructure, strongly suggesting that even hundreds of devices, either AGVs or Smart Logistics could be easily supported by this architecture. Data from Kafka is consumed by various components of the C4IIoT architecture, at almost real time, allowing the detection of possible cyber attacks to be reported fast. All components that need to process the data, consume them at the rate they can, therefore avoiding an overflow of data which could potentially disrupt their service. Additionally, data which is needed by more than one components, is consumed by the relevant Kafka topic without delay since it becomes available for all at the same time.