A method for monitoring an autonomously operated computer system running at least one software

A RUST-based monitoring module with an eBPF module in the kernel space of a GNU/Linux system addresses the challenge of detecting attacks in autonomously operated systems by continuously monitoring behaviors against a reference model, ensuring system safety and security without interruption.

WO2026104874A1PCT designated stage Publication Date: 2026-05-21FRAMATOME SA
View PDF 1 Cites 0 Cited by

Patent Information

Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
FRAMATOME SA
Filing Date
2024-11-13
Publication Date
2026-05-21

AI Technical Summary

Technical Problem

Existing intrusion detection systems (IDS) struggle to anticipate all suspicious data patterns and activity patterns in autonomously operated computer systems, such as those in industrial control systems of nuclear power plants, and face memory capacity constraints, making it difficult to detect potential attacks without compromising system safety or interrupting critical processes.

Method used

A monitoring method implemented by a monitoring module programmed in RUST and using an eBPF module in the kernel space of a GNU/Linux operating system, which observes and compares software behaviors against a reference model to detect deviations, generating alerts without interrupting the system, and employs mechanisms to limit resource impact.

Benefits of technology

Effectively detects potential attacks in autonomously operated systems by continuously monitoring behaviors, reducing resource impact, and ensuring the system remains operational, thus maintaining safety and security.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure IB2024061285_21052026_PF_FP_ABST
    Figure IB2024061285_21052026_PF_FP_ABST
Patent Text Reader

Abstract

The method implemented by a monitoring module (42) programmed in RUST programming language and collecting activity data via an eBPF module (44) installed in the kernel space (28) of a GNU / Linux operating system (26), the monitoring module (42) being configured to perform the steps of: - in a safe operational observing environment, observe behaviors of the at least one software (24) based on activity data collected via the eBPF module (44) and store reference behaviors into a reference behavioral model (52), then - in an autonomous operational monitored environment, monitor at least one behavior of the at least one software (24) based on activity data collected via the eBPF module (44), - if a deviation is detected between the monitored behavior and the expected reference behavior (56), keep the at least one software (24) running and generate and send an event message (58).
Need to check novelty before this filing date? Find Prior Art

Description

[0001] A method for monitoring an autonomously operated computer system running at least one software

[0002] The present invention relates to the technical field of security (or cybersecurity) for computer systems, such as those found in industrial plants, particularly in instrumentation and control (l&C) systems of nuclear power plants.

[0003] It is possible to detect a potential attack on a computer system using an Intrusion Detection System (IDS).

[0004] The IDS may be implemented as a Network Intrusion Detection System (NIDS), which is configured to monitor data traffic at one or more specific points on the network. Alternatively, the IDS may also be implemented as a Host Intrusion Detection System (HI DS), which is configured to run on a specific device on the network and monitors the activity occurring on that device.

[0005] Possible attacks can be detected by searching for specific data patterns or activity patterns corresponding to known potential attacks.

[0006] However, it is difficult to anticipate all suspicious data patterns and activity patterns that could indicate a potential attack on the computer system, and to update a library of suspicious data patterns and activity patterns.

[0007] This is particularly true for computer systems configured to operate autonomously, meaning they do not have the ability to receive updates via a network connection, such as those found in l&C systems of nuclear power plants.

[0008] Furthermore, such methods are generally generic and cannot be easily adapted to a specific computer system. Additionally, not all events can be reported due to memory capacity constraints.

[0009] It is also desirable to detect and report suspicious events without compromising the safety of the computer system, meaning without interrupting a critical process and / orwithout interrupting security monitoring, as this could lead to stopping the overall process implemented by the computer system.

[0010] One of the objectives of this invention is to propose a method for monitoring an autonomously operated computer system that preserves both its safety and security.

[0011] In this view, the invention proposes a method for monitoring an autonomously operated computer system running at least one software, the computer system operating on a GNU / Linux operating system, the monitoring method being implemented by a monitoring module programmed in RUST programming language and collecting activity data via an eBPF module installed in the kernel space of the GNU / Linux operating system, the monitoring module being configured to perform the steps of:

