System for the cybersecurity of critical OT devices with intrinsically secure access to it services, including sentinel devices and self-healing ai agents

Abstract

A system called SENECA™ (Secure Edge Neuromorphic computing Ecosystem using Auto-healing Al Agents) that is inherently secure (secure by design) and capable of ensuring the cybersecurity of devices connected to critical OT (Operational Technologies) infrastructures, comprising one or more sentinel devices (1) called SENECA dAlsy™ (data-diode-based Autohealing Intelligent sentry) composed of two symmetrical computational systems (2) (3), which in turn are interfaced with each other via two inherently unidirectional channels (4)(5) and capable of accessing online IT (Information Technologies) services for cybersecurity, SENECA CyberSecurity Management Services (CMS)(6), and artificial intelligence, Seneca Al Management Services (AIMS) (7) respectively capable of creating, distributing, and managing digital hw and sw keys and certificates for secure, authenticated, authorized, and auditable access to peripherals, programs, and service providers, and of using an LLM (SENECA LLM)(8) trained to generate Self-Healing Al Agents (SENECA 3A Agents)(9) capable of autonomously discovering, monitoring, diagnosing, healing, and testing machinery operating in the critical OT area using machine learning code (SENECA PATCH) (10) managed by LLM and SLM / TINYLM systems operating with homomorphic encrypted connection of network weights, executable both on the cloud and optionally on distributed computing architecture, SENECA DLT (25), with dAlsy™ edge devices also configurable to operate via smart contracts between machines, Smart Contracts (24) and as distributed autonomous computing units (26) (swarm intelligence) and with limited resources (TINYML) and / or dedicated neuromorphic chips, making OT machinery secure, self-repairing, and resilient in the event of cyberattacks and malfunctions.

Description

[0001] “System for the cybersecurity of critical OT devices with intrinsically secure access to IT services, including sentinel devices and self-healing Al agents”

[0002] *****

[0003] The present invention relates to a system for the cybersecurity of connected devices called SENECA™ (Secure Edge Neuromorphic Ecosystem using Auto-healing Al Agents), in particular a system for ensuring the cybersecurity of connected devices in critical OT (Operational Technologies) infrastructures while such connected devices receive IT (Information Technologies) services from a cloud system.

[0004] An industrial planning approach called Industry 5.0 has recently emerged. This term generally refers to the evolution of the manufacturing and industrial sector, which closely integrates artificial intelligence (Al), the Internet of Things (loT), advanced robotics, and human-machine collaboration to create smarter, more resilient, and more sustainable production systems. Unlike Industry 4.0, which focused primarily on the automation and digitization of production processes, Industry 5.0 places greater emphasis on safety and security in the use of advanced technologies to improve quality of life, production customization, and environmental sustainability, prioritizing the safety of critical infrastructure, facilities, and machinery such as power plants, industrial plants, biomedical installations, and widespread mobility.

[0005] With the rise of Industry 5.0, we're seeing more and more online connections for machines in critical areas, many of which weren't subject to strict cybersecurity requirements during the evolution previously known as Industry 4.0. The current evolution towards increasingly connected and interoperable devices and machinery, with growing links between critical internal operating environments (Operational Technologies, OT) and cloud-based information systems (Information Technologies, IT), has led to a greater need for security, through devices, standards, and infrastructures capable of ensuring reliability, security, and advanced cybersecurity controls. In particular, devices in critical infrastructures such as those in energy, industrial, medical, mobility, and military security and defense scenarios are required to be resilient “by design” at the hardware design level, for example, by using closed execution zones for the secure execution of programs (e.g., TEE, Trusted Execution Environment) , preventing physical access to data storage areas (e.g., anti-memory scamming) and / or implementing secure communication protocols and channels, such as so-called “data diodes,” which in some implementations use opto-electronic signal conversion to enforce unidirectional communications in order to physically segregate critical facilities from external attacks.

[0006] However, these measures often do not allow for full interoperability and detection of critical issues and malfunctions in machinery operating in a segregated OT area, limiting the usability and effectiveness of the IT services provided. Furthermore, they do not allow for secure “by design” connection to remote computing centers for training algorithms and Al solutions that require significant computational resources, such as the recent LLMs (Large Language Models).

[0007] Most current systems suffer from significant limitations, particularly because they do not have an integrated cybersecurity management ecosystem for the OT, IT, and Al parts, involving all possible communication channels between critical OT operational areas and IT online services and vice versa during the training and delivery phases of the algorithms.

[0008] Innovative approaches that allow services designed to monitor and reinforce existing infrastructures in an integrated, continuous, and automated manner using the latest Artificial Intelligence techniques, such as LLM (Large Language Models) capable of generating code and Al agents capable of executing processes, making decisions, and interacting intelligently with the surrounding environment are therefore not only desirable but necessary to increase the cyber resilience of Industry 5.0. However, the computational limitations often found in OT environments, where machinery and equipment are often interfaced through control systems with limited resources such as PLCs and field controllers, greatly limit Al experimentation in OT areas, where operators are very careful to limit the incremental exposure of possible attack surfaces that integrated approaches with online IT components risk opening up.

[0009] In summary, existing cybersecurity systems in the OT area are unable to dynamically adapt to new threats or changes in the environment in which they operate, and possible solutions are limited by the need for high computational resources, which are not always compatible with the existing infrastructure in the OT environment.

[0010] As a result, possible new automation technologies such as Al agents and LLM are not widely used for effective OT cybersecurity monitoring, given the limited resources in critical contexts.

[0011] In contrast, in the current cloud-based IT landscape, the integration of generative Al with new features to produce efficient and functional code on demand, as demonstrated by the evolution of GitHub Copilot™ and interactive dialogue systems with reinforcement learning techniques available in the latest versions of ChatGPT™, Claude™, Gemini™, and Mistral™, is revolutionizing the IT industry by offering Al services capable of autonomously developing complex software solutions by linking code generation with operational decisions.

[0012] A particularly promising area of application for this code generation technology with LLM is the generation of code optimized for Al operation on devices with limited resources, such as those found in critical OT areas, a sector generically defined as TINYML, a subcategory of Machine Learning characterized by the optimization of algorithms to enable their operation on devices with limited hardware resources, such as those operating with ARM™ or Raspberry Pi™ microprocessors. TINYML techniques range from those using shallow neural networks (i.e., Shallow Learning) to those using quantization and deep neural network reduction methods, such as network pruning and the reduction of weights from floating point to integer, to the use of dedicated systems on chip (SOC) and software modules (SOM), with code implemented on dedicated ASIC HW circuits or programmed on FPGA media. Whatever form they take, TINYML techniques are essential for reducing memory and computational power requirements while increasing the security of the Al algorithms implemented, allowing edge devices in particular to run Al models in an explainable (explainable Al) and trustworthy (trustworthy Al) manner, i.e., efficiently, securely, and transparently, all of which are highly sought-after characteristics in highly critical infrastructure environments. However, although the most advanced current TINYML techniques are effective in reducing the size of machine learning models for use on devices with limited resources, they remain complex and difficult to optimize and test, often representing a barrier to wider adoption of TINYML techniques in the OT field.

