RU2637435C1 - Method for detecting anomaly of execution system of programmable logic controller - Google Patents

Abstract

FIELD: physics.

SUBSTANCE: method is carried out through the detection of the interaction mismatch by the security module, monitoring of which is set, to the rule for this interaction, while monitoring of the interaction is carried out by separating the execution systems of the programmable logic controllers to modules and modifications of the data exchange interface of the modules among themselves and to the resources of the operating system in such a way as to steer through the security module, which monitors the interaction and discovers the anomalies.

EFFECT: providing the anomaly detection performed by the execution system of the programmable logic controllers.

14 cl, 13 dwg

Description

Technical field

The invention relates to methods for detecting anomalies in the operation of programmable logic controllers and related peripheral devices for monitoring and controlling machines and production processes.

State of the art

Attacks on automated control systems (abbr. ACS) have long been not uncommon. Almost all ACS elements are attacked, and programmable logic controllers are not an exception (GOST R IEC 61131-1-2016. The national standard of the Russian Federation. Programmable controllers. Part 1. General information (approved and put into effect by the Order of Rosstandart from 05.13.2016 N314-st)) (abbr. PLC, English PLC). PLCs contain many vulnerabilities (http://www.alphaguardian.net/category/plc-cyber-vulnerabilities/) that can be used to attack ICS. One of these vulnerabilities is the use of PLC execution systems (e.g. CodeSYS RTE), which are a monolithic or multicomponent program that runs in the same virtual address space on the operating system that the PLC runs under. Thus, if at least one functional component is compromised (GOST R IEC 61131-1-2016. - P. 2), supported by the PLC execution system, for example, interacting with input devices, the entire PLC execution system will be compromised.

The technical problem is the inability to detect an anomaly inside the PLC execution system due to its monolithicity.

In the prior art there are no solutions that can solve this problem radically. Various vulnerability scanners and filters are used. An example of such a solution is given in the article "Protecting Industrial Control Systems with Cisco IPS Industrial Signatures" (http://www.cisco.com/c/en/us/about/security-center/protecting-industrial-control-systems-networks- ips.html) Ho, if the filter missed some interaction and passed it to the PLC execution system, then it becomes almost impossible to identify the anomaly due to the closedness of the execution system itself; in fact, for security systems, the PLC execution system is a "black box".

Two pole options for solving this problem are currently possible, in the first case, the PLC design is developed in such a way as to fulfill a strictly deterministic task, which in principle eliminates any flexibility (the ability to switch from one type of product to another with minimal time and labor) ) and in the use of execution systems in their classical sense, there is no need. Either PLCs are used together with execution systems, which gives PLCs maximum flexibility, but the issue of information security is completely ignored, although very close attention is paid to the implementation of functional safety requirements due to their regulatory regulation ( IEC 61508 - Functional safety of electrical, electronic, programmable electronic safety related systems).

Disclosure of invention

The present invention is intended to detect anomalies in the execution of a PLC execution system on a programmable logic controller.

The technical result of the present invention is to provide anomaly detection in the execution of a PLC execution system on a programmable logic controller. The technical result is achieved by detecting by the security module the interaction mismatch being monitored for the rule established for this interaction, while monitoring the interaction is carried out by dividing the PLC execution system into modules and modifying the module data exchange interface with each other and with the operating system resources so that direct interaction through a security module that monitors the interaction and detection of anomalies .

A method for controlling the execution of a PLC execution system, in which the code and data of the PLC execution system or its parts are divided into separate software modules, while the software modules are divided based on:

- the functional structure of the PLC execution system, where a functionally complete fragment of code and data of the PLC execution system is allocated to at least one module, the rest of the code and data of the PLC execution system is allocated to another module; or

- security threats for the PLC execution system, where a fragment of code and data of the execution system containing the vulnerability used to implement threats is allocated to at least one module, the rest of the code and data of the execution system is allocated to another module; or

- the criticality of the code and data of the execution system, where a fragment of code and data of the PLC execution system that controls the critical object is allocated to at least one module, the rest of the code and data of the PLC execution system is allocated to another module.

Install a security module on the PLC and modify the module data exchange interface, designed for the modules to interact with each other and with the resources of the operating system so that the specified interaction is carried out only through the installed security module, and the format of the data exchanged corresponds to the format defined by the security module. Next, they monitor the interaction of the modules of the PLC execution system with each other and with the resources of the operating system by checking the security module for at least one interaction for compliance with the rules established for this interaction. In the process, anomalies are detected in the execution of the PLC execution system based on the interaction mismatch detected by the security module, the monitoring of which is carried out, the rule established for this interaction. Modules can be executed in separate processes.

In the particular case, at least one received module is further isolated from other modules and from the resources of the operating system in which the PLC execution system is executed, excluding the possibility of direct data exchange with other modules and with PLC OS resources. In one case, the module is isolated by containerization, and the security module is installed on the operating system under the control of which the PLC execution system is executed. For isolation, it is possible to use Linux containerization technology.

In a particular case, the security module is executed under the control of the operating system, under the control of which the PLC execution system is executed.

In another particular case, the modules are isolated by virtualization, and the security module is installed on the hypervisor. In a particular case, PikeOS technology is used for virtualization.

When modifying the data exchange interface, the order and protocol of data exchange are changed. At the same time, the data exchange interface is modified for this exchange through the security module, not for any interaction between the modules and the OS, but only for critical, where the criticality is determined on the basis of existing and potential threats to the PLC execution system. In a particular case, the security module monitors based on the rules, the format of which coincides with the data format that the modules exchange with themselves and the operating system, and the interaction is checked by the security module for compliance with at least one rule.

Brief Description of the Drawings

Additional objectives, features and advantages of the present invention will be apparent from reading the following description of an embodiment of the invention with reference to the accompanying drawings, in which:

FIG. 1 shows examples of PLC execution systems and programming and debugging systems;

FIG. 2 depicts an embodiment of the present invention;

FIG. 3 depicts options for dividing a PLC execution system into modules;

FIG. 4 shows insulation options for the modules of the PLC execution system;

FIG. 5 depicts installation options for a security module on a PLC;

FIG. 6 depicts an example of a general purpose computer system with which the present invention can be implemented.

The implementation of the invention

The objects and features of the present invention, methods for achieving these objects and features will become apparent by reference to exemplary embodiments. However, the present invention is not limited to the exemplary embodiments disclosed below, it can be embodied in various forms. The above description is intended to help a person skilled in the art for a comprehensive understanding of the invention, which is defined only in the scope of the attached claims.

A programmable logic controller is an electronic component of an industrial controller, a specialized (computerized) device used to automate technological processes. Execution system (English execution runtime, runtime environment) - software and / or hardware environment necessary for the execution of a computer program and available during the execution of a computer program. Also known as a runtime system, runtime environment, runtime environment, executive system.

The execution system of a programmable logic controller (Petrov IV "Programmable controllers. Standard languages and techniques of applied design" - M .: Solon-Press, 2010 - P. 48) (English control runtime system) - software environment installed on the PLC necessary for executing the control (application) program and available during execution of the control program. Provides loading, execution of the PLC application and debugging functions. It is installed in the controller during its manufacturing. It is a monolithic program (single-component) or a software package (consists of several components). In the case of a monolithic program, all functionally complete fragments of code (hereinafter, code refers to program code in its various forms: object code, code byte (intermediate code), executable code, machine code) and program data responsible for network exchange, access to output input devices and other functions are located within one component, in another case they are distributed among several components (e.g. libraries). Examples of these systems: MasterPLC executive system (http://www.insat.ru/products/?category=395), CodeSys Runtime execution system (https://www.codesys.com/products/codesys-runtime.html). In FIG. 1 shows a variant of organization of a PLC execution system. Functionally completed pieces of code and data that implement the functions of network exchange, access to input / output devices, and other functions located within the framework of one program will be further denoted abstractly Functions A, Functions B, Functions C, where, for example, “Function A” is understood as functionally complete code and data fragments responsible for the implementation of “Function A”. A functional component should be distinguished from a software component. The functional component is an element of the functional structure, and the software component is an element of the software complex.

A component of the execution system is a set of functionally complete fragments of code and data combined into a program (application, library), a function, a functional block from which the execution system is hierarchically built. The components interact with each other through an interface. In the framework of this application, the execution system module is a special case of a component that is executed separately from other components of the PLC execution system (eg, in a different address space).

The set of interconnected components (modules), from which the execution system is hierarchically built, implements the functional structure ("GOST R IEC 61131-1-2016. The national standard of the Russian Federation. Programmable controllers. Part 1. General information" (approved and put into effect by the Order Rosstandart dated 05.13.2016 N 314-st), - S. 3) (functions performed by the execution system). The order and format of interaction of interconnected components are determined by functional logic. In the particular case, the implemented functional structure and functional logic (a way of interacting with the elements of the functional structure) are business logic implemented in the runtime code. The method of interaction in a particular case determines the order and format of interaction of elements.

The business logic of the runtime system - implemented in the code of classes, methods, procedures, functions of the runtime environment, is a set of rules, principles, dependencies of the behavior of objects in the subject area. An element of the business logic of the runtime is a functionally complete set of instructions, classes, methods, procedures, functions. The combination of elements form the functional structure of the execution system or its part.

The business logic of the PLC execution system is implemented in the code of classes, methods, procedures, functions of the runtime environment, a set of rules, principles, dependencies of the behavior of objects in an automated technological process. For example, the order of network exchange, access to input / output devices, interaction with the PLC OS.

System for programming and debugging programs ("GOST R IEC 61131-1-2016. National standard of the Russian Federation. Programmable controllers. Part 1. General information" (approved and put into effect by the Order of Rosstandart dated 13.05.2016 N 314-st), - P. 2) (abbr. SP&O) is associated with the PLC execution system. It is through this system that the application program is loaded into the PLC memory and transferred to the control of the PLC execution system. An example of a DSS is depicted in FIG. 1. In the particular case, this system can be used to control the PLC execution system, change its configuration and install additional modules on the PLC.

As noted in the “Prior art” section, PLC execution systems have security problems because the PLC execution system is a monolithic program or consists of components that are executed in one process. The present invention allows to divide the execution system into modules, which will allow you to control the interaction of any elements of the functional structure of the PLC execution system or any fragments of the execution system code with each other and with the resources of the operating system. The present invention, when used with other execution systems, monolithic programs, or multicomponent programs running in one process, also allows:

increase the security of computer systems on which the listed objects operate (are executed); and

provide control over the interaction of elements of these objects.

This invention is applicable not only to entire programs or systems, but also to any monolithic parts and components of programs and software systems, the execution of which must be controlled, as well as to increase the security of computer systems on which said parts or components are executed. Therefore, it should be noted that everything indicated for the PLC execution system is equally true, unless explicitly stated otherwise or otherwise follows from the essence of the PLC execution system arising from the features of the PLC for:

- other execution systems, their parts and individual components (modules);

- monolithic programs and their parts;

- multicomponent programs executing in one address space and separate components (modules) of these programs.

An embodiment of the present invention is depicted in FIG. 2. At the first stage 200 of the implementation of the method, a PLC execution system is obtained. The PLC execution system is either removed from the PLC or the PLC execution system is obtained before being installed on the PLC. In another particular case, the method is implemented from the first stage directly on the PLC.

Next, at step 210, the code and data of the PLC execution system are divided into separate modules; the code and data are divided based on the functional structure (GOST IEC 61131-1) of the PLC execution system. With this separation, a functionally complete fragment of code and data of the PLC execution system is allocated to at least one module, the rest of the code and data of the PLC execution system is allocated to another module. In FIG. 3a, an example of such a separation is shown, where a code and data fragment intended to perform “functions A” is allocated to “module 1”, a code and data fragment intended to perform “functions A” is allocated to “module 2”, a code fragment and data intended to perform the “other functions” remaining is highlighted in “module 3”.

Also, the code and data of the PLC system are divided based on security threats (GOST R 56546-2015) for the PLC execution system. With this separation, a fragment of code and data of the execution system containing a vulnerability (GOST R 56546-2015) (or a vulnerable fragment of code, for example, a fragment responsible for network interaction) is isolated into at least one module, and it is he who, as a rule, is attacked in first of all), used to implement threats, the rest of the code and data of the execution system is allocated to another module. In FIG. 3b shows such a separation, for example, fragments of code and data intended to perform functions A, B, C, contain vulnerabilities, a fragment of code and data intended to perform "functions A" is highlighted in "module 1", fragments of code and data intended to perform “functions B” and “functions C”, are allocated to “module 2”, fragments of code and data intended to perform “other functions” remaining and not containing vulnerabilities are allocated to “module 3”.

Separation can also be carried out on the basis of the criticality of code fragments and data of the execution system, where a fragment of code and data of the PLC execution system is allocated into at least one module, which controls a critical object (GOST R 53114-2008. National Standard of the Russian Federation. Information Protection. Securing information security in the organization. Basic terms and definitions "(approved and enforced by the Order of the Russian Technical Regulation of 12/18/2008 N 532-st), p. 6) (a critical fragment of code and data), the rest of the code and system data PLC executions are allocated to another module, Fig. 3c shows an example of such separation, where a code and data fragment intended to perform “functions A” is critical code and contains critical data, this fragment is allocated to module 1, code and data fragments, designed to perform “functions B”, “functions C”, “other functions” remaining, are allocated to “module 2”.

These criteria for separation can be used both separately and jointly, in the example depicted in FIG. 3b, the separation is used not only by the presence of vulnerabilities, but also based on the functional structure of the PLC execution system, and in the example depicted in FIG. 3c, separation is used not only for the criticality of the code / data, but also based on the functional structure of the PLC execution system.

In FIG. 3b and FIG. Figure 3c shows examples where functionally complete code and data fragments are allocated to modules that contain vulnerabilities or are used to manage critical objects; in general, when separating based on criticality and security threats, functionally complete fragments are not required to be allocated to the module, any critical fragments can be highlighted, or fragments containing vulnerabilities, examples are presented for ease of perception.

When extracting code fragments into modules, a way of interaction (data exchange order and data format) between the modules is organized, which is equivalent to the way these fragments interact in the PLC execution system before separation. In other words, which code fragment interacted with which fragment in which order, the modules containing the indicated code fragments will interact in this order, after the PLC execution system is divided.

At step 220, previously created modules are isolated from each other, from the operating system and equipment. For isolation, virtualization technologies using containers or virtual machines are used (GOST R 56938-2016 Information protection. Information protection when using virtualization technologies. General provisions). When using containers (see Fig. 4a), the module is placed in a container, and a control service is installed into the operating system, through which the modules interact with each other and with the operating system, examples of such services are the Docker services. When using virtual machines, the modules are placed in virtual machines with different types of virtual machine monitors, which are:

- Type I hypervisors (see Fig. 4b), for example VMware ESX;

- Type II hypervisors (see Fig. 4c), Microsoft Virtual PC, VM Workstation, QEMU, Parallels, VirtualBox;

- hybrid hypervisors (see Fig. 4d), Xen, Citrix XenServer, Microsoft Hyper-V.

Separately, it is worth noting that for isolation in a particular case, the following can be used: partition (English partition) PikeOS (PikeOS is a real-time microkernel operating system manufactured by SYSGO AG). It focuses on the security of critical embedded systems. It provides a shared environment for several operating systems with different design goals and security requirements (of the site https://www.sysgo.com/products/pikeos-hypervisor/)) Linux containerization (Linux Containers, abbreviated LXC) . In the particular case, not all modules can be isolated, and their interaction with the operating system and other modules remains unchanged, this fact is shown on the example of module N in the figures, for which isolation is optional.

At step 230, a security module is installed on the PLC; in the particular case, the module contains functionally complete sets of code and data fragments responsible for implementing security functions (how these functions will be described below). The PLC architecture level at which the safety module will operate will be determined by the technology that was used to isolate the modules of the PLC execution system. For example, if containers were used for isolation (Fig. 4a) and a control service was installed in the PLC OS (eg, Docker), then the security module is located at the same level as the containers (see Fig. 5a). If virtual machines are used for isolation (see Fig. 4b, Fig. 4c, Fig. 4d), then the security module is installed at or integrated into the virtual machine monitor (hypervisor) (see Fig. 5b, Fig. 5c). At the same stage, the data exchange interface of isolated modules is modified, designed to interact with other modules and with the operating system resources in isolation conditions so that the specified interaction in isolation conditions of the modules is carried out only through the installed security module, and the format of the data exchanged matches format defined by the security module.

As a result, the security module is able to perform security functions, namely, to monitor the execution of the execution system, which involves: monitoring the interaction of isolated modules with each other, with the resources of the PLC operating system or equipment; adjustment of the specified interaction, stopping the interaction. The security module monitors based on the rules, the format of which coincides with the data format which the modules exchange with themselves and with the operating system. The interaction is checked by the security module for compliance with the logical rule that is stored in the security module, the rule contains a description of the valid interaction.

The security module monitors the interaction, where the interaction is checked for compliance with the rule, if the interaction matches the rule, then the interaction is skipped and data is sent to the receiver, if the interaction does not match the rule, the interaction is adjusted (changes are made to the data exchanged between the receiver and the source through the security module) or interaction is not allowed (interaction stops). What a security module should do if the interaction does not match the rule that describes such interaction is determined either by the rule itself or by a subsidiary rule if the module does not have a rule for the interaction (dispositive regulation). For example, the permissible interaction (see Fig. 5b) of “module 1” with “module 2”, where “module 1” is the source and “module 2” is the receiver, is described by the basic “rule A” and optional “rule B”, also the security module contains a subsidiary “rule X”, which must be applied when no other rule contains any requirements for the interaction that has arisen. When monitoring this interaction, the security module found that the interaction of "module 1" with "module 2" does not correspond to "rule A". “Rule A” in this case requires that the interaction be checked for compliance with “Rule B”. Therefore, the security module checks the interaction for compliance with “rule B”, the module detects that the interaction does not correspond to “rule B”, but in this case, “rule B” does not prescribe anything, therefore the security module applies some “rule X”, which, for example , instructs to stop the interaction.

The present invention in a particular case is carried out by means of SP&O, the elements of which can be executed on the processor of a general-purpose computer (for example, which is shown in Fig. 6).

This invention can also be used to detect anomalies in the execution of a PLC execution system. If anomalies are detected, it is not necessary to isolate the modules, and isolation can be used in the particular case by the methods described above. After dividing into modules, the security module is installed on the PLC and the module data exchange interface is modified, intended for the modules to interact with each other and with the operating system resources so that the specified interaction is carried out only through the installed security module, and the format of the data exchanged corresponds to the format defined by the security module. Thus, the structure of messages exchanged in whole or in part is known to the security module, this structure (data format, sometimes also called an interface) is described, for example, using the Intreface Definition Language (IDL), and as a result, the security module is able to verify that the transmitted message matches this description , and can also use separate fields of this message for validation purposes.

Next, they monitor the interaction of the modules of the PLC execution system with each other and with the resources of the operating system by checking the security module for at least one interaction for compliance with the rules established for this interaction. Messages that are exchanged between the modules and the system by the security module are checked, this is possible, as mentioned above, due to the fact that the structure of the messages exchanged and on which the interaction is based in a particular case is known to the security module.

During monitoring, anomalies are detected in the execution of the PLC execution system based on the interaction inconsistency detected by the security module, which is monitored according to the rule established for this interaction. In another case, the anomalies in the execution of the PLC execution system based on the interaction detected by the security module that is being monitored are monitored according to the rule established for this interaction, where the rule describes the anomalous version of this interaction.

FIG. 6 is an example of a general purpose computer system, a personal computer or server 20 comprising a central processor 21, a system memory 22, and a system bus 23 that contains various system components, including memory associated with the central processor 21. The system bus 23 is implemented as any prior art bus structure comprising, in turn, a bus memory or a bus memory controller, a peripheral bus and a local bus that is capable of interacting with any other bus architecture. The system memory contains read-only memory (ROM) 24, random access memory (RAM) 25. The main input / output system (BIOS) 26, contains basic procedures that ensure the transfer of information between the elements of the personal computer 20, for example, at the time of loading the operating ROM systems 24.

The personal computer 20 in turn contains a hard disk 27 for reading and writing data, a magnetic disk drive 28 for reading and writing to removable magnetic disks 29, and an optical drive 30 for reading and writing to removable optical disks 31, such as a CD-ROM, DVD -ROM and other optical information carriers. The hard disk 27, the magnetic disk drive 28, the optical drive 30 are connected to the system bus 23 through the interface of the hard disk 32, the interface of the magnetic disks 33 and the interface of the optical drive 34, respectively. Drives and associated computer storage media are non-volatile means of storing computer instructions, data structures, software modules and other data of a personal computer 20.

The present description discloses an implementation of a system that uses a hard disk 27, a removable magnetic disk 29, and a removable optical disk 31, but it should be understood that other types of computer storage media 56 that can store data in a form readable by a computer (solid state drives, flash memory cards, digital disks, random access memory (RAM), etc.) that are connected to the system bus 23 through the controller 55.

Computer 20 has a file system 36 where the recorded operating system 35 is stored, as well as additional software applications 37, other program modules 38, and program data 39. The user is able to enter commands and information into personal computer 20 via input devices (keyboard 40, keypad “ the mouse "42). Other input devices (not displayed) can be used: microphone, joystick, game console, scanner, etc. Such input devices are, as usual, connected to the computer system 20 via a serial port 46, which in turn is connected to the system bus, but can be connected in another way, for example, using a parallel port, a game port, or a universal serial bus (USB). A monitor 47 or other type of display device is also connected to the system bus 23 via an interface such as a video adapter 48. In addition to the monitor 47, the personal computer may be equipped with other peripheral output devices (not displayed), such as speakers, a printer, and the like.

The personal computer 20 is capable of operating in a networked environment, using a network connection with another or more remote computers 49. The remote computer (or computers) 49 are the same personal computers or servers that have most or all of the elements mentioned earlier in the description of the creature the personal computer 20 of FIG. 6. Other devices, for example, routers, network stations, peer-to-peer devices or other network nodes, may also be present on the computer network.

Network connections can form a local area network (LAN) 50 and a wide area network (WAN). Such networks are used in corporate computer networks, internal networks of companies and, as a rule, have access to the Internet. In LAN or WAN networks, the personal computer 20 is connected to the local area network 50 via a network adapter or network interface 51. When using the networks, the personal computer 20 may use a modem 54 or other means of providing communication with a global computer network such as the Internet. The modem 54, which is an internal or external device, is connected to the system bus 23 via the serial port 46. It should be clarified that the network connections are only exemplary and are not required to display the exact network configuration, i.e. in reality, there are other ways to establish a technical connection between one computer and another.

In conclusion, it should be noted that the information provided in the description are examples that do not limit the scope of the present invention defined by the claims. One skilled in the art will recognize that there may be other embodiments of the present invention consistent with the spirit and scope of the present invention.

Claims (22)

1. A method for detecting anomalies in the execution of a PLC execution system, in which: a) share the code and data of the PLC execution system or part of the system into separate software modules, while the software modules are divided on the basis of: - the functional structure of the PLC execution system, where a functionally complete fragment of code and data of the PLC execution system is allocated to at least one module, the remaining code and data of the PLC execution system is allocated to another module; or - security threats for the PLC execution system, where a fragment of code and data of the execution system containing the vulnerability used to implement threats is allocated to at least one module, the remaining part of the code and data of the execution system is allocated to another module; or - the criticality of the code and data of the execution system, where a fragment of code and data of the PLC execution system that controls the critical object is allocated to at least one module, the remaining code and data of the PLC execution system are allocated to another module; b) install a safety module on the PLC; c) modify the module data exchange interface, designed for the modules to interact with each other and with the resources of the operating system so that the specified interaction is carried out only through the installed security module, and the format of the data exchanged corresponds to the format defined by the security module; d) monitor the interaction of the modules of the PLC execution system with each other and with the resources of the operating system by checking the security module for at least one interaction for compliance with the rules established for this interaction; e) detect anomalies in the execution of the PLC execution system on the basis of an interaction mismatch detected by the security module, the monitoring of which is carried out, the rule established for this interaction. 2. The method according to p. 1, in which at least one received module is isolated from other modules and from the resources of the operating system in which the PLC execution system is executed, excluding the possibility of direct data exchange with other modules and with PLC OS resources. 3. The method of claim 2, wherein the module is isolated by containerization. 4. The method according to claim 3, in which the security module is installed on the operating system, under the control of which the PLC execution system is executed. 5. The method according to claim 3, in which Linux is used for isolation technology containerization. 6. The method according to p. 1, in which the security module is executed under the control of the operating system, under the control of which the PLC execution system is executed. 7. The method of claim 2, wherein the modules are isolated by virtualization. 8. The method of claim 7, wherein PikeOS virtualization technology is used for isolation. 9. The method of claim 7, wherein the security module is installed on the hypervisor. 10. The method according to p. 1, where when modifying the data exchange interface, the order and protocol of data exchange are changed. 11. The method according to claim 1, wherein modifying the data exchange interface for performing this exchange through the security module is not for any interaction between the modules and the OS, but only critical, where the criticality is determined based on existing and potential threats to the PLC execution system. 12. The method according to p. 1, in which the security module monitors based on the rules, the format of which coincides with the data format that the modules exchange with themselves and with the operating system. 13. The method according to p. 12, in which the interaction is checked by the security module for compliance with at least one rule. 14. The method of claim 1, wherein the module is executed in a separate process.

Images