[0012] - in a safe operational observing environment:

[0013] - observing the behaviors of the at least one software running on the computer system to be monitored based on activity data collected via the eBPF module (44), and - store behaviors of the at least one software into a reference behavioral model as reference behaviors, then

[0014] - in an autonomous operational monitored environment:

[0015] - monitoring at least one behavior of the at least one software running on the monitored computer system based on activity data collected via the eBPF module, and - compare the at least one monitored behavior with the expected reference behavior stored in reference behavioral model to detect any deviation with the expected reference behavior;

[0016] - if a deviation is detected between the monitored behavior and the expected reference behavior,

[0017] - keeping the at least one software running and

[0018] - generating and sending an event message representative from the deviation to a supervisory entity.

[0019] In specific embodiments, the monitoring method comprises one or several of the following optional features, taken individually or in any technically feasible combination:

[0020] - there is a further step for optimizing the reference behavioral model using machine learning mechanism;

[0021] - the monitoring module comprises mechanisms for limiting the impact of the monitoring on the operational resources of the computer system;

[0022] - the mechanisms for limiting the impact of the monitoring on the operational resources of the computer system includes limited event count handling, limited and compressed event buffering, limited computation power and memory usage and / or the execution of the computation intensive tasks during low CPU activity phases;

[0023] - each reference behavior comprises for example process parameters including one or more of the following parameters: accesses with read / write or both to specific files, access to specific critical system calls, for example SUID / SGID usage, access to specific network capabilities, and / or system parameters including one or more of the following parameters: a specific process arborescence, specific modules (such as drivers) loaded in the computer system, specific peripheral plugged to the computer system, specific monitored files with various integrity information in the computer system; - the monitoring module is configured for continuously monitoring at least one parameter of each monitored behavior and / or for periodically monitoring at least one parameter of each monitored behavior;

[0024] - the at least one continuously monitored parameter comprise one of more of the following parameters: accesses with read / write or both to specific files, access to specific critical system calls, for example SUID / SGID usage, access to specific network capabilities, access to new process creation;

[0025] - the at least one periodically monitored parameter comprise one of more of the following parameters: a specific process arborescence, specific modules (drivers) loaded in the computer system, specific peripheral plugged to in the computer system, specific monitored files with various integrity information;

[0026] - the method additionally comprises monitoring the behavior of the at least one software on a rule-based approach with generating custom alerts if a combination of condition on a given event is met;

[0027] - the computer system is part of control system of an installation;

[0028] - the computer system is part of an information and control system of a nuclear power plant or an autonomous server of an IT system;

[0029] The invention also relates to a software comprising software instructions which may be stored in a non-volatile computer memory and executed by a processor and / or a virtual machine for implementing a monitoring method as defined above.

[0030] The invention also relates to an installation comprising sensors and / or actuators and a control system connected to the sensors and actuators, the control system comprising a computer system configured for running as least one software with implementing a monitoring method as defined above.

[0031] In specific embodiments, the installation is a nuclear power plant or an autonomous server of an IT system.

[0032] The invention and its advantages will be better understood upon reading the following description that is given solely by way of a non-limiting example and with reference to the appended drawings in which:

[0033] - Figure 1 is a schematic view of an installation comprising an autonomously operated computer system for controlling the installation;

[0034] - Figure 2 is a schematic view of a monitoring module of the monitoring system; - Figure 3 is a flow diagram illustrating a method of monitoring the autonomously operated computer system implemented by the monitoring system. The installation 10 illustrated on Figure 1 comprises a computer system 12 configured for at least partly controlling the installation 10.

[0035] The installation 10 is for example a nuclear power plant, the computer system 12 being an information and control (l&C) system of the nuclear power plant.

[0036] The installation 10 comprises equipment 14 which are connected to the computer system 12. The equipment 14 may comprise one or more sensors 16 that may send signals to the computer system 12 and / or one or more actuators 18 that may be controlled by the computer system 12, in particular as a function of signals provided by the one or more sensors 16.