[0013] A particular area of interest in the TINYML macro sector is reduced- parameter language models, i.e., scaled-down versions of LLMs optimized to function, especially in inference on limited resources such as those available on mobile devices and, indeed, on-premise environments in the industrial sector.

[0014] A Small Language Model (SLM) or TINY Language Model (TLM) is a version derived from a Large Language Model (LLM) through the following processes:

[0015] - Distillation (knowledge distillation): the small model learns to imitate the behavior of the large one.

[0016] - Pruning / Quantization: reduction of parameters while maintaining performance.

[0017] - Fine-tuning on a subset of data.

[0018] It is worth noting that although SLMs / TLMs contain fewer parameters than LLMs, they can be trained more efficiently. According to the scaling laws proposed by OpenAI and subsequently revised by DeepMind, the optimal performance of a model depends on a balance between model size and training data quantity. DeepMind has shown that a smaller model (such as Chinchilla) can outperform larger models when trained on significantly higher amounts of data.

[0019] This implies that an SLM is not simply a “cut-down” version of an LLM, but can be designed and trained independently to achieve optimal performance in specific contexts.

[0020] - The SLM was derived from an LLM through:

[0021] - Distillation (knowledge distillation): the small model learns to imitate the behavior of the large one.

[0022] - Pruning / Quantization: reduction of parameters while maintaining performance.

[0023] - Fine-tuning on a subset of data.

[0024] The present SENECA invention aims to exploit the correlation between the originating LLM and SLM / TLM to extend the security of its OT sentinels beyond the normal security techniques of generic TINYML code.

[0025] In particular, several techniques have been developed for the automatic testing of ML and TINYML code to date, including:

[0026] • Adversarial Testing: Evaluates the robustness of the model against malicious inputs designed to deceive it.

[0027] • Security Testing: Ensures that the model is protected against various types of attacks, such as data poisoning and model inversion.

[0028] • Explainability Tools: Tools such as SHAP (SHapley Additive exPlanations) and LIME (Local Interpretable Model-agnostic Explanations) help identify vulnerabilities by explaining the model's predictions.

[0029] • Model Monitoring: Continuously monitors model performance to detect security breaches or anomalies. • Fuzzy Testing: Use random or unexpected inputs to find vulnerabilities and weaknesses in the model.

[0030] These methods help protect machine learning models with automated testing against potential cybersecurity threats and are all applicable to TINYLM code as well.

[0031] However, a TINYLM potentially generated by LLM servers in the cloud and distributed on OT sentinel devices of the type proposed by SENECA maintains a strong link with the originating LLM, with which it is possible to optimize the communication security and monitoring of the devices on which the SLM / TINYLM is executed.

[0032] The proposed solution involves designing a distillation pipeline (scripts, datasets, hyperparameters) such that the central LLM can be used to re- execute the distillation using the new LLM as a “teacher” and perform a delta update by calculating the difference between the weights of the old and new LLMs and applying a proportional update to the SLMs / TLMs distributed on the OT sentinels.

[0033] In this highly evolving technological landscape, it is important to highlight the role played by new standardization and regulatory initiatives, particularly within the EU, for the safety and certification of loT devices and industrial and medical equipment, as well as the Al algorithms and data services that can be used on them.

[0034] In particular, the Cyber Resilience Act (CRA) and the new machine regulations for industrial and biomedical markets recently issued by the European Community constitute a reference framework that is being synergistically integrated with the GDPR regulation and the new EU Al Act and EU Digital Services Act directives, EU Data Act, and EU Digital Services Act, which aim to regulate the use of machine data by human and automated actors, all in a context of increasing security and interoperability, placing maximum emphasis on infrastructure resilience and the security and certification of algorithms and data operating on loT machines and peripherals, while also opening up important business models and monetization of possible data and related digital services available on the cloud. These regulations require not only the adoption of security solutions that effectively protect critical infrastructure, but also that the machines operating within these perimeters be accessible and updatable so that they can adapt to new services and technologies for the preventive maintenance of the hardware involved and the adaptive evolution of the software used.

[0035] Finally, there are many new developments addressing these issues, including in international standardization bodies, with regard to the secure, open, and interoperable management of machine data. In particular, the latest specifications from the largest private initiative for industrial data interoperability, the OPC FOUNDATION, have produced many specifications for semantic twins of machines (OPC UA Companion Specs) and for their cybersecurity. In particular, OPC UA provides an integrated framework of services called GDS (Global Discovery Services) which, among other things, allow the discovery of networked machines and offer them services through centralized entities called “authorities,” including one for issuing and managing security keys and certificates called PKI (Private Key Infrastructure). These specifications have also been adopted and adapted by various national initiatives, such as the Italian “Cluster Fabbrica Intelligente” (Smart Factory Cluster) and the German “Industrie 4.0,” the latter being the developer of an XML format for digital twins of machinery and industrial assets called Asset Administration Shell (AAS), which brings together various half-models and APIs, including for authentication and secure access authorization specifications, opening up new possibilities for secure communication between devices and services in the OT and IT fields.

[0036] These standards address machine security in three main areas:

[0037] • Authentication between client and server applications

[0038] • Authorization to determine whether a user is authorized to connect and / or perform the requested action • Confidentiality and integrity of communications

[0039] This means that a layered approach to security is crucial for an inherently “secure by design” implementation, where each layer is responsible for verifying that the connection / action is permitted, and any unapproved action can be quickly rejected.

[0040] In particular, for a holistic approach, machine security must be addressed at four levels, each based on the transparent security of the underlying levels

[0041] 1. Physical Layer: This is the lowest level at which the device, machine, and / or peripheral has the ability to express itself in HW sources, on chips, ASICs, or FPGAs, physically integrated with the machinery, the first certificate of the security line (Root of Trust, RoT) originating from them and managed by central authorities such as the PKI infrastructure that controls the certificates issued, a fundamental pillar of security on which computer systems and connected mobile devices are based. Since RoT schemes must be inherently reliable, their encryption must be designed with maximum security from the outset. Cryptographic security depends on the keys used to encrypt and decrypt data, as well as for functions such as digital signature generation and verification. RoT schemes are typically included in hardened, tamper-resistant hardware security modules (HSMs), such as Trusted Platform Module (TPM) chips, which protect cryptographic processes in hardware circuits. HSMs are tested, validated, and certified to the highest security standards, including FIPS 140-2 and Common Criteria.

[0042] 2. Transport Layer: At this level, the focus is on the transport channel, such as the IP address of the machine and the port on which the application is listening. This layer may also include defenses outside the scope of the communication channel (e.g., firewalls, access control lists, etc.) that could reject a connection before it is established. Transport Layer security is crucial for protecting data during its transmission between the client and server. This layer uses protocols such as TLS (Transport Layer Security) and SSL (Secure Sockets Layer) to ensure that communications are encrypted and that data cannot be intercepted or altered by third parties. TLS provides authentication, data integrity, and confidentiality, ensuring that only authorized parties can access the information being transmitted.

[0043] 3. Communication Layer: This is where most of the activity takes place. When the client connects to the server, a secure channel is established where keys and certificates are exchanged. These are used not only to authenticate the applications and hosts making the connections, but also to encrypt and sign the messages sent, peripherals, and services. If the certificates that the client and / or server are using are not trusted, the application may reject the connection attempt while the secure channel is being established. A key element of this security is the use of PKI infrastructures that provide a framework for managing cryptographic keys and digital certificates. PKI uses a pair of keys, one public and one private, to encrypt and decrypt data, ensuring that only authorized parties can access the information being transmitted. Digital certificates, issued by a certificate authority (CA), authenticate the identity of devices and users, ensuring that communications are secure and reliable.

[0044] 4. Application Layer: This is where user authentication and calls / commands to the underlying layers take place. At this level, we already know that the host and application making the call are trusted, the conversation between client and server is secure, and therefore the only thing left to verify is whether the user interacting with the application is authorized to access the resources in question.

[0045] With these four levels of security in mind, there are several considerations to keep in mind when designing a system that implements clients and servers:

[0046] • Do not rely on “security by obscurity,” i.e., do not assume that keeping an OT system segregated makes it implicitly secure and unassailable. • Discover and correctly configure the server endpoint to use security.

[0047] • Consider whether the system will be publicly exposed or only accessible on an internal intranet or the Internet.

[0048] • Assess the number of clients that will connect to the system.

[0049] • Use other security measures (such as user authorization or firewalls).

[0050] • Configure users and their access permissions in a granular manner.

[0051] • Be aware of the certificates you are accepting.

[0052] These considerations help ensure that the system meets the required security requirements.

[0053] Despite this, there are still significant challenges in building systems that can fully implement and manage these levels of security in the transition between OT and IT areas while maintaining high levels of security and operational efficiency, especially where the Application Layer uses algorithms and applications that are increasingly capable of producing code and making decisions autonomously, as is possible with the latest Generative and Agentic AI techniques.

[0054] In particular, current cloud-based Al systems, often operating with limited implicit security, do not have sufficient levels of transparency and explainability.

[0055] As a result, there are many security limitations on one or more of the four security levels introduced above when it comes to ensuring the execution of algorithms on devices with limited resources, especially in edge contexts. Finally, there is a lack of systems capable of self-testing, dynamically adapting, and self-repairing in response to new types of attacks or anomalies without manual intervention. At the same time, the systems currently known in the literature show significant difficulties in meeting the growing and stringent European regulations regarding the security and resilience of critical infrastructures, where the use of Generative and Agentic Al raises pressing questions of actual reliability and security.

[0056] Ensuring that the code automatically generated by Al agents, including for cybersecurity management, is itself free of vulnerabilities and optimized for specific critical applications is therefore a considerable challenge.

[0057] The document VIACHESLAV ZOLOTNIKOV: "Industrial Internet of Things: Volume G4 - Security Framework 11 , IEEE DRAFT WGDS; 862055733031 , IEEE-SA IMEET CENTRAL, PISCATAWAY, NJ USA vol. 2413 May 25, 2016 (2016-05-25), pages 1 -144, describes a security framework for the Industrial Internet of Things (HoT), in which OT and IT systems are integrated and protected according to “security by design” principles. In particular, the document discloses the use of gateways or edge endpoints equipped with computational and communication capabilities, which can interface with cloud security and artificial intelligence services to receive software updates, verify their integrity, and redistribute them securely to connected OT devices, with the aim of improving their resilience and self-repair capabilities. However, the document does not comprehensively address the needs for separation and control of OT and IT domains, nor does it define intrinsically binding mechanisms to ensure the unidirectionality of information flows. Furthermore, it does not describe autonomous procedures for validating and verifying distributed code, nor does it consider the computational limitations typical of devices operating in critical OT contexts.

[0058] Nor does it address in any way the related use of LLM and SLM / TinyLM in this context and the distributed retraining techniques proposed by the SENECA patent in question. There are several ways to implement unidirectional data flows, including the use of a firewall. However, a firewall is software that can itself be subject to cyberattacks and / or bugs that make it vulnerable.

[0059] Once this flow has been secured, advanced security techniques can be used, such as the creation of message whitelists, the passing of security verification tests, and, finally, the passing of the weights of new encrypted SLM / TINYLM versions, in which only the sentinel device sees the Language Model in clear text, while the entire SLM / TINYLM parameter regeneration pipeline is encrypted. TINYLM versions, in which only the sentinel device sees the Language Model in clear text, while the entire SLM / TINYLM parameter regeneration pipeline is carried out in encrypted form, as allowed, for example, by homomorphic encryption, which allows weights from various sentinel devices to be added together and the new SLM / TINYLM to be redistributed to all connected sentinels.

[0060] The present invention therefore aims to overcome these disadvantages inherent in the state of the art of using the latest Al techniques for cybersecurity in OT systems through the implementation of an advanced and integrated security ecosystem capable of generating and using self- healing Al code, i.e., self-configuring, self-diagnosing, and self-testing for devices connected in the OT area, generated by AGENTS based on a central LLM capable of generating SLM / TINYLM versions by exploiting the potential of Generative and Agentic Al even in the context of limited and segregated resources typical of edge computing, offering an adaptable, efficient solution that complies with all new EU regulations in force and soon to be adopted in critical OT infrastructure contexts.

[0061] The present invention addresses the potentials and limitations found in the state of the art described above with a system called SENECA™ (Secure Edge Neuromorphic computing Ecosystem using Auto-healing Al Agents) comprising one or more edge sentinel devices (1 ) capable of connecting to online IT (Information Technologies) services for Cybersecurity and Artificial Intelligence and capable of generating, distributing, and testing software code and redistributing it in an intrinsically secure manner in said OT infrastructure on said edge sentinel devices and / or on said devices connected to said edge sentinel devices, making such connected devices more secure, self-healing, and resilient in the event of cyberattacks and malfunctions. Each sentinel edge device comprises two symmetrical computational areas, one of which is an OT area connected to machinery operating in said OT infrastructure and one of which is an IT area connected to said IT services, which computational areas are connected to each other by two intrinsically unidirectional communication channels, respectively an OT-IT channel to said IT services and an IT-OT channel to said OT infrastructure.

[0062] An advantage of the system of the present invention is that it provides transparent communication between the IT and OT domains, so that application services operating on the IT side can access the functionality and data of devices in the OT domain as if they were natively present in the same domain, without requiring additional software components or specific protocol adaptations.

[0063] The invention also proposes a secure architecture for the distribution and updating of Small Language Models (SLMs) in sentinel OT environments, overcoming the vulnerabilities typical of solutions based exclusively on firewalls or traditional software controls.