[0037] The computer system 12 comprises a processor 20, a memory 22 and one or more software 24. Each software 24 is a computer application comprising software instructions stored in the memory 22 and executable by the processor 20 for operating the installation 10. In particular, each software 24 is for example configured for collecting signals from the one or more sensors 16 and / or emitting control signals to the one or more actuators 18.

[0038] The computer system 12 is operated on a GNU / Linux operating system 26. The memory space of the GNU / Linux operating system 26 contains various software and drivers disposing of either kernel land privileges, or “kernel space” 28, or user land privileges, or “user space” 30. The kernel space 28 is dedicated for running a privileged operating system kernel, kernel extensions and drivers. The user space 30 is used for running the software, here the one or more software 24.

[0039] Each software 24 can use various software drivers 32 in the kernel space 28.

[0040] The computer system 12 is configured to be operated autonomously. In the present context, “operated autonomously” means that the computer system 12 is configured to operate without receiving data or instructions from another computer system arranged inside or outside the installation 10.

[0041] In particular, the computer system 12 is preferably not connected to computer network outside the installation 10 such as to receive signals and / or messages from outside the installation 10.

[0042] Optionally, the computer system 12 is connected to a control interface 34 allowing one or more operators to interact with the computer system 12, in particular for the control of the installation 10.

[0043] The control interface 34 is for example configured for collecting data from the computer system 12 and / or for providing instructions to the computer system 12. The control interface 34 is part of the installation 10. Optionally the computer system 12 is configured for sending signals and / or messages related to the security of the computer system 12 to a supervisory entity 36. The supervising entity is part of the installation 10 or separate from the installation 10.

[0044] The supervisory entity 36 is for example security operation center (SOC) which may comprise a security information and event management system 38 (SIEM).

[0045] The computer system 12 comprises a monitoring system 40 configured for monitoring the computer system 12, in particular for monitoring the activity of the computer system 12 when running the one or more software 24.

[0046] The monitoring system 40 is executed on the computer system 12.

[0047] The monitoring system 40 comprises a monitoring module 42 installed in the user space 30 of the operating system 26 and configured for collecting activity data via an eBPF module 44 installed in the kernel space 28 of the operating system 26.

[0048] The monitoring module 42 is programmed in RUST programming language. The RUST programming language allows for improved reliability of the monitoring module 42 thus ensuring a reliability of the monitoring system 40 with a limited risk of interrupting the process of the monitoring module 42 and thus the operation of the computer system 12.

[0049] The eBPF module 44 is based on the Extended Berkeley Packet Filter (eBPF) technology and is also programmed in RUST. This technology is available on GNU / Linux operating systems since the release of Linux 4.4 and allows performing safely operations from the kernel space, opposed to a regular driver which can introduce system stability issues. The eBPF module 44 runs within the kernel space 28.

[0050] The eBPF module 44 is configured to detect (or intercept) activities related to each monitored software 24 in the kernel space 28 and to transmit a corresponding activity data to the monitoring module 42. The eBPF module 44 operates as an activity probe for the monitoring module 42, with reporting any activity generated by the at least one software 24 in the kernel space 28.

[0051] The eBPF module 44 is preferably configured to intercept system calls, in particular specific key system calls, which are selected to offer a good coverage for the activity monitoring of the at least one software 24.

[0052] The EBPF module 44 is also advantageously configured to intercept incoming network packets which may or may not be intended for the at least one software 24 through the eBPF express Data Path (XDP) mechanism.

[0053] The eBPF module 44 can be configured to intercept system calls with no need to modify the kernel code or to add a module in the kernel space 28 or to add a driver for operating the monitoring module 42. The data collected by the monitoring module 42 via the eBPF module 44 includes for example activity such as file opening, network socket opening, new software execution, usage of specific privileges (SIIID or SGID), file descriptor manipulations, inter-process signals. Data can also be collected from the XDP mechanism, which generates events for each incoming network packet received by the computer system 12.

[0054] Optionally, the computer system comprises a monitoring client module 46 installed in the user space 30. The monitoring client module 46 defines a user interface allowing an operator to administrate the monitoring system 40, in particular the monitoring module 42.