[0064] The system requires each peripheral node (“sentinel”) to perform local optimization or incremental retraining of its SLM, generating encrypted weights using homomorphic encryption.

[0065] Homomorphic encryption allows mathematical operations, such as the sum of language model weights, to be performed directly on encrypted data, so that the result, once decrypted, is unchanged from that obtained by operating on plaintext data, thus enabling the secure generation and updating of local versions of LLM / SLM without exposing sensitive parameters.

[0066] Homomorphic encryption is a technique that allows mathematical operations (such as addition) to be performed directly on encrypted data, so that once decrypted, the results are identical to those that would be obtained by operating on the plaintext data. Applied to linguistic models, it allows encrypted weights from multiple nodes to be combined to obtain an updated model which, after decryption, maintains consistency and integrity for local use. This technique allows weights to be sent to the cloud and the central LLM reference without ever exposing the plaintext data, allowing the central system to:

[0067] - Aggregate and combine contributions from multiple sentinels in encrypted form.

[0068] - Regenerate an updated version of the SLM, which is also encrypted.

[0069] The new model is then redistributed to the sentinels, which are the only entities that have the private key assigned at the time of distribution authorized to decrypt and use it in clear text. The entire update pipeline takes place in encrypted form, ensuring:

[0070] - Secure unidirectionality of flows to the OT.

[0071] - Protection against attacks and software vulnerabilities.

[0072] - Compliance with European regulations on cybersecurity and data protection.

[0073] The ecosystem also integrates self-configuration, self-diagnosis, and selftesting capabilities for models, leveraging agents based on a central LLM to generate optimized versions of SLM / TinyLM, even in edge computing contexts with limited resources, typical of critical OT infrastructures.

[0074] In an executive example, each channel comprises a physical electronic- to-optical conversion module and a physical optical-to-electronic conversion module.

[0075] The optical coupling makes it physically impossible for data to flow from the destination to the source, ensuring physical segregation that cannot be circumvented by software. In a further executive example, the communication channels are configured to use a message-based point-to-point communication protocol.

[0076] According to an embodiment, the system is configured to use an LLM model trained to automatically generate self-healing Al agents capable of autonomously discovering, configuring, monitoring, diagnosing, healing, and testing connected devices through the generation of software code, executable both in the cloud and on sentinel edge devices.

[0077] According to an improvement, said self-healing Al agents are configured to generate Tiny Language Model (TINYLM) software code.

[0078] In a third improvement with homomorphic encryption, IT-side operations are performed on encrypted data. The server receives the encrypted weights from the sentinel edge nodes and combines them (e.g., sums them) without ever seeing them in plain text. The final result remains encrypted and is sent to authorized nodes, which decrypt locally to obtain the updated model.

[0079] In a further application case, the homomorphic flow is applied to the weights of an LLM / SLM, but the server does not perform inference or training: it only performs encrypted aggregation and then redistributes the SLM / TINYLM to the sentinel nodes.

[0080] In a further executive example, the OT-IT channel is configured to transfer logs from devices connected to said OT infrastructure to the IT area of the sentinel edge device, and said IT-OT channel is configured to pass and test, in a natively secure manner, alarm and / or event notifications and / or said software code generated by said Al agents and / or connected services of the IT area to the OT area on the sentinel edge device.

[0081] In one embodiment, each sentinel edge device includes a secure HW and / or SW identification source.

[0082] According to an executive example, said communication channels are based on a protocol managed by algorithms operating in the OT and IT areas of each sentinel edge device, which algorithms are capable of managing the disassembly and reassembly of the bidirectional communication protocol in order to resubmit data to authorized remote clients of said IT services as if such data were coming directly from the IT area and, vice versa, to resubmit alarms and / or events and / or software code to said OT infrastructure as if such alarms and / or events and / or software code were coming from the OT area of the edge sentinel device without the possibility of reverse flows “by design.”

[0083] In a further executive example, the OT-IT channel is configured to use client server protocols and standards (e.g., OPC UA Server / client) and / or publish / subscribe protocols (e.g., MQTT, OPC UA PUB / SUB) through the conversion of the electronic signal into an optical signal and from optical to electronic with supporting HW and SW to maintain the signal carrier and, in the case of a bidirectional communication protocol (e.g., TCP / IP) with the disassembly and reassembly of the protocol itself to emulate client-server or publish / subscribe operation, to ensure the intrinsic unidirectionality of the channel.

[0084] In an executive example, a whitelist mechanism is provided that is configured to accept only messages digitally signed by an authorized IT service and to verify their authenticity and integrity in the OT domain before processing them.

[0085] In an executive example, the OT domain includes an artificial intelligence engine, such as but not limited to an SLM / TINYLM, residing exclusively in that domain and executing monitoring, diagnosis, or control algorithms without transferring models to IT services.

[0086] In an executive example, the artificial intelligence engine residing in the OT domain can be updated by transferring neural network weights digitally signed on the IT side and accepted in the OT domain only after running a battery of predefined hardcoded tests, configured to validate their correctness and security before the system is put into production. The architecture is thus bound to an Al update flow with weights signed and validated through hardcoded tests.

[0087] Self-healing Al agents are therefore not generic code but are bound to the cloud-signed whitelist communication model and the OT Al engine, and are subject to passing hardcoded tests on Al weights before being accepted. In the specific case of self-healing Al agents based on SLM / TINYLM, the weights can be encrypted using homomorphic techniques and are transmitted via a messaging-based communication method, with a whitelist of permitted messages and digital signatures of messages on the cloud side. The agent running on the OT side is updated by sending new weights, optionally encrypted with homomorphic neural network techniques, which are decrypted before being executed in clear text and, optionally, after verification of inclusion in the whitelist of receivable messages and / or final security verification through the execution of hardcoded tests performed on the OT side.

[0088] In one possible implementation, the system offers the option of completely disconnecting the IT-OT channel during normal operations, reconnecting it temporarily only during update procedures.

[0089] According to one embodiment, the software code is executed in a secure Trusted Execution Environment (TEE) area of the sentinel edge device and validated by an automatic verification procedure preloaded into the sentinel edge device and configured to validate that the code has not been modified or tampered with while passing through the IT area before reaching the sentinel edge device.

[0090] According to one enhancement, the code modules related to the Al update are executed in a TEE secure execution environment, and acceptance occurs only if the digitally signed neural network weights pass validation via predefined hardcoded tests.

[0091] In another embodiment, the aforementioned self-healing software code is generated by one or more of the aforementioned self-healing Al agents using a Large Language Model (LLM) and a series of tools and contexts provided to the LLM, including at least one register of the SW components of the monitored systems and at least one register of the software code published by the individual SW providers to guide the automatic generation of code that heals the recorded anomalies.

[0092] According to an executive example, this code is generated by offline LLM in an appropriate on-premise computing center that generates encrypted SLM / TINYLM code placed in a connected IT area to manage the arrival of weights from the various federated OT sentinel devices to generate an SLM code sum of the various distributed networks.

[0093] According to an executive example, the aforementioned online IT (Information Technologies) services for Cybersecurity and Artificial Intelligence use a cloud-based PKI infrastructure and Al Management System to manage the certificates and keys of the aforementioned sentinel edge devices, the aforementioned software codes, and the providers and consumers of online IT (Information Technologies) for Cybersecurity and Artificial Intelligence, the LLM, and the aforementioned self-healing Al agents.

[0094] According to a further executive example, the online IT (Information Technologies) services for Cybersecurity and Artificial Intelligence and the related PKI infrastructures, Al Management System, software code, and LLM and self-healing Al agents are managed on a distributed DLT computational architecture, using DID and NFT tokens respectively to identify the uniqueness and ownership of the edge sentinel devices or devices connected to them, managing transactions through smart contracts between machines and the calculations necessary for the LLM and self-healing Al agents through distributed computing nodes (SWARM Intelligence).

[0095] According to an executive example, each of these nodes on the blockchain acts as an encrypted SLM / TINYML node and can add up the weights received from the previous nodes. According to a further executive example, the LLM automatically generates software code capable of running on low-resource peripherals (TINYML) in an intrinsically secure manner using a testing algorithm operating on smart contracts or with automatic verification routines.

[0096] According to an executive example, each of these nodes on the blockchain acts as an SLM / TINYML node encrypted with homomorphic technology and can add up the weights received from the previous nodes.

[0097] These and other features and advantages of the present invention will become clearer from the following description of some executive examples illustrated in the attached drawings, in which:

[0098] Fig. 1 illustrates a high-level diagram of the SENECA™ system;

[0099] Fig. 2 illustrates a detailed diagram of the unidirectional optical connection;

[0100] Fig. 3 illustrates a detailed diagram of the SENECA Cybersecurity Management Services (CMS) and Al Management Services (AIMS) and the dAlsy™ self-diagnostic, self-healing, and self-testing unit;

[0101] Fig. 4 illustrates an alternative diagram that assumes the use of DLT technology and distributed computational nodes for SENECA CMS and AIMS services

[0102] Fig. 5 illustrates the optional distributed homomorphic encryption scheme for the encrypted sharing of SLM / TINYLM network weights.

[0103] The figures illustrate an executive example of the cybersecurity system for connected devices 32 operating in the critical OT 30 area. These devices 32 can be of any type, such as industrial machines (CNC machines, industrial robots, signaling devices, etc.), biomedical machines (MRI, ultrasound, wearable devices, digital microscopes, etc.), enertech machines (meters, electrolysers, capacitors, turbines, etc.) or mobility systems (autonomous vehicles, drones, underwater exploration vehicles, etc.), etc.), enertech machines (meters, electrolysers, capacitors, turbines, etc.) or mobility systems (autonomous vehicles, drones, underwater exploration vehicles, etc.). OT infrastructure 30 also includes operational control and management systems and platforms 31 , i.e., software and hardware devices used to supervise, control, and optimize industrial processes. These include SCADA (Supervisory Control And Data Acquisition) systems, designed for real-time monitoring and remote control of sensors, actuators, and plants; MES (Manufacturing Execution System) systems, which connect management levels with the production level to coordinate and track production execution; PLM (Product Lifecycle Management) systems, which manage the product lifecycle, ensuring consistency between design and operation; and Field Controllers, including programmable logic controllers and equivalent devices, responsible for direct interaction with field machinery and equipment.

[0104] The SENECA™ ecosystem provides for each asset 31 , 32 in a critical OT area to be connected to a monitoring and self-healing unit called dAlsy™ (data-diode-based Autohealing Intelligent sentry) 1 consisting of two symmetrical computational systems 2, 3, which in turn are interfaced with each other via two intrinsically unidirectional channels 4 and 5 and Cybersecurity online IT services, SENECA CyberSecurity Management Services (CMS) 6 and Al, SENECA Al Management Services (AIMS) 7, respectively capable of creating and managing hw and sw digital keys and certificates for secure, authenticated, authorized, and auditable access to peripherals, programs, and service providers, and of using an LLM model (SENECA LLM) 8 trained to generate Self-Healing Al Agents (SENECA 3A Agents) 9 to discover, monitor, diagnose, heal, and test machinery operating in the critical OT area using machine learning code (SENECA PATCH) 10 capable of operating both on the cloud and on edge devices dAlsy™ optionally configured with dedicated chips and limited resources (TINYML).

[0105] These monitoring and self-healing units are nodes in a cloud or blockchain authentication and authorization network 21. The system is configured to be self-healing, using generative artificial intelligence models (Large Language Model) to automatically create, apply, and test security patches in response to new threats or malfunctions.

[0106] The dAlsy™ 1 self-configuring, self-monitoring, self-healing, and selftesting unit is preferably a physical gateway that can be installed in a standard industrial rack and is preferably configured to be compatible with industrial interoperability standards, enabling secure and compliant communication with other devices and systems. The monitoring unit can communicate southbound with the critical network, for example via wired or wireless connections, isolating the devices from the rest of the infrastructure in which they are installed and ensuring secure data transmission.

[0107] The monitoring and self-healing unit can then communicate northbound with the online network I via wired and / or wireless networks, such as WIFI, LORA cellular, and / or satellite.

[0108] Each dAlsy 1 self-configuring, self-monitoring, and self-healing unit is equipped with both a secure identification source (Root of Trust), 11 for secure identification once put into circulation, and communication ports and modems to the northbound 12 and southbound 13 areas capable of implementing the main security standards and protocols available on the market. The Root of Trust 11 is configured to send a device certificate request and to receive a device certificate generation, as indicated in Figures 3 and 4 by the arrows. According to one embodiment, the Root of Trust 11 is represented by an HW key that can be imprinted on a TPM (Trusted Platform Module) type ASIC chip inserted during the manufacture of the dAlsy peripheral. In an alternative form of implementation, the Root of Trust 11 can be an FW or SW key that can be imprinted on an FPGA chip or SSD card, again generated by the external SENECA CMS service and loaded onto the dAlsy device in a secure manner and managed by the SENECA CMS server acting as the issuing security authority and key manager, equipped with PKI infrastructure and OT machine discovery according to OPC UA GDS specifications. The dAlsy peripheral is then equipped with two symmetrical computing areas in the OT and IT areas, 2 and 3, each comprising CPU or MCU, 27 and 28, each with its own Memory 14 and 15 and bus 16 and 17 assigned and physically segregated according to a “secure by design” approach. The OT and IT areas 2 and 3 also include Alarms servers 940 and Alarms clients 941 , and Logs clients 930 and Logs servers 931 , respectively.

[0109] According to one embodiment, the two computational subsystems composed of CPU, memory, and bus communicate with each other through two horizontal communication channels, namely an OT-IT channel 4 and an IT-OT channel 5, referred to as Northbound Datadiode and Southbound Datadiode, each unidirectional “by design” and each equipped with a secure execution environment (TEE) 18 that is also protected “by design” and in which TINYML code is expected to be executed for the detection of anomalies and discrepancies, which anomalies and discrepancies include cyber threats or malfunctions for at least one said device connected in the OT area. The secure execution environment (TEE) 18 also includes a code testing unit 180.