[0055] The monitoring client module 46 is accessible only locally on the computer system 12 for security reasons. For example, monitoring client module 46 can be launched through an administrative access performed via the control interface 34.

[0056] Optionally, the monitoring system 40 is installed with a monitoring installation driver 48 installed in the kernel space 28 and configured for installing and protecting the monitoring system 40 in the operating system 26, in particular for installing the monitoring module 42, and the eBPF module 44.

[0057] As illustrated on Figure 2, the monitoring module 42 comprises a behavior module 50, which contains a reference behavior model 52 and an analysis module 54.

[0058] The reference behavior model 52 contains at least one reference behavior 56 of the at least one software 24 of the monitored computer system 12.

[0059] In operation, the behavior of software 24 may include actions such as initiating a process, reading a memory, writing a memory, inter-process internal signal transmission, interaction with equipment.

[0060] Each reference behavior 56 may include: a process, having accesses with read / write or both to specific files, having access to certain critical system calls (for example SUID / SGID usage), having access to some network capabilities, having access to new process creation. Or the system on overall, having a specific process arborescence, having certain modules (drivers) loaded, having certain peripheral plugged to it, having specific file with various integrity information.

[0061] The behavior module 50 is configured to monitor at least one behavior of the at least one software 24 during operation of the monitored computer system 12.

[0062] The behavior module 50 is preferably configured for continuously monitoring one or more parameters of each monitored behavior and / or periodically monitoring one or more parameters each monitored behavior.

[0063] In the present context, continuously monitoring a parameter refers to monitoring the parameter each time the parameter is affected by the monitored behavior. In the present context, periodically monitoring a parameter refers to monitoring the parameter at fixed or variable intervals, which may by intervals of time or a number of times the parameter is affected by the monitored.

[0064] The behavior module 50 comprises for example an analysis module 54, which itself comprises for example a continuous analysis submodule 54A and a periodic analysis submodule 54B and optionally an analysis submodule 54C which does conventional rulebased detection to take profit of the event ingestion to facilitate and complement the supervision of the system 12.

[0065] Continuously monitored parameters may include for example file opening, network socket opening, new software execution, usage of specific privileges (SIIID or SGID), file descriptor manipulations, inter-process signals and / or incoming network packet.

[0066] Periodically monitored parameters may include for example file integrity checks, overall process tree (software creation arborescence), system CPU load and memory usage, loaded drivers and / or external peripherals.

[0067] Conventional rule-base detection may include rules which allow to perform detection on event content based on some combinations of conditions described in a rule description language.

[0068] The analysis module 54 is configured for, in a safe operational observing environment, observing the behaviors of the at least one software 24 running on the computer system 12 to be monitored, and store the observed behaviors of the at least one software into the reference behavioral model 52.

[0069] In the present context, a “safe operational observing environment” refers to an operation of the computer system 12 in a controlled environment with ensuring that the security of the computer system 12 is not jeopardized. This is for example implemented by running the computer system 12 in an initial phase, preferably after a security check and without communication of the computer system 12 with any other system.

[0070] A reference (predefined) model for well-known GNU / Linux software, meaning not specific to the application of the system 12, may be included in the monitoring module 42 to optimize the time required by this behavioral model creation step.

[0071] Hence, the analysis module 54 is configured for automatically determining each reference behavior 56 of the reference behavioral model 52 during a nominal usage of the system 12.

[0072] The analysis module 54 is configured for, in an autonomous operational monitored environment, monitoring at least one behavior of the at least one piece of software 24 running on the monitored computer system 12, and compare the at least one monitored behavior with the expected reference behavior 56 stored in the reference behavioral model 52 to detect any deviation with the expected reference behavior 56.

[0073] In the present context, an “autonomous operational monitored environment” refers to the operation of the monitored computer system 12 under monitoring of the monitoring system 40.

[0074] The analysis module 54 is configured for, if a deviation is detected between the monitored behavior and the expected reference behavior 56, keeping the corresponding software 24 running and generating an event message 58 representative from the deviation and sending the message to the supervisory entity 36.