[0110] According to one form of implementation, the Northbound and Southbound Datadiods channels are designed to be unidirectional “by design” thanks to the conversion of electrical signals into optical signals and subsequent reconversion from optical to digital, with the support of dedicated HW and SW to maintain the signal carrier and any bidirectionality of the input protocol (e.g. TCP).

[0111] Figure 2 illustrates a diagram of the communication between the OT 30 domain and the IT 40 domain, implemented by means of two integrated proxies 51 , 56 and a unidirectional optical link 4. Proxies 51 and 56 terminate the bidirectional communication protocols towards the source (OT domain 30) and destination (IT domain 40) respectively, while the data diode 4 transfers data exclusively to the IT side 40, making a return flow physically impossible. In a preferred embodiment, the proxy 51 present in area 2 and facing the OT side 30 implements an OPC UA client 50 that queries the OPC UA servers residing on the devices connected to the OT side 30, collecting the data and routing it to a transmitter module 52 connected to an Ethernet port 53. The data thus prepared is transferred unidirectionally through the data diode 4, received by an Ethernet port 54 connected to a receiver module 55 facing the IT side 40, and forwarded to the proxy 56 that cooperates with an OPC UA server 57 in the IT area 3, making it available via the Ethernet port 12 to the application systems of the IT domain 40.

[0112] In this way, the OPC UA interface of the OT machines is transparently virtualized on the IT side, with physical segregation and unidirectionality guaranteed by the optical connection. Although described with reference to OPC UA, the system can be configured to support other industrial interoperability protocols, such as MQTT, Modbus, PROFINET, or similar client / server or publish / subscribe protocols.

[0113] Figure 3 illustrates an overview of the cloud-based system.

[0114] According to one implementation, the TINYML code is generated online by an LLM called SENECA LLM 8, specially optimized to generate selfconfiguring code, i.e., capable of discovering and configuring machinery in the OT area, self-diagnosing, i.e., capable of diagnosing discrepancies and anomalies in the operation and access traffic of OT devices, self- healing, i.e., capable of making software changes (SENECA PATCHES) 10 and, optionally, capable of self-testing autonomously on board the dAlsy peripheral before being executed and / or transmitted to OT machinery via preloaded self-testing procedures.

[0115] When in operation, the dAlsy unit is first configured to receive data from machinery and equipment in the OT area and transmit it securely to SENECA CMS (SENECA Cybersecurity Services) 6, including SENECA KEYS 60 and SENECA Certificates 61 , Devices Registry 62 and Services Registry 63, and SENECA AIMS (Al Services) 7, also including Alarms Registry 94, Logs Registry 93, and CODE Registry 96, without the possibility of contamination between the OT and IT areas.

[0116] Once the data flow reaches the CMS and AIMS services securely from authenticated and authorized dAlsy devices, external service providers (SENECA IT Service Providers) 19, once authenticated and authorized by the CMS service, can access the CMS and AIMS services to provide services based on SENECA's PKI infrastructure and LLM and send everything back to the authenticated dAlsy peripheral, allowing it to test and verify the code, execute it on its protected IT area or transfer it to the OT area and from there distribute it to the various OT machines, possibly through monitoring and authorization by OT users (SENECA OT Services Consumer) 20, who are also authenticated and authorized by the CMS service.

[0117] According to one implementation, the IT / OT transport and communication layer is implemented by installing an OPC UA server and client on board the IT and OT components of dAlsy. The OPC UA client in the OT part of the dAlsy 16 peripheral is able to collect data from the various machines discovered in the OT area and equipped with OPC UA servers connected in the OT area, and then pass this data to a mirror OPC UA server exposed in the IT area of the dAlsy 17 peripheral after transfer to the Northbound Datadiode channel. The OPUA server recreated in the IT area can then be queried by OPC UA clients operating in the IT area authenticated and authorized by the CMS service, starting with the one using SENECA AIMS services to monitor traffic and anomalies and use the Seneca LLM to create self-healing and self-testing patches.

[0118] Conversely, once the SENECA patches are ready, registered, and verified on the AIMS service, they can be executed on the cloud or, as an alternative, generated in TINYML format and sent back to dAlsy via an OPC UA server to which dAlsy connects from the IT area via the OPC UA client part installed, again using the same OPC UA channel to limit the exposure surface. Once on dAlsy, the TINYML code can be operated in the IT area or transferred in part to the OT area through the Southbound Datadiode unidirectional channel and tested with self-testing procedures that guarantee no attack in the return path before being approved and distributed to the OT network automatically or through approval by authenticated and approved SENECA OT Services Consumers.

[0119] According to an alternative implementation, the OT-IT communication described above is implemented based on the pub-sub alternative of OPC UA connection using the MQTT protocol with two brokers in the respective OT and IT areas of dAlsy, where communications take place by publishing data and subscribing to the communication channel, segregating the Northbound and Southbound sides, again with unidirectional channels.

[0120] The dAlsy monitoring unit is therefore responsible for executing artificial intelligence algorithms, including in TINYML mode with code autogenerated by generative agents at services operating in the IT area on the cloud and designed to generate and apply ML security patches in response to the detection of cyber threats or malfunctions recorded in the OT area and capable of self-verification through validation tests preloaded in dAlsy.

[0121] According to a specific executive form, the self-testing algorithm provides for routines preloaded on dAlsy and capable of dictating the compliance or non-compliance of the distributed algorithms, appropriately augmented with the relevant self-verifying testing procedures.

[0122] In an executive example, this self-testing functionality will be based on tests called “fuzzy testing.” These methods consist of entering random or “fuzzy” data into the system to observe how the model responds. If the model behaves abnormally or produces unexpected results, it could indicate that it has been compromised. In this way, fuzzy testing helps identify potential alterations or vulnerabilities in the model, ensuring the integrity and security of the ML code before it passes from the IT area of the dAlsy peripherals to the OT part in the reverse patching path. In another executive example, the reverse IT-OT path is subject to “Human in the Loop” workflow approval, whereby the actual availability of SW patches for malfunctions or cyber security attacks in the OT area are subject to approval and physical transport by a human operator on the OT devices involved through an approval and distribution workflow managed by a dedicated section of the AIMS service in the IT area.

[0123] The use of external authentication, authorization, and certification services allows for the unique identification of devices and makes it possible to identify and, if necessary, install and transfer device ownership in a secure and verifiable manner to the cloud.

[0124] Figure 4 illustrates a global diagram of a further alternative form of the system, according to which the identity, ownership, keys, and certificates managed by CMS services are implemented using DLT (Distributed Ledger Technology), SENECA DLT, 21 implemented according to a graph topology with digital identity keys (DID, Digital Identity Data) 22, non- fungible tokens (NFTs, Non-Fungible Tokens) 23 of ownership, and smart contracts 24 to implement in a decentralized manner the same functionalities provided for the SENECA CMS authority on the cloud.

[0125] According to a further form of execution, the SENECA LLM is implemented in a distributed manner, on the cloud or DLT, in which each dAlsy unit constitutes an autonomous computational node 26 capable of authenticating itself and being authorized to execute SENECA AIMS services in a distributed manner (swarm intelligence), possibly distributing the load required for the SENECA LLM and SENECA 3A AGENTS on individual edge devices.

[0126] The DLT architecture can, for example, be implemented as described in document WO2024 / 057259 of the same owner by assigning a DID identifier to each machine or to the dAlsy peripheral associated with it, allowing both the physical version of the machine and its digital twin to be uniquely identified and their ownership to be managed in combination with an NFT. This implementation also provides a robust system for identification and authentication, so that each machine is uniquely recognizable and its interactions are traceable and verifiable, improving security and reducing the risk of fraud or tampering. Furthermore, the use of DLT technology to manage these digital identities and NFT ownership certificates ensures that all transactions are recorded in a transparent and immutable manner, possibly through smart contracts.

[0127] According to one implementation, the digital twin of the machine is hosted on the dAlsy peripheral and uses the AAS (Asset Administration Shell) standard to expose the digital twin to the IT area to service providers and consumers authenticated and authorized by the SENECA CMS authority to access SENECAAIMS services.

[0128] According to another form of implementation, the DID key is stored in a RoT, possibly on HSM hardware in the dAlsy unit, and the public key is managed by the PKI system implemented on the SENECA CMS service in cloud or DLT option.

[0129] This authentication system ensures that only authorized devices, algorithms, service providers, and consumers can communicate and interact with the SENECA ecosystem, reducing the risk of unauthorized access. The private key protects the integrity of the data on the device, while the public key allows for the verification of transactions and communications.

[0130] According to one embodiment, a plurality of said monitoring and self- healing units are provided, and said management unit is configured to distribute the computational load among said plurality of monitoring and self-healing units.

[0131] The ability of the management unit to distribute the computational load among the monitoring and self-healing units offers significant advantages in terms of system scalability and resilience. This approach allows the workload to be distributed evenly, avoiding overloads and ensuring a rapid and efficient response to any anomalies or threats. In addition, the distribution of the computational load improves the robustness of the system, allowing for efficient resource management and increasing the system's ability to adapt to different operating conditions.

[0132] The SENECA system described above also involves an executive method that provides for the following operational flow.

[0133] The dAlsy 1 device is first released on the market with a hardware security module (HSM) that acts as a RoT (Root of Trust) 11 registered at the time of manufacture using a private key requested from the SENECA CMS 6 authority. Third-party users, referred to as SENECA Service Providers 19 and Service Consumers 20, can then be registered by the CMS service to access both dAlsy peripherals and Al services called SENECA AIMS 7, including SENECA LLM 8 and SENECA Algos 70, using double authentication keys managed by the PKI infrastructure of the SENECA CMS service. Once identified and registered, the AIMS service providers and consumers of the SENECA ecosystem can access data from specific dAISY peripherals with the highest level of security to monitor, diagnose, and treat the traffic patterns of the peripherals themselves or of the machines connected in critical OT areas, sending SENECA PATCH 10, a code also generated by the specific SENECA LLM 8 service, back to them. In particular, a SENECA Service Provider will be able to access the dAlsy peripherals assigned to it to receive data flows from OT machinery in a unidirectional manner thanks to the transfer mechanism implemented by the dAlsy peripheral. This mechanism will be based on a particular implementation form of the electrical-optical -electrical conversion of the TCP IP signal coming from the OT machinery by means of an OPC UA client or subscriber residing in the OT part of dAlsy capable of querying the server or publisher residing on one or more OT machines and by means of SW capable of maintaining the optical carrier and reconstructing the TCP-IP protocol once the data has been transferred to the IT part of dAlsy. Once reconstructed in the IT part, the data is exposed as an OPC UA server or publisher that the SENECA Server Provider can access through the SENECAAIMS service acting as a client or subscriber on the IT side.

[0134] Once on SENECA AIMS, the data representing communication flows and / or the operation of specific OT machines becomes processable by one or more algorithms provided by the SENECA IT Service Provider or made accessible to multiple Service Providers by the SENECA AIMS service, including SENECA LLM.

[0135] Once the data is available on SENECA AIMS, the Service is able to use advanced Artificial Intelligence techniques to diagnose alarms and events, which it then re-exposes using formalisms such as OPC Server or Publisher that can be queried by authenticated and authorized third parties, including dAlsy 1 peripherals that can return the data to the OT area with a unidirectional path implemented in reverse to that described above.

[0136] The SENECA LLM 8 available on the SENECAAIMS 7 service can in turn be used by Self-Caring Al Agents (SENECA 3A AGENTS) 9 with access to a series of tools and contexts included in SENECA Registries 90 and provided to the LLM to guide code generation, including a registry of the SW components of the monitored systems (SENECA SBOM 95, Software Bill of Materials), and a registry of patches published by individual SW providers (SENECA PATCH REGISTRY 10). Other data contained in SENECA Registries 90 include Assets 91 , Time Series 92, Logs 93, and Alarms & Events 94.

[0137] In a particular executive implementation, one or more SENECA 3A Agents are first able to discover and configure OT machines connected to one or more dAlsy and then able to process the traffic or operating data coming from them and self-configure so as to be self-healing and self-testing, i.e. , able to solve problems by operating on the cloud in the context of SENECA AIMS services offered to Service Consumers ers from the OT area and authorized and authenticated by the SENECA CMS service.

[0138] In a further implementation form, alarm and event flows and / or SENECA PATCHES are redistributed by SENECA 3A Agents to TEE protected areas in the dAlsy peripheral and, if necessary, from these to machines or controllers in the OT area with executable code also expressed in TINYML format and possibly configured to be self-tested once returned to the sentinel peripherals using verification tests natively included on dAlsy at the time of production and capable of self-testing using obfuscated code included in SENECA PATCHES, in order to validate them before they are redistributed in the OT area, making the cycle “secure by design” from the detection of anomalies in the OT area to their recovery through self-healing patches generated by Al services on the cloud and executable both on the cloud and edge on dAisy and very edge on critical machinery in the OT area.

[0139] Figure 5 shows a variant of the system in which the connection between the dAisy sentinel nodes is made using homomorphic encryption, with two objectives:

[0140] (i) to strengthen protection against external cyber attacks;

[0141] (ii) to enable the secure federation of dAisy devices in a distributed architecture.

[0142] The central node in the IT area, which maintains secure and segregated copies of the LLM models (as illustrated in the previous figures), is responsible for generating reduced SLM / TinyLM versions. These versions are pre-installed on each dAisy 1 device at the time of delivery, together with the private key 73 and the GDS server 74, which uniquely identify the device.

[0143] Once installed in the OT area and connected to the field devices 32, the dAisy sentinel devices locally execute the SLM / TinyLM model 75 in plain text. In the event of an update, the weights 79 are encrypted using homomorphic encryption by the dedicated module 76 and sent to the central server. The latter exposes an homomorphic aggregator 77 in the IT area capable of:

[0144] - receiving encrypted weights from the various sentinel nodes;

[0145] - performing operations compatible with the homomorphic process (e.g., sum, weighted average) without decrypting the data;

[0146] - return the updated weights 78, also encrypted, to the OT devices 32, which decrypt them locally to update their SLM.

[0147] In the case of implementations based on distributed sentinel nodes, as in the DLT version of SENECA AIMS 25, the computational load related to testing, verification, diagnosis, and encryption / decryption operations (e.g., for SLM / TinyLM models) can be distributed among the nodes using swarm intelligence techniques and coordinated via smart contracts for secure and automated management of interactions between devices.

Claims

CLAIMS1. System for ensuring the cybersecurity of devices connected to critical OT (Operational Technologies) infrastructures while such connected devices receive online IT (Information Technologies) services from a cloud system, characterized by the fact that it includes one or more sentinel edge devices capable of connecting to said IT services for Cybersecurity and Artificial Intelligence and capable of generating, distribute, and test software code and redistribute it in an intrinsically secure manner in said OT infrastructure on said sentinel edge devices and / or on said devices connected to said sentinel edge devices, making said connected devices more secure, self-repairing, and resilient in the event of cyberattacks and malfunctions, where each sentinel edge device comprises two symmetrical computational areas, one of which is an OT area connected to machinery operating in said OT infrastructure and one of which is an IT area connected to said IT services, which computational areas are connected to each other by two intrinsically unidirectional communication channels, respectively an OT-IT channel to said IT services and an IT-OT channel to said OT infrastructure, and wherein each sentinel edge device is configured to pass and test data from the IT area to the OT area on the sentinel edge device and vice versa in a natively secure manner.

2. System according to claim 1 , wherein the communication channels are configured to use a message-based point-to-point communication protocol, and each channel is secured by a whitelist mechanism configured to accept only messages digitally signed by an authorized IT service and to verify their authenticity and integrity in the OT domain prior to processing.

3. System according to claim 1 or 2, wherein the communication channels are configured to use a message-based point-to-point communication protocol based on messages, and the channel is secured to obtain data for performing automatic verification tests preloaded in the OT sentinel edge device and configured to validate that the code has not been modified or tampered with when crossing the IT area before reaching the OT sentinel edge device.

4. System according to claim 3, wherein said verification tests are performed in a secure TEE (Trusted Execution Environment) area of the OT sentinel edge device.

5. System according to one or more of the preceding claims, configured to use one or more LLM models on an IT cloud that can be used by Al agents capable of generating tiny machine learning (TINYML) software code.

6. System according to claim 5, wherein said LLM models are trained to automatically generate self-healing Al agents capable of autonomously discovering, configuring, monitoring, diagnosing, healing, and testing connected devices through the generation of software code, executable both in the cloud and on edge sentinel devices.

7. System according to claim 5 or 6, wherein the generated TINYML code is a Small Language Model (SLM), also known as a TINY Language Model (TLM), to be distributed on the sentinel edge devices.

8. System according to claim 5 or 6 or 7, wherein said LLMs are segregated in a non-IT accessible area and generate weights for the SLM / TLM version to be sent downstream securely from the IT accessible area to said sentinel edge devices, which weights are encrypted in transmission downstream to the sentinel edge devices, where said weights are decrypted and used to generate the SLM / TLM code. TLM version to be sent downstream securely from the IT accessible area to said sentinel edge devices, which weights are encrypted in transmission downstream to the sentinel edge devices, where said weights arereceived and decrypted by said sentinel edge devices and used to run the updated local SLM / TLM model in clear text.

9. System according to claim 8, wherein said weights are encrypted in transmission using homomorphic technology.

10. System according to one or more of the preceding claims, wherein each sentinel edge device can use the weights obtained downstream to operate its own SLM / TLM to learn new weights and send them back upstream after encrypting them with homomorphic technology to an aggregation system capable of combining all the weights received from these OT edge sentinel devices to aggregate the weights received and send them back to the edge sentinel devices without any knowledge of the data processed.11 . System according to one or more of the previous claims, in which the IT-OT and OT-IT unidirectional channels consist of a physical electronic-optical conversion module and a physical optical-electronic conversion module of the channel with software for disassembling and reconstructing the communication protocols provided in the electronic parts.

12. System according to claim 11 , wherein said communication channels are based on a protocol managed by software drivers operating in the OT and IT areas of each sentinel edge device, which software drivers are capable of managing the disassembly and reassembly of the communication protocol before and after passage through the optical channel in order to resubmit the data to authorized remote clients of said IT services as if such data were coming directly from the IT area and, vice versa, to resubmit alarms and / or events and / or software code to the said OT infrastructure as if such alarms and / or events and / or software code were coming from the OT area of the edge sentinel device without the possibility of reverse flows “by design.”13. System according to claim 12, wherein the OT-IT channel is configured to use client-server protocols and standards (e.g., OPC UAServer / client) and / or publish / subscribe protocols (e.g., MQTT, OPC UA PUB / SUB) through said conversion of the electronic signal to optical and from optical to electronic with supporting HW and SW to maintain the signal carrier and, in the case of a bidirectional communication protocol (e.g., TCP / IP) with the disassembly and reassembly of the protocol itself to emulate client-server or publish / subscribe operation, to ensure the intrinsic unidirectionality of the channel.

14. System according to one or more of the preceding claims, wherein said online IT (Information Technologies) services for cybersecurity and Artificial Intelligence use a dual-key security PKI infrastructure for the management of IT certificates and keys for the cybersecurity of software and equipment, including edge sentinel devices and a global discovery service for peripherals in both IT and OT areas, including edge sentinel devices (e.g. OPC UA GDS), said software codes, IT (Information Technologies) online service providers and consumers, and have at least one register of the SW components of the monitored systems and one register of the software code published by the providers of the individual SW used.

15. System according to claim 14, wherein each edge sentinel device comprises a secure HW identification source as the Root of Trust of the PKI infrastructure.

16. System according to one or more of the preceding claims, wherein the IT (Information Technologies) online services are managed on a distributed DLT (Distributed Ledger Technologies) and each edge sentinel device is connected to the DLT network from its IT area, using DID and NFT tokens respectively to identify the uniqueness and ownership of said edge sentinel devices or devices connected to them, managing transactions between said edge sentinel devices through smart contracts between machines.

17. System according to claim 16, wherein the calculations necessary for the homomorphic encryption and decryption of the weights of thenetworks used by the individual sentinel nodes connected in DLT mode are performed by the individual computing nodes represented by the edge sentinel devices (SWARM Intelligence).

Images