[0075] Preferably, the analysis module 54 is configured for optimizing the reference behavioral model 52 using machine learning.

[0076] In this view, the behavioral model size is reduced using various machine learning algorithms adapted to the data structures, for example pondered graphs with cutting thresholds for path-like data or data clustering for network flows representation, contained in reference behavior 56 to transform a discrete list of specific behaviors to a more englobing list of less-specific behaviors. Preferably, no neural networks are used, as a deterministic and computing-power efficient approach is preferred.

[0077] Advantageously, the monitoring module 42 comprises mechanisms for limiting the impact of the monitoring on the computer system operational resources (or “impact limitation mechanisms”).

[0078] The impact limitation mechanisms include for example a fixed-size ring buffer 60 for storing incoming events intercepted by the eBPF module 44. Events may be lost, but system integrity must be prioritized to monitoring exhaustivity. This prevents the memory allocated to the monitoring module 42 from increasing too much).

[0079] The impact limitation mechanisms include for example a spamming process detection 62 which disables the monitoring for a given process which generated an abnormal volume of events (while generating an alert regarding the detected spamming activity).

[0080] The impact limitation mechanisms include for example a smoothed workload treatment 64 configured to regularly analyze events count is regularly analyzed, wherein an increase in the number of events per second provokes a gradual increase in the speed of the event processing and a decrease in the number of events per second provokes a gradual diminution in the speed of the event processing.

[0081] The impact limitation mechanisms include for example a CPU load spike detection 66, and computing-power heavy periodic checks are done when the current CPU load is inferior to configurable thresholds. Additionally, the data transfer to the external supervisory entity 36 may buffered in a compressed and size-limited buffer 68 to prevent losing events in case of a network disruption, while also preventing dramatic memory increase of the memory spaced allocated to the monitoring module 42 if the network disruption lasts for too long.

[0082] A monitoring method implemented by the monitoring system 40, in particular by the monitoring module 42, during operation of the computer system 12, will now be described with reference to Figure 3.

[0083] In a first phase implemented in a safe operational observing environment, the monitoring module 42 implements a first step E1 observes the behaviors of the at least one software 24 running on the computer system 12 to be monitored, and a second step E2 of storing the behaviors of the at least one software 24 into a reference behavioral model (52) as reference behaviors 56. Finally, the model is reduced using various machine learning algorithms during the third step E3.

[0084] Then, in a second phase implemented in an autonomous operational monitored environment, the monitoring module 42 implements a fourth step E4 of monitoring at least one behavior of the at least one software 24 running on the monitored computer system 12 and fifth step E5 of comparing the at least one monitored behavior with the expected reference behavior 56 stored in reference behavioral model 52 to detect any deviation with the expected reference behaviors 56.

[0085] If a deviation is detected between the monitored behavior and the expected reference behavior 56, the monitoring module 42 performs a sixth step E6 of keeping the at least one software 24 running and a seventh step E7 of generating an event message 58 representative from the deviation to a supervisory entity 36.

[0086] During implementation of the monitoring step E4, the monitoring module 42 performs for example continuous monitoring of at least one parameter of each monitored behavior and / or periodical monitoring at least one parameter of each monitored behavior.

[0087] The proposed monitoring method can be implemented locally on a computer system 12 operated autonomously with no need to update a library of suspicious data patterns or activity patterns.

[0088] The proposed monitoring method is based on the activity of the computer system 12 itself and in particular on the behavior of software 24 of the computer system 12. It is not based on the behavior of users of the computer system.

[0089] The monitoring method is based on a reference behavior model that can be at least partly generated automatically by the monitoring system during an observation step implemented in a safe operational observing environment. The reference behavior model can thus be used for comparison with the actual behavior of the software 26 during autonomous monitored operational environment to detect deviations and emit event messages.

[0090] Each event message is emitted by the monitoring module 40 to the supervisory entity 36 with keeping the at least one software 26 running, such that the computer system 12 keeps running for preserving safety of the installation.

[0091] Each event message is a “silent alert”, meaning that it does not affect the computer system 12 and the installation 10 that needs to keep running (in particular in the case of an l&C system of a nuclear power plant), but launches an alert to the supervisory entity 36 that can check the potential issue / attack on the computer system 12 within pre- established processes that do not jeopardize the safety of the nuclear power plant.

Claims

CLAIMS1.- A method for monitoring an autonomously operated computer system (12) running at least one software (24), the computer system (12) operating on a GNU / Linux operating system (26), the monitoring method being implemented by a monitoring module (42) programmed in RUST programming language and collecting activity data via an eBPF module (44) installed in the kernel space (28) of the GNU / Linux operating system (26), the monitoring module (42) being configured to perform the steps of:- in a safe operational observing environment:- observing the behaviors of the at least one software (24) running on the computer system (12) to be monitored based on activity data collected via the eBPF module (44), and- store behaviors of the at least one software (24) into a reference behavioral model (52) as reference behaviors (56), then- in an autonomous operational monitored environment:- monitoring at least one behavior of the at least one software (24) running on the monitored computer system (12) based on activity data collected via the eBPF module (44), and- compare the at least one monitored behavior with the expected reference behavior (56) stored in reference behavioral model (52) to detect any deviation with the expected reference behavior (56);- if a deviation is detected between the monitored behavior and the expected reference behavior (56),- keeping the at least one software (24) running and- generating and sending an event message (58) representative from the deviation to a supervisory entity (36).2.- Monitoring method as in claim 1, wherein there is a further step for optimizing the reference behavioral model (52) using machine learning mechanism.3.- Monitoring method as in claim 1 or 2, wherein the monitoring module (42) comprises mechanisms for limiting the impact of the monitoring on the operational resources of the computer system (12).4.- Monitoring method as in claim 3, wherein the mechanisms for limiting the impact of the monitoring on the operational resources of the computer system (12) includes limited event count handling, limited and compressed event buffering, limited computation power and memory usage and / or the execution of the computation intensive tasks during low CPU activity phases.5.- Monitoring method as in any one of the preceding claims, wherein each reference behavior comprises for example process parameters including one or more of the following parameters: accesses with read / write or both to specific files, access to specific critical system calls, for example SUID / SGID usage, access to specific network capabilities, and / or system parameters including one or more of the following parameters: a specific process arborescence, specific modules (such as drivers) loaded in the computer system, specific peripheral plugged to the computer system, specific monitored files with various integrity information in the computer system.6.- Monitoring method as in any one of the preceding claims, wherein the monitoring module (42) is configured for continuously monitoring at least one parameter of each monitored behavior and / or for periodically monitoring at least one parameter of each monitored behavior.7.- Monitoring method as in claim 6, wherein the at least one continuously monitored parameter comprise one of more of the following parameters: accesses with read / write or both to specific files, access to specific critical system calls, for example SUID / SGID usage, access to specific network capabilities, access to new process creation.8.- Monitoring method as in claim 6 or 7, wherein the at least one periodically monitored parameter comprise one of more of the following parameters: a specific process arborescence, specific modules (drivers) loaded in the computer system, specific peripheral plugged to in the computer system, specific monitored files with various integrity information.9.- Monitoring method as in any one of the proceeding claims, additionally comprising monitoring the behavior of the at least one software (24) on a rule-based approach with generating custom alerts if a combination of condition on a given event is met.10.- Monitoring method as in any one of the preceding claims, wherein the computer system is part of control system of an installation.11.- Monitoring method as in any one of the preceding claims, wherein the computer system is part of an information and control system of a nuclear power plant or an autonomous server of an IT system.12.- Software comprising software instructions which may be stored in a non-volatile computer memory and executed by a processor and / or a virtual machine for implementing a monitoring method as any one of the preceding claims.13.- Installation comprising sensors and / or actuators and a control system connected to the sensors and actuators, the control system comprising a computer system configured for running as least one software with implementing a monitoring method as in any one of claims 1 to 11.14.- Installation as in claim 13, wherein the installation is a nuclear power plant15.- Installation as in claim 13, wherein the installation is an autonomous server of an IT system.