Network gateway and method for transferring data from a first network to a second network

Abstract

The present invention relates to a network gateway and method for transferring data from a first network to a second network. The method of using the gateway to transfer data from the first network to the second network includes: setting, by a security monitor, the state of the gateway to a first state, the first state indicating to a destination agent that access to a trusted memory is permitted and access to the second network and an untrusted memory is denied. When the gateway is in the first state, configuring, based on parameters stored in the trusted memory, the destination agent to transfer data received from a source agent to the second network. Changing the state of the gateway to a second state, the second state indicating to the destination agent that access to the trusted memory is denied and access to the second network and the untrusted memory is permitted. When the gateway is in the second state, controlling the transfer of data from the source agent in the first network to the destination agent in the second network.

Description

Technical Field

[0001] The present invention generally relates to the field of network communication, and more particularly, to a network gateway and method for transferring data from a first network to a second network. Background Art

[0002] Currently, the application of digital services in the Industrial Internet of Things (IIoT) has become increasingly widespread. Such digital services are typically installed on remote servers and are generally used to process and analyze data received from devices (hardware) of an Internet of Things (IoT)-based Information System (hereinafter referred to as IS). Data from IS devices (such as transducers, sensors, and actuators) is transferred to the remote server through a network gateway.

[0003] The network gateway (hereinafter referred to as the gateway) is responsible for ensuring a reliable and secure connection between the IS device and the remote server. The IS device communicates with the server through the gateway. In other words, the IS device is located on an internal network relative to the server. The server is located on an external network, and the communication between the server and the IS device is carried out through the gateway. Generally, the internal IS network should be protected from computer-based attacks from the external network. The remote server is usually the most vulnerable component because it is connected to an external network, such as the Internet. Therefore, the remote server may be subject to various computer attacks, including but not limited to: MITC attack (Man in the cloud); attacks using errors and vulnerabilities in the remote server code and architecture and the installed services; buffer overflow attacks; Structured Query Language (SQL) injection database attacks; privilege escalation attacks; vulnerable channel attacks; Distributed Denial of Service (DDoS) attacks; data integrity violation attacks; certificate spoofing attacks; phishing attacks; password selection or password reset to obtain unauthorized access; social engineering attacks; attacks involving the installation of malicious software (hereinafter referred to as "SW"); attacks exploiting vulnerabilities; insecure application installation attacks, etc. The MITC attack is an attack based on stealing unique tokens that are generated when a service is first used and stored on the user's machine for convenience. By running a computer attack on the remote server, an attacker can continuously attack the gateway and gain access to the internal IS network. Access to the internal network may in turn lead to unauthorized access to the data of the IS device and even render the IS device and the IS itself inoperable. It should be noted that attacks on the remote server can be carried out externally and internally, for example, through physical access to the server.

[0004] Another type of computer attack on an internal IS network is an attack on the communication channel between the gateway and the remote server, i.e., an attack on the external network. An attacker can perform such an attack by, for example, searching for devices through open ports, searching for device vulnerabilities, intruding into the communication link, performing a man-in-the-middle attack, and by obtaining unauthorized access to the device application.

[0005] A third type of computer attack is a gateway attack, which can be achieved by physically accessing the gateway or by using the external network in the case of a successful attack on the remote server or the external network.

[0006] Therefore, the technical problem that arises relates to the security level of devices connected to the first network (internal network) against computer network attacks originating from the second network (external network).

[0007] However, the known techniques do not solve the said technical problem because copying network traffic into a hidden network for analysis does not fully protect the operational network from computer attacks from the Internet. Therefore, it is necessary to improve the security level of devices connected to the internal network against computer network attacks originating from the external network. Summary of the Invention

[0008] A system and method for transferring data from a first network to a second network using a gateway are disclosed.

[0009] Advantageously, the disclosed method performs a secure one-way data transfer from the first network to the second network.

[0010] Another advantage is to improve the security level of the trusted memory of the network gateway against computer network attacks by allowing access to the trusted memory when the gateway is in the first ("secure") state and by denying access to the trusted memory when the gateway is in the second ("working") state.

[0011] In one aspect, a method of transferring data from a first network to a second network using a gateway includes setting the state of the gateway to a first state by a security monitor. The first state indicates to the destination proxy that access to the trusted memory is permitted and access to the second network and the untrusted memory is denied. When the gateway is in the first state, the destination proxy is configured based on one or more parameters stored in the trusted memory. The destination proxy is configured to transfer data received from the source proxy to the second network. The source proxy is configured to receive data to be transferred from the first network. The state of the gateway is changed to a second state. The second state indicates to the destination proxy that access to the trusted memory is denied and access to the second network and the untrusted memory is permitted. When the gateway is in the second state, the transfer of data from the source proxy in the first network to the destination proxy in the second network is controlled. The destination proxy uses the untrusted memory to perform the data transfer.

[0012] In one aspect, the first state includes a "secure" state and the second state includes a "working" state.

[0013] In one aspect, the second state also indicates that data transfer from the source agent to the destination agent is allowed and data transfer from the destination agent to the source agent is prohibited.

[0014] In one aspect, changing the state of the gateway by the security monitor to the second state further includes changing the state of the gateway by the security monitor after the configuration of the destination agent is completed.

[0015] In one aspect, one or more parameters of the destination agent stored in the trusted memory include one or more authorization parameters for transferring data to the second network.

[0016] In one aspect, one or more parameters of the destination agent stored in the trusted memory include a list of data to be transferred from the first network to the second network.

[0017] In one aspect, configuring the destination agent further includes: creating one or more rules to filter received data based on one or more parameters of the destination agent, and using the one or more rules to subsequently transfer only the filtered data from the first network to the second network.

[0018] In one aspect, the untrusted memory contains a buffer for storing data to be transferred and also contains service information related to the destination agent.

[0019] In one aspect, controlling the transfer of data by the security monitor further includes the security monitor controlling the communication between one or more resources according to one or more predefined security policies, wherein controlling the communication includes permitting or denying access of one resource to another resource, and wherein the one or more resources include: the destination agent, the source agent, the trusted memory, and the untrusted memory. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The drawings incorporated in and forming a part of this specification illustrate one or more example aspects of the invention and, together with the detailed description, serve to explain the principles and implementation of these example aspects.

[0021] Figure 1A 、 Figure 1B and Figure 1C are example diagrams of inter - process communication (IPC) using a security monitor based on an operating system with a micro - kernel architecture.

[0022] Figure 2 is an example system diagram showing the security monitor.

[0023] Figure 3A An example system diagram is shown that shows a gateway for transferring data from a first network to a second network.

[0024] Figure 3B Shows Figure 3A a system diagram of the gateway, where possible types of computer attacks on the gateway components and the first network by an attacker from the second network are indicated.

[0025] Figure 4 is an example of a flowchart showing a method for transferring data from a first network to a second network.

[0026] Figure 5 An example of a computer system is shown on which variant aspects of the systems and methods disclosed herein can be implemented. Detailed Description

[0027] The various exemplary aspects are described herein in the context of systems, methods, and computer program products for protecting user data when an unwanted call occurs. Those of ordinary skill in the art will realize that the following description is merely illustrative and is not intended to be limiting in any way. Those skilled in the art who understand the advantages of the present invention will readily conceive of other aspects. Implementations of the exemplary aspects as shown in the accompanying drawings will now be described in detail. Identical or similar items will be referred to by the same reference numerals throughout the drawings and the following description as much as possible.

[0028] Glossary: Many terms are defined herein that will be used to describe variant aspects of the present invention.

[0029] Process: A series of operations in the execution of a program or a part thereof together with useful data, which may include one or more threads and associated system resources.

[0030] Inter - process communication (IPC): A set of methods for exchanging data between multiple threads in one or more processes. Processes can be launched on one or more computers interconnected by a network. IPC methods can be classified into methods of exchanging messages, synchronization, shared memory, and remote procedure calls.

[0031] An operation is a basic action performed in the process under consideration (a non - limiting example of an operation can be an API function call).

[0032] Modern operating systems can use synchronous and asynchronous operations to transfer data between two processes using IPC methods.

[0033] A finite state machine (FSM) is a model of a discrete device, characterized by multiple states and transitions from one state to another. Each state of the finite state machine represents one of the possible situations in which the finite state machine can be.

[0034] The Internet of Things (IoT) is a computing network of physical objects ("things") equipped with built-in technologies for interacting with each other or with the external environment. The IoT can also include, but is not limited to, technologies such as wearable devices, electric vehicle systems, smart cars, smart cities, industrial systems, etc.

[0035] The Industrial Internet of Things (IIoT) consists of connected devices and advanced analytics platforms that process data obtained from the connected devices. There is a wide range of IIoT devices, from small weather sensors to complex industrial robots.

[0036] A computer attack (also known as a "cyber attack") is a targeted impact on information systems, as well as information and telecommunications networks, by software-based means, with the aim of compromising the security of the information in these systems and networks.

[0037] The network gateway (also known as a gateway) of a local computer network is a device that connects the local computer network to another network.

[0038] A modern operating system (hereinafter referred to as OS) is a complex IS with a large amount of installed software for performing various functions. At the same time, software developers are constantly fixing bugs and continuously expanding the functionality of the software. However, due to software vulnerabilities and the possibility of unauthorized installation of malware, the quantity and scope of such software can pose significant information security risks. The first layer of protection against these threats is the built-in security features of the OS architecture. The OS provides mechanisms for handling and controlling IPC, which can be achieved, in particular, by exchanging messages between processes.

[0039] Many popular operating systems (such as but not limited to Windows 9x, Linux, Android, etc.) can use a monolithic kernel. A monolithic kernel has many advantages, such as simplicity and performance of communication between drivers. However, due to the large number of kernel software modules and the high probability of code errors, it is difficult to ensure the reliability and security of a monolithic OS. Therefore, if there is a vulnerability in the OS, the IPC processing and control features may still allow some unwanted or malicious messages to be passed between processes. An example of such a malicious message between processes is a message requesting access to a protected area of memory. Another type of OS is an OS with a microkernel (e.g., KasperskyOS, Symbian, etc.). The microkernel can provide a minimum set of basic process control and abstract functions that work with hardware. The microkernel architecture of the OS can be characterized by the small size of the microkernel and the trusted computing platform. The microkernel architecture helps to improve the reliability and security of the OS microkernel architecture because it is easier to verify the correctness of a small amount of microkernel code. However, the microkernel architecture generally has lower performance. There are also operating systems with hybrid kernels (such as but not limited to MacOS X, Windows NT, etc.) that allow the operating system to take advantage of the well-structured OS microkernel architecture while maintaining the performance of a monolithic kernel.

[0040] Figure 1A , Figure 1B and Figure 1C is an example diagram of IPC communications using a security monitor 120 based on an operating system 100 having a microkernel architecture.

[0041] Figure 1A The OS 100 shown may include separate processes 131-132 of the application programs of the OS 100 that may interact with each other via IPC. The processes 131-132 may also communicate with each other via messages 140 (also IPC messages, in Figure 1A - Figure 1Binteracts with the OS kernel 110 (indicated by the thick arrow starting with a dot). The message 140 may include, but is not limited to, the following: a request 141 to start process 131, a request 142 from process 131, or a reply 143 from another process 132 (e.g., a call by the first process 131 to a method of the second process 132), a request from process 132 to the security monitor 120 (security request 144). It should be noted that the message 140 as used herein is understood to refer to IPC messages that generally facilitate communication between various processes (including processes 131 - 132) of the OS 100. The security monitor 120 may be a component of the OS 100 configured to control the delivery of the above - mentioned message 140. The implementation details of the security monitor 120 will be disclosed below. The message 140 may also include an error notification from the OS kernel 110 in response to the message 140 from processes 131 - 132. In this case, the above - mentioned interface implemented by the process may be a data structure containing declared methods that implement the functions of the corresponding process.

[0042] The above - mentioned interface may be statically defined, and the allowed communication between processes may be predefined.

[0043] The message 140 may be sent and received by processes 131 - 132 by means of a system call to the OS kernel 110.

[0044] The system call may include, but is not limited to, the following:

[0045] Call(): Used by the first process 131 to send a request 142 to the second process 132 and receive a reply 143 from the second process 132 to perform IPC;

[0046] recv(): Used by the second process 132 to receive the request 142;

[0047] reply(): Used by the second process 132 to send the reply 143 to the first process 131.

[0048] In one aspect, the system call reply() may be executed in the same process thread that executes the call recv().

[0049] The security monitor 120 may be implemented to have the ability to run on a computer processor running the OS 100 ( Figure 5An example of a general-purpose computer 20 is shown). The security monitor 120 may be configured to control the delivery of the message 140 according to a decision 150, which is made based on a security policy from the policy database 121. The control of the delivery of the message 140 may include allowing or prohibiting the delivery of the message 140 and thus allowing or prohibiting the execution of the communication using the message 140. The decision 150 regarding the method of controlling the delivery of the message 140 may indicate that the authorization or transmission of the message 140 complies with the security policy. The decision 150 may be used by the security monitor 120 or its components to implement the control of the delivery of the message 140 (see Figure 2 ). Based on the security policy from the policy database 121, the data in the message 140 (e.g., the name of the process to be launched or the actual arguments of the process method called) may be used to issue the decision 150.

[0050] In addition, the decision 150 regarding the method of controlling the delivery of the message 140 may depend on the correctness of the structure of the message 140. Thus, if the message 140 has an invalid structure, the transmission of the message 140 may be prohibited. In this case, a declarative description of the interface of the process recipient of the message 140 may be used to define the valid message structure. The above structure may include the size of the message 140, valid arguments, and other valid parameters of the message 140.

[0051] In one aspect, the security monitor 120 may be part of the OS kernel 110 or a separate application. In another aspect, the security monitor 120 may run in the privileged mode of the OS kernel 110.

[0052] One aspect of the OS 100 may also include an audit service 133, which is designed to record the results of the control of the delivery of the message 140. In this case, the control of the delivery of the message 140 may also include performing an audit using the audit service 133. On the other hand, the security monitor 120 may control the delivery of the message 140, also considering the current state of the audit service 133. This state indicates that the audit service 133 is ready to receive and store the message 140. For example, if the first process 131 (through the second process 132) sends a request 142 to a security resource (where information about access to the security resource should always be recorded), but the state of the audit service 133 indicates that the audit service 133 is not currently storing the message 140, the security monitor 120 may prohibit such a request 142 according to the security policy.

[0053] In one aspect, the OS 100 can include a security monitor context 122. The security monitor 120 can also consider the context 122 to control the delivery of the message 140. The security monitor context 122 can include values of security policy parameters. In one aspect, the security monitor 120 can also be configured to change the context 122 based on a decision 150 considering a security policy from the policy database 121. In one aspect, the security policy can use a finite state machine model, a mandatory integrity control model, or other models that implement the security policy. Details of these models will be disclosed in the description of Figure 3A later. Depending on the model used by the security policy, the context 122 can include different security policy parameters. For example, for a security policy based on the mandatory integrity control model, the context 122 can include values of the integrity level and the access level to the protected resource. For a security policy based on a finite state machine, the context 122 can include the current value of the state of the finite state machine and the transition table of the finite state machine.

[0054] Figure 1B An example of using the security monitor 120 to control the delivery of an allowed request 142 from a first process 131 to a second process 132 is shown. The first process 131 can call an interface method of the second process 132, and the first process 131 can send a request 142 containing the input arguments of the called method for this purpose. The first process 131 can send the request 142 through the OS kernel 110. The OS kernel 110 can in turn send the request 142 to the security monitor 120 for verification. The security monitor 120 can issue a decision 150 "allow" based on the security policy from the policy database 121 and can transmit the decision 150 to the OS kernel 110. Then, the OS kernel 110 can forward the request 142 to the second process 132 based on the decision 150.

[0055] In Figure 1B the example shown, the second process 132 can then send a reply 143 to the first process 131 (the reverse order of the message 140 is not indicated), where the reply 143 can include the output arguments of the called method. The method of sending the reply 143 can be the same as the method of sending the request 142, but in the reverse order, that is, from the second process 132 to the first process 131. That is, the second process 132 can send the reply 143 with the help of the OS kernel 110. The OS kernel 110 can in turn send the reply 143 to the security monitor 120 for verification. The security monitor 120 can issue a new decision 150 "allow" based on the security policy from the policy database 121 and can transmit this new decision 150 back to the OS kernel 110. Then, based on the new decision 150, the OS kernel 110 can forward the reply 143 to the first process 131.

[0056] Figure 1C An example of controlling a prohibited request 142 from a first process 131 to a second process 132 is shown. In the example shown, the security monitor 120 can control the transfer of the request 142 by prohibiting the transfer of the request 142. The first process 131 can send the request 142 through the OS kernel 110. The OS kernel 110 can in turn send the request 142 to the security monitor 120 for verification. The security monitor 120 can issue a decision 150 of "prohibit" based on the security policy from the policy database 121, and can transmit the decision 150 to the OS kernel 110. The OS kernel 110 can then send an error notification to the first process 131 based on the decision 150. In this case, the request 142 will not be transferred to the second process 132.

[0057] Figure 2 An example system 200 for a security monitor is shown. The system 200 for generating a security monitor can be used to enhance the security of the OS 100 when exchanging messages 140 and also to control the transfer of the messages 140 to the recipient. In this case, software developers can use the security monitor 120 in various operating systems 100 and / or any other computer systems that use the exchange of messages 140, including but not limited to use in databases and application software. Examples of such use have been discussed previously in conjunction with Figure 1A - Figure 1B For each operating system 100, the security monitor 120 can be generated based on the characteristics of the OS architecture 240 and by considering the security requirements of that operating system 100 as expressed in the security policy. It should be noted that various software and firmware development systems (hereinafter referred to as development systems) based on the OS 100 can share the main objects of the OS architecture 240. Examples of such objects can include but are not limited to processes, services, applications, drivers responsible for operating the OS kernel 110 and other components 260 of the operating system. At the same time, other objects of the OS architecture 240 responsible for the functions of the development system may vary for each of the systems mentioned. Therefore, different security policies may be required to control the transfer of the messages 140. The development system can include software as well as firmware systems.

[0058] System 200 may include a policy database 121 that may be configured to store security policies required for the delivery of control messages 140. System 200 may also include at least one configuration tool 220 that may be designed to configure a corresponding authentication module 221 based on the security policies received from a generation tool 210. The authentication module 221 may be configured to generate a decision 150 (hereinafter referred to as a decision) regarding the method of delivery of control messages 140 according to a request from a security monitor 120 when implementing the security policies from the policy database 121. System 200 may also include a description of the OS architecture 240. The description of the OS architecture 240 may include, but is not limited to: OS architecture objects such as processes and applications of the OS 100. In one aspect, the OS architecture objects may also include objects of a development system based on the OS 100. In one aspect, the OS architecture objects may also include, but are not limited to:

[0059] A service-providing process that may include at least one software component that may be configured to implement a software interface of a given process; may perform communication with the given process using the above interface (for example, such a service may be an application that transforms an external event stream and requests an event handling process);

[0060] A list of programming interfaces for each process; may also specify corresponding interface methods for implementing the functions of the corresponding process.

[0061] In one aspect, the OS architecture objects may also be resource drivers - processes that manage resources and access them. Resources may be, but are not limited to, files, ports, or processes. For example, a file system is a resource driver, and a file itself is a resource that the file system may provide other processes access to.

[0062] In addition, system 200 may include a generation tool 210, which may be configured to analyze security policies. The analysis may include, but is not limited to: identifying processes using a given security policy. In one aspect, the foregoing analysis may consider OS architecture objects 240, including the foregoing processes and applications. Generation tool 210 may also be configured to select a security policy from policy database 121 for a corresponding configuration tool 220, and transmit at least one selected security policy to the corresponding configuration tool 220. Generation tool 210 may also be configured to generate security monitor 120 based on the analysis results, using a verification module 221 of the configuration obtained from each configuration tool 220. In one aspect, generation tool 210 may generate security monitor 120 by creating the code of security monitor 120. The code may include, but is not limited to, source code, intermediate code, or executable code. In addition, the generation of the code of security monitor 120 may also include code optimization and error analysis. Thus, generation tool 210 may be a compiler that generates the code under discussion.

[0063] OS architecture 240, policy database 121, and configuration tool 220 may be pre-configured using development tool 250. For example, development tool 250 may provide a set of APIs (application programming interfaces) or plug-in modules for software development. As used herein, the term "interface" refers to the process interface described above. In one aspect, at least a portion of OS architecture 240, a portion of the security policies from policy database 121, and a portion of configuration tool 220 may be shared (based on a template) between different operating systems 100. In such a sharing scenario, a developer may use development tool 250, OS architecture 240, and the security policies from policy database 121 to configure configuration tool 220. In one aspect, a developer may add security policies, OS architecture objects 240, and configuration tool 220 that are missing from the template, which may be required to reflect the characteristics of OS 100 or a development system based on OS 100, as well as the security requirements of OS 100 or a development system based on OS 100, where a given developer generates security monitor 120 for OS 100. In addition, if certain data is not required in OS100 or OS development system 100, such data may be deleted from the template under discussion. For example, certain security policies and applications may be deleted.

[0064] The security monitor 120 can be generated together with other components 260 of the OS and can also be incorporated into the operating system 100. The above incorporation of the security monitor 120 and the OS components 260 can be achieved using techniques known in the art. For example, the security monitor 120 and the OS components 260 can be incorporated during the compilation phase of the OS 100 using the OS 100 compiler or by installing the security monitor 120 on the OS 100. As previously mentioned, the security monitor 120 can be part of the OS kernel 110 or a separate application of the OS 100. The security monitor 120 can run in privileged mode on the OS kernel 110. For the OS 100, an OS installation image 270 can also be created to install the OS 100 on an end-user computing device. The OS installation image 270 can be, but is not limited to, an archive material, an executable file, or an installation package. The installation package can be an archive file that includes files of the OS 100, control files, and optionally files for configuring the installation process of the OS 100. Additionally, the installation package can include system developer files based on the OS 100. These files can be provided as source code, intermediate code, or executable code.

[0065] Security policies from the policy database 121 can be defined using a specification language such as PSL (Policy Specification Language). In the PSL example, mandatory integrity control can be defined by the policy class Mandatory_integrity_control. The class (family) of security policies can define a set of rules that match the rules of the model used in the security policy. The security policy specification can determine the correspondence of these rules with the communications in the system, and these communications in the system can be achieved by exchanging messages 140 between processes. For each communication attempt, i.e., each time the security monitor 120 verifies a message 140, the security monitor 120 can apply these rules to generate a decision 150 regarding the validity of a given communication (the delivery of the message 140). To use a policy class, a policy object can be created based on the policy class for which a configuration is specified.

[0066] Figure 3A An example system diagram is shown that shows a network gateway 300 for transferring data from a first network 310 to a second network 350. In one aspect, the gateway 300 can be implemented as a separate computer device or a hardware router. In another aspect, the gateway 300 can be implemented as a virtual machine running on the processor of a general-purpose computer 20. The operating system used in the gateway 300 can be the OS 100 (an example of which is in Figure 1A - Figure 1B(shown in), and may include a security monitor 120 implemented to have the ability to run on the processor of the gateway 300. The first network 310 may be the internal network of the Internet of Things-based IS 340. The data source 311 may include devices of the IS 340 connected to the first network 310 and connected to the gateway 300, for transmitting data to the data destination server 351 through the second network 350 to which the gateway 300 is also connected. The data destination server 351 may include, but is not limited to, for example, a remote server.

[0067] Since the gateway 300 is a computer device based on the OS 100, the security monitor 120 can be used to control the communication with the gateway 300. In one aspect, the security monitor 120 can be implemented as a separate computer device, such as Figure 5 the general-purpose computer 20 shown. The security monitor 120 can be configured to control the communication between the software components of the gateway 300, which may be provided in the form of services, applications, and processes of the OS 100 installed on the gateway 300 and can be implemented to have the ability to run on the processor of the gateway 300. The components of the gateway 300 may include, but are not limited to: a first network interface card (NIC) driver 313, a first I / O system 314, a source proxy 315, a data processing service 316, a first virtual file system (VFS) 317, a data storage drive 320, a second VFS 356, a destination proxy 355, a second I / O system 354, and a second NIC driver 353. In one aspect, the data storage drive 320 can store in a trusted memory 331 and an untrusted memory 332. In this case, the trusted memory 331 and the untrusted memory 332 can also be components of the gateway 300, which means they can contain services, applications, and processes implemented to have the ability to run on the processor of the gateway 300. At the same time, the trusted memory 331 and the untrusted memory 332 can reside on a machine-readable medium of the gateway 300 having data storage capabilities.

[0068] For each component of the gateway 300, a security policy can be defined in the policy database 121 according to which the security monitor 120 can control each communication between the above components of the gateway 300.

[0069] The gateway 300 can have at least two states called "secure" and "operational". The "secure" state can indicate that the destination agent 355 is permitted access to the trusted memory 331 and denied access to the second network 350 and the untrusted memory 332. The "operational" state can indicate that the destination agent 355 is denied access to the trusted memory 331, permitted access to the second network 350 and the untrusted memory 332 and is also permitted to transfer data from the source agent 315 to the destination agent 355, and prohibited from transferring data from the destination agent 355 to the source agent 315. For example, information about the current state of the gateway 300 can be stored in the security monitor 120. On the other hand, information about the current state of the gateway 300 can be stored in the trusted memory 331 or in a separate temporary or permanent data memory of the gateway 300 (not shown in FIG. 3). Thus, the security policy can also depend on the state of the gateway 300. For example, a security policy can be specified under which the destination agent 355 is permitted access to the trusted memory 331 in the "secure" state of the gateway 300. There can be another security policy that denies the destination agent 355 access to the trusted memory 331 in the "operational" state of the gateway 300. More details about the security policy will be described below.

[0070] Since the gateway 300 uses the secure OS 100, the above components of the gateway 300 can communicate with each other using IPC. These components can also communicate with the OS kernel 110 by exchanging messages 140 (also IPC messages) using a software interface. The above interfaces can be implemented by processes, can be statically defined, and the permitted communications between the processes can be predefined. Processes 131 - 132 can send and receive messages by means of system calls to the OS kernel 110. The security monitor 120 can be configured to control these communications by controlling the delivery of the messages 140 under discussion. More information about the control of IPC communications by the secure OS 100 and the security monitor 120 was described previously in connection with Figure 1A - Figure 1B is described.

[0071] According to one aspect, the security monitor 120 can be used to set the state of the gateway 300 to "secure". The "secure" state can indicate that the destination agent 355 is authorized to access the trusted memory 331 and denied access to the second network 350 and the untrusted memory 332. To implement these permissions and prohibitions, at least one security policy can be defined in the policy database 121 under which, in the "secure" state of the gateway 300, the destination agent 355 is permitted access to the trusted memory 331 and denied access to the second network 350 and the untrusted memory 332.

[0072] It should be noted that the security policy can be predefined by the administrator of the gateway 300. In addition, the security policy can be defined by the security monitor 120 during the operation process of the gateway 300.

[0073] The trusted memory 331 can contain data crucial for the secure operation of the gateway 300 and the data source 311, such as authorization settings for transmitting data to the second network 350 (including but not limited to login names, passwords, certificates, electronic / digital signatures required for authorizing the data transmission process), software on the gateway 300, configuration files (settings) of various components of the gateway 300 (especially the settings of the destination proxy 355), etc. The untrusted memory 332 can contain data that is not important for the secure operation of the gateway 300 and the data source 311. Such non-critical data can include but not limited to: service information of the data destination server 351, service information of the destination proxy 355, and buffers for storing data to be transmitted. The service information can include authorization information of the data destination server 351 and the applications and services installed on the above data destination server 351. Such authorization data can include, for example, access API tokens.

[0074] In the shown scenario, the destination proxy 355 can be configured to establish communication with the data destination server 351 and can also be configured to transmit the data received from the source proxy 315 to the data destination server 351 via the second network 350. If the data destination server 351 is a Siemens MindSphere-based cloud server, a non-limiting example of the destination proxy 355 can be Mind Proxy.

[0075] The source proxy 315 can be configured to receive the above data from the first network 310 from the data source 311, for example, using the OPC UA (Unified Architecture) industrial communication protocol. OPC is an interoperability standard for secure and reliable data exchange in the field of industrial automation and other industries. In addition, if the security policy from the policy database 121 is implemented, the security monitor 120 can be configured to provide access to the trusted memory 331 according to the request from the destination proxy 355.

[0076] The destination agent 355 can be designed to be configured to the "secure" state of the gateway 300 based on the parameters of the destination agent 355 from the trusted memory 331. This configuration can be performed by the destination agent 355 itself. In one aspect, the destination agent 355 can be configured by the security monitor 120. This configuration of the destination agent 355 can be performed when the gateway 300 is in the "secure" state where the destination agent 355 is allowed to access the trusted memory 331 and is denied access to the second network 350 and the untrusted memory 332. At the same time, the first VFS 317 can be used to grant the destination agent 355 access to the trusted memory 331. The security monitor 120 can also change the state of the gateway 300 to the "working" state after the destination agent 355 is configured. At the same time, the "working" state of the gateway 300 can indicate to the destination agent 355 that it is denied access to the trusted memory 331, is allowed access to the second network 350 and the untrusted memory 332, and allows data to be transmitted from the source agent 315 to the destination agent 355 and prohibits data from being transmitted from the destination agent 355 to the source agent 315. To implement these permissions and prohibitions, a security policy can be set in the policy database 121, according to which, in the "working" state of the gateway 300, the destination agent 355 is denied access to the trusted memory 331 and is allowed access to the second network 350 and the untrusted memory 332, while the source agent 315 is allowed to transmit data to the destination agent 355 and the destination agent 355 is not allowed to transmit data to the source agent 315. In this case, before the configuration, the destination agent 355 may not be provided with the above permissions and prohibitions.

[0077] In one aspect, the specified configuration of the destination agent 355 may include, but is not limited to, preparing an authorization request that contains authorization parameters (including but not limited to a login name, password, certificate, and digital signature required to authorize the data transfer process) for the data destination server 351 on the second network 350. Accordingly, the configuration result of the destination agent 355 may include the above authorization request. Meanwhile, after the status of the gateway 300 changes to the "working" state, the prepared request can be sent to the data destination server 351 using the destination agent 355 to authorize and establish a connection for subsequent data transfer. In one aspect, the parameters of the destination agent 355 contained in the trusted memory 331 may also include a list of data to be transferred from the first network 310 to the second network 350. Such a list may include, but is not limited to, for example, data of a specified device only from the data source 311, or data of a specified data type, etc. In this example, the configuration of the destination agent 355 may optionally include the following steps: configuring a data filter according to the specified parameters to filter (and also process) the data received from the source agent 315. The configuration of the data filter may include, but is not limited to, creating rules for filtering the received data according to the above parameters of the destination agent 355 so that only the filtered data is subsequently transferred to the second network 350. The data filter may also be a part of the destination agent 355.

[0078] The source agent 315 and the destination agent 355 can be used to transfer data from the first network 310 to the second network 350 under the control of the security monitor 120. The security monitor 120 may implement the security policy from the policy database 121 based on the configuration of the destination agent 355. In this case, the destination agent 355 may use the untrusted memory 332 to perform the given data transfer. The untrusted memory 332 may include, but is not limited to, service information of the recipient, i.e., the data destination server 351.

[0079] In one aspect, the trusted memory 331 and the untrusted memory 332 can be two separate data memories (machine-readable media). In another aspect, the trusted memory 331 and the untrusted memory 332 can be two different partitions of the same data memory 330 located within different address ranges of the data memory 330. The data memory 330 can include, but is not limited to, for example, a hard disk, a flash memory, or other machine-readable data storage media. In this case, access to the trusted memory 331 and the untrusted memory 332 can be implemented as access to respective devices. Thus, both of the above two embodiments can be used in the gateway 300. For ease of explanation, the second aspect in which the trusted memory 331 and the untrusted memory 332 are two partitions of the same data memory 330 will be considered below. The data memory 330, and thus the trusted memory 331 and the untrusted memory 332, can be accessed using the data storage drive 320. The data storage drive 320 can be configured to perform I / O operations on the data memory 300 under the control of the security monitor 120 and observing the security policies from the policy database 121.

[0080] However, the first VFS 317 can be configured to organize access (read and write access to files) to the trusted memory 331 in the gateway 300, and the second VFS 356 can be configured to organize access to the untrusted memory 332. Security policies can be defined that allow the listed communications and prohibit other communications. In other words, a first range of security policies that only reference the memory addresses of the data memory 300 corresponding to the trusted memory 331 can be assigned to the first VFS 317. Similarly, a second range of security policies that only allow reference to the memory addresses of the data memory 300 corresponding to the untrusted memory 332 can be assigned to the second VFS 356. Thus, according to the security policies, the first VFS 317 can be permitted to access the trusted memory 331 and be denied access to the untrusted memory 332. The second VFS 356 can also be permitted to access the untrusted memory 332 and be denied access to the trusted memory 331.

[0081] The gateway 300 may also include a first NIC 312, and the first NIC 312 may be configured to provide connectivity to the first network 310. The driver of the first NIC 313 may be configured to send and receive data from devices of the first NIC 312, particularly from the data source 311. In one aspect, the source agent 315 may access the first NIC driver 313 through the first I / O system 314. A security policy may be defined to permit these communications and prohibit other communications. In particular, in the "secure" and "working" states of the gateway 300, the first I / O system 314 may be permitted to access the first NIC driver 313 and the source agent 315, while the first NIC driver 313 may be permitted to access the first I / O system 314 and may also be permitted to receive data from the data source 311 on the first network 310 through the first NIC 312. However, unspecified communications may be prohibited.

[0082] To connect to the second network 350, the gateway 300 may include a second NIC 352. The second NIC driver 353 may be configured to send and receive data from devices on the second network 350, particularly from the data destination server 351. In one aspect, the destination agent 355 may be configured to access the second NIC driver 352 through the second I / O system 354. In this case, the security policy may be defined to permit the listed communications and prohibit other communications, particularly but not limited to the following:

[0083] In the "secure" state of the gateway 300: there may be no permitted communications for the second I / O system 354 and the second NIC driver 353;

[0084] In the "working" state of the gateway 300: the second I / O system 354 may be permitted to access the destination agent 355 and the second NIC driver 353, the second NIC driver 352 may be permitted to access the second I / O system 354, and data exchange with devices on the second network 350 (using the second NIC 352) may also be permitted;

[0085] Unspecified communications may be prohibited.

[0086] The first NIC 312 and the second NIC 352 may be any known or later developed network cards in the art (including but not limited to network boards, network adapters, network interface controllers). The first NIC 312 and the second NIC 352 may be devices respectively used for communications between the gateway 300 and other devices of the first network 310 or the second network 350. Examples of such network cards include but are not limited to Ethernet adapters, Wi-Fi adapters, Bluetooth adapters, etc.

[0087] In one aspect, the source agent 315 may be communicatively coupled to the destination agent 355 using the data processing service 316. The data processing service 316 may be used to request and receive data from the source agent 315 and subsequently forward the data unidirectionally to the destination agent 355. It should be noted that a security policy allowing access to the destination agent 355 in the "working" state of the gateway 300 may be specified for the data processing service 316 in the policy database 121. At the same time, for the destination agent 355, a security policy denying access to the data processing service 316 in the "working" state of the gateway 300 may be specified. This solution may implement unidirectional data transfer in the "working" state of the gateway 300. However, during the initialization process of the gateway 300, when the gateway 300 is in the "secure" state, the destination agent 355 may be considered a trusted component of the gateway 300 and may be allowed to access the trusted memory 331.

[0088] According to the above aspect, the parameters of the destination agent 355 included in the trusted memory 331 may include, but are not limited to, a list of data to be transferred from the first network 310 to the second network 350. According to another aspect, the data processing service 316 may also be configured to obtain the above parameters of the destination agent 355 and then configure a data filter to filter (process) the data received from the source agent 315 according to the given parameters. In this case, the data processing service 316 may obtain the above parameters from the destination agent 355 or from the trusted memory 331 through the source agent 315 in the "secure" state of the gateway 300. In both cases, a security policy allowing these communications and prohibiting other communications may be defined in the policy database 121.

[0089] The configuration of the data filter may include, but is not limited to, creating rules for filtering the received data according to the above parameters of the destination agent 355 so that only the filtered data is subsequently transferred to the second network 350. The data filter may be a part of the data processing service 316.

[0090] The data processing service 316 may be configured to transfer the already filtered data to the destination agent 355 in the "working" state of the gateway 300. This solution implements unidirectional data transfer from the source agent 315 to the destination agent 355 using the data processing service 316 in the "working" state of the gateway 300. In addition, in the case where an attacker may compromise the destination agent 355, the attacker will only gain access to the filtered data, rather than the original data received by the source agent 315. At the same time, the attacker can still access the filtered data by compromising the second network 350 or the data destination server 351. Therefore, this aspect further enhances the data security of the first network 310.

[0091] Description of the security policy

[0092] In certain aspects, a security policy may use at least one of the following models: basic operations; finite state machines; timed automata; role-based access control; mandatory integrity control; regular expressions; discrete event systems (DES); object capability models; temporal logic.

[0093] The security policy from the policy database 121 may be defined using a specification language such as, but not limited to, PSL (Policy Specification Language) and eXtensible Access Control Markup Language (“XACML”). In the PSL example, a finite state machine may be defined by the policy class finite_state_machine. A class (family) of security policies may define a set of rules that match the rules of the models used in the security policy. The security policy specification may determine the correspondence of this set of rules with the communications in the OS 100, which may be achieved by exchanging messages 140 between processes corresponding to the components of the gateway 300. For each communication attempt, i.e., each time the security monitor 120 verifies a message 140, the security monitor 120 may apply at least one rule to generate a decision on the validity of a given communication (the delivery of the message 140). To use a policy class, a policy object with a specified configuration may be created by the security monitor 120 based on the policy class.

[0094] In one aspect, the analysis of the security policies and objects of the OS architecture 240 may include, but not be limited to, at least one of the following types of analysis: lexical analysis, syntactic analysis, semantic analysis. The security policy analysis may identify the objects of the OS architecture 240, particularly the processes involved in the exchange of messages 140 to which a specified security policy may be applied. In other words, the security monitor 120 may determine the correspondence between the objects identified in the OS architecture 240 and the security policies applied to the specified objects. For example, if a security policy permits a request 142 from a first process 131 to a second process 132, the analysis of this security policy may identify the specific processes 131 - 132 and the information regarding the permitted request 142. It should be noted that due to this security policy analysis, other objects of the OS architecture 240 that are verified in the specified security policy may be further identified. For example, when a message 140 is sent to a process interface method and is to be delivered to a specified process interface, the security monitor 120 may identify the specified method. In such a case, the security policy may verify the requirements for using the defined process interface and the defined interface method when exchanging messages 140 between the identified processes.

[0095] In an example of the PSL language that can be used to define security policies in the policy database 121, a reference to the first process 131 that is the source of the request 142 can be included in the variable "scr". A reference to the second process 132 that is the destination of the request 142 can be included in the variable "dst". Thus, the above analysis of the security policy from the policy database 121 written in the PSL language can allow identification of the specified OS architecture objects to which the specified security policy can be applied.

[0096] On the other hand, the analysis of the security policy from the policy database 121 can also include checking the types of objects of the OS architecture 240 and analyzing errors in the security policy from the policy database 121.

[0097] The results of the above analysis can be considered when generating the security monitor 120. For example, the security monitor 120 can record the security policy application conditions - a list of objects of the OS architecture 240. The object list can include, for example, processes and security policies corresponding to the list and the verification module 221. Thus, when receiving the message 140 from the OS kernel 110, the generated security monitor 120 can identify the objects of the OS architecture 240 participating in the exchange of the message 140, and then can determine the security policy applied to the specified objects of the OS architecture 240. The security monitor 120 can then send the message 140 corresponding to the specified security policy to the verification module 221 to decide how to control the delivery of the message 140.

[0098] On the one hand, syntactic analysis can be performed by constructing a syntax tree of the code of the security monitor 120. The syntax tree can include the code of the verification module 221 generated by at least one configuration tool 220.

[0099] The security policy can use basic operations that allow or deny the transmission of the message 140 provided that the parameters of the message 140 (e.g., the name of the process to be started or the actual arguments of the method to be called) match the data specified in the security policy. For example, the security policy can determine that the first process 131 can receive any message but is not allowed to send messages.

[0100] In one aspect of the security policy, a finite state machine can be used, where the state of the finite state machine can be the state of the gateway 300. The security policy can determine whether to allow or deny access from one component of the gateway 300 to another component of the gateway 300 according to the state of the finite state machine and according to the state transition table of the finite state machine.

[0101] The following is a description of an exemplary secure_gateway finite state machine:

[0102]

[0103] The secure_gateway finite state machine can be in one of the following states: "Secure" (secure state), "Working" (operational state). The state of the secure_gateway finite state machine can correspond to the state of the gateway 300. The transition table of the finite state machine can be represented in the "transitions" structure. When the secure_gateway finite state machine is initialized, it can be in the "Secure" state. The "Secure" state can indicate that the destination agent 355 is allowed to access the trusted memory 331 and is denied access to the second network 350 and the untrusted memory 332. From the "Secure" state, the finite state machine can only transition to the "Working" state. The "Working" state can indicate to the destination agent 355 that it is denied access to the trusted memory 331 and is allowed access to the second network 350 and the untrusted memory 332. The "Working" state can also indicate that data transfer from the source agent 315 to the destination agent 355 is allowed, and data transfer from the destination agent 355 to the source agent 315 is prohibited.

[0104] In this case, from the "Working" state, the secure_gateway finite state machine can only transition to the same "Working" state and cannot return to the "Secure" state.

[0105] The following are examples of security policies in the policy database 121 of the destination agent 355 (Agent_dst) that can use the secure_gateway finite state machine.

[0106]

[0107]

[0108] According to the above security policy, if the secure_gateway finite state machine is in the "Secure" state, the destination agent 355 can be allowed to access ("Read" method) the trusted memory 331 (Safe_storage).

[0109]

[0110] If the secure_gateway finite state machine is in the "Secure" state, the security policy can prohibit the destination agent 355 (Agent_dst) from accessing ("Access" method) the second network 350, for example, via the second I / O system 354 (O_ext).

[0111]

[0112] According to the above security policy, if the secure_gateway finite state machine is in the "secure" state, the destination agent 355 can be denied access to the untrusted memory 332 (Unsafe_storage) (the "Read" and "Write" methods).

[0113] security src=Secure_monitor,method=Confirm{

[0114] secure_gateway.enter[Work];

[0115] }

[0116] According to this security policy, the security monitor 120 can be allowed to implement the security request 144 to change the state of the secure_gateway finite state machine (the method "Confirm") to "Work". In this case, if the specified state change of the finite state machine matches the transition table of the finite state machine, the security monitor 120 can also perform the state change of the finite state machine.

[0117]

[0118] According to this security policy, if the secure_gateway finite state machine is in the "Work" state, the destination agent 355 is allowed access to the untrusted memory 332 (the methods "Read" and "Write").

[0119]

[0120] According to this security policy, if the secure_gateway finite state machine is in the "Work" state, the destination agent 355 is denied access to the trusted memory 331 (the "Read" and "Write" methods). It should be noted that if the security monitor 120 applies the security policy according to the "default deny" model, this security policy can be optional (i.e., not present in the policy database 121). In this case, if the policy database 121 does not have a security policy that allows the destination agent 355 to access the trusted memory 331 when the finite state machine is in the "Work" state, this access will be denied by default.

[0121]

[0122] According to this security policy, if the secure_gateway finite state machine is in the "working" state, the destination agent 355 is allowed to receive data (method "Receive") from the source agent 315 (Agent_src) and is not allowed to transfer data to the source agent 315 (method "Transfer").

[0123]

[0124] If the secure_gateway finite state machine is in the "working" state, this security policy allows the destination agent 355 to access (method "Access") the second network 350, for example, by means of the second I / O system 354.

[0125] In another aspect of the security policy, a timed automaton model can be used. For example, the security monitor 120 can use an ERA type (Event Recording Automaton) timed automaton. The ERA automaton is a special case of a finite state machine. In this model, an additional time parameter (timer) can be set for each message, equal to the time since the last receipt of that message. For example, if a message is received after the time defined by the timer, a transition from one finite state machine state to another may occur.

[0126] The mandatory integrity control model can be used to allow or deny the delivery of messages 140. According to the mandatory integrity control model, using the security monitor 120, the objects of the OS architecture 240 involved in the transmission of the message 140 (e.g., processes 131 - 132) can be mapped to two numbers called the integrity level and the access level. In this process, a security policy based on mandatory integrity control can be used to allow the transfer of messages from one object to another based on the values of the integrity level and the access level of the objects. For example, if the value of the access level of the first object is not less than the integrity level of another object, a security policy that allows one object to access another object can be used. In the PSL specification language, the integrity level and the access level can be defined for the mandatory integrity control model. Therefore, to set the integrity level, the "integrity" policy object can be defined as an instance of the Mandatory_integrity_control class:

[0127]

[0128] The integrity policy object configuration can define three integrity levels in ascending order: low, medium, and high. In other words, low < medium < high.

[0129] Policies based on the object - capability model can be based on the principle of least privilege. This principle of resource - access organization means that only the privileges that are absolutely necessary for successfully completing a task are given to a subject (process or user). For example, a user who wants to find out the content of a file should be granted only the read permission for that file and only for the duration of its use.

[0130] On the one hand, security policies can use temporal logic. To define a security policy based on temporal logic, security properties (requirements) can be formulated based on temporal - logic formulas and using temporal operators. Using the security monitor 120, the components of the gateway 300 can be mapped to their state events from a set of predefined events. For the gateway 300, this set of events can include, but is not limited to, the following: {read_safe, data_transfer}, where read_safe is the event that the destination agent 355 accesses the trusted memory 331, and data_transfer is the event of data transfer from the first network 310 to the second network 350 by the transfer from the source agent 315 to the destination agent 355. A security property can be formulated, for example, as follows:

[0131] Property 1. Whenever the destination agent 355 obtains access to the trusted memory 331 in the "secure" state of the gateway 300, it should be ensured that after the gateway 300 transitions to the "working" state, the destination agent 355 should not be able to read data from the trusted memory 331. It should also be ensured that the destination agent 355 can access the untrusted memory 332 and the external network 350 only if the destination agent 355 has previously accessed the trusted memory 331 (i.e., the read_safe event has occurred). Additionally, when the read_safe event occurs, it can be guaranteed that data transfer from the source agent 315 to the destination agent 355 is allowed, and data transfer from the destination agent 355 to the source agent 315 is prohibited. The specified property can be written as a formula:

[0132] G(data_transfer => P read_safe),

[0133] where G is the temporal operator "always in the future", and P is the temporal operator "at least once in the past".

[0134] The construction of a policy - class object for implementing access control based on temporal logic can be implemented in the PSL language as the following structure:

[0135] policy object tl_checker = TL{

[0136] config “G(data_transfer => P read_safe)”

[0137] }

[0138] It should be noted that other expressions of Attribute 1 are possible. For example, Attribute 1 can be defined as follows: data transfer occurs only when the destination agent 355 accesses the trusted memory 331 (i.e., until the state of the gateway 300 changes from “secure” to “working”):

[0139] !data_transfer U read_safe,

[0140] where U is the temporal operator “until such time as the specified event occurs”.

[0141] When transferring data from the first network 310 to the second network 350, the policy based on the temporal logic model can associate the data_transfer event with this inter-process communication and can verify the truth of the formula specified in the policy object configuration. If the formula is true, the policy can allow the communication; if it is false, the policy can prohibit the communication.

[0142] Policies based on the discrete event model can be defined using the verification module 221 corresponding to the policy. These security policies can also be described in the PSL specification language. These security policies can be applied to development systems containing a large number of components. For the above system, the model with discrete events can be a composite finite state machine defined by the combination of a set of finite state machines. Each finite state machine can describe a separate component of the system. For each finite state machine, when certain events occur, it can indicate its set of states and the transitions between states. The state of the composite finite state machine can be determined by the combination of the states of the finite state machines of the system components. In this case, the specified combination can be achieved, for example, by the synchronous or asynchronous generation of finite state machines. For the composite finite state machine, a list of allowed transitions, a list of allowed states, and a list of prohibited states of the resulting finite state machine can also be specified. Therefore, security policies can be used to verify the transitions of system components and the resulting finite state machine to the initial state defined in the corresponding finite state machine configuration (the configuration can include, but is not limited to, a set of states and transitions), the transitions between states when specific events occur, and the occupancy of one of the specified states by the corresponding finite state machine.

[0143] Figure 3B is shown Figure 3ASystem diagram of the gateway, which indicates possible types of computer attacks on the components of the gateway 300 and the first network 310 by an attacker 390 from the second network 350. For example, the gray filling indicates tools and modules that may be attacked and compromised by the attacker 390. The gray arrows indicate the attack vectors of the attacker, while the crosses indicate the attack vectors that are impossible when using the gateway 300 disclosed herein.

[0144] The attacker 390 can directly attack the destination server 351 or the second network 350. The attacker 390 can then attack the NIC driver 353 and the second I / O system 354 that handle all network requests from the second network 350. The attacker 390 can exploit various vulnerabilities in these components, perform DDoS attacks, perform unauthorized access, etc. It should be noted that by differentiating the components of the gateway 300 related to the first network 310 and the second network 350, security policies for each component of the gateway 300 can also be used to improve the overall security of the gateway 300. In one aspect, a security policy can be used to restrict the second NIC driver 353 that accesses devices on the second network 350. For example, the security policy can only allow access to the destination server 351. Even if the specified second NIC driver 353 is compromised, based on the security policy in the policy database 121, the security monitor 120 may not allow the second NIC driver 353 to obtain access to other devices in the second network 350.

[0145] Therefore, after obtaining access to the second I / O system 354, the attacker 390 can continue to perform network attacks on the destination proxy 355. However, the attacker 390 cannot attack either the data processing service 316 or the source proxy 315, or the first VFS 317 and the trusted memory 331. The attacker 390 cannot initiate an attack because the gateway 300 may be in an operating state that denies the destination proxy 355 access to the source proxy 315 and the trusted memory 331. It should be noted that when the gateway 300 has just started and is in a "secure" state, the destination proxy 355 can be considered trusted and the destination proxy 355 can be denied access to the second network 350. Therefore, in the "secure" state of the gateway 300, the attacker 390 cannot compromise the destination proxy 355 and initiate network attacks on other components of the gateway 300.

[0146] Meanwhile, in the "working" state of the gateway 300, an attacker 390 who has compromised the destination agent 355 can launch attacks on the second VFS 356 and the untrusted memory 332. However, the attacker 390 cannot compromise the data storage drive 320 and thus cannot obtain access to the trusted memory 331. The data storage drive 320 can be protected by the fact that a specific drive is considered a trusted component of the gateway 300 due to the limited functions of the data storage drive 320 and can thus be verified to eliminate errors and vulnerabilities. However, on the one hand, the gateway 300 can include two data storage drives, where one data storage drive can provide the first VFS 317 access to the trusted memory, while the second data storage drive can provide the second VFS 356 access to the untrusted memory 332.

[0147] Regarding possible attacks by the attacker 390 directly on the gateway 300 and the first network 310, the architecture of the gateway 300 can prevent such attacks. The data source 311 can be associated with the source agent 315 through a data transfer protocol (e.g., OPC UA) that can allow data authorization. Thus, data cannot be transferred from an unauthorized data source other than the data source 311. Additionally, if the gateway 300 is within the secure perimeter of an industrial information system, this eliminates the possibility of a physical attack on the components of the gateway 300 (e.g., connecting an unauthorized device (e.g., a flash card) to the gateway 300).

[0148] Therefore, aspects of the present invention can solve the technical problem of the low level of protection of the first network against network attacks from the second network. Additionally, aspects of the present invention allow for the achievement of the stated technical results. These technical results can include enabling one-way data transfer from the first network 310 to the second network 350, strengthening the protection of the first network 310 against network attacks from the second network 350, and strengthening the protection of the gateway against network attacks from the second network 350.

[0149] Figure 4 is an example of a flowchart showing a method for transferring data from a first network to a second network.

[0150] In step 410, the security monitor 120 can be used to set the status of the gateway 300 to "secure". In step 420, the security monitor 120 can provide access to the trusted memory 331 according to a request from the destination agent 355. In one aspect, the enforcement requirements of the security policy from the policy database 121 can be checked. Next, in step 430, the security monitor 120 or the destination agent 355 can be used to configure the destination agent 355 based on the parameters of the destination agent 355 from the trusted memory 331, particularly the authorization parameters for transmitting data to the second network 350. After configuring the destination agent 355, in step 440, the security monitor 120 can change the status of the gateway 300 to "operational".

[0151] As a result, in step 450, data from the first network 310 is transmitted from the data source 311 to the second network 350 and reaches the data destination server 351 by going from the source agent 315 to the destination agent 355. The data transmission can be controlled by the security monitor 120 when the security policy from the policy database 121 is enforced and the configuration result of the destination agent 355 is taken into account. In this case, the destination agent 355 can use the untrusted memory 332 to perform the above data transmission. The untrusted memory 332 can include the service information of the destination agent 355. It should be noted that the specific aspects described above for Figure 3A the gateway 300 in Figure 4 also apply to the method of transmitting data from the first network 310 to the second network 350 as shown in

[0152] Figure 5 An example of a computer system is shown on which different aspects of the systems and methods disclosed herein can be implemented. The computer system 20 can represent Figure 1A the security monitor 120, and can be in the form of multiple computing devices, or can also be in the form of a single computing device, such as a desktop computer, a laptop computer, a notebook computer, a mobile computing device, a smart phone, a tablet computer, a server, a host, an embedded device, and other forms of computing devices.

[0153] As shown, the computer system 20 includes a central processing unit (CPU) 21, a system memory 22, and a system bus 23 that connects various system components, including the memory associated with the central processing unit 21. The system bus 23 can include a bus memory or a bus memory controller, a peripheral bus, and a local bus that can interact with any other bus architecture. Examples of buses can include PCI, ISA, serial bus (PCI-Express), HyperTransport TM(HyperTransport TM ), InfiniBand TM (InfiniBand TM ), Serial ATA, I 2 C, and other suitable interconnections. The central processing unit 21 (also referred to as a processor) may include a single set or multiple sets of processors with single-core or multi-core. The processor 21 may execute one or more computer-executable codes implementing the techniques of the present invention. The system memory 22 may be any memory for storing data used herein and / or computer programs executable by the processor 21. The system memory 22 may include volatile memory (such as random access memory (RAM) 25) and non-volatile memory (such as read-only memory (ROM) 24, flash memory, etc.) or any combination thereof. The basic input / output system (BIOS) 26 may store basic programs for transmitting information between elements of the computer system 20, such as those basic programs when loading an operating system using the ROM 24.

[0154] The computer system 20 may include one or more storage devices, such as one or more removable storage devices 27, one or more non-removable storage devices 28, or a combination thereof. The one or more removable storage devices 27 and the one or more non-removable storage devices 28 are connected to the system bus 23 through a memory interface 32. In one aspect, the storage devices and the corresponding computer-readable storage media are power-independent modules for storing computer instructions, data structures, program modules, and other data of the computer system 20. The system memory 22, the removable storage devices 27, and the non-removable storage devices 28 may use a variety of computer-readable storage media. Examples of computer-readable storage media include: machine memory, such as cache, SRAM, DRAM, zero-capacitor RAM, dual-transistor RAM, eDRAM, EDO RAM, DDR RAM, EEPROM, NRAM, RRAM, SONOS, PRAM; flash memory or other storage technologies, such as in a solid state drive (SSD) or a flash drive; magnetic tape cartridges, tapes, and disk memories, such as in a hard disk drive or a floppy disk; optical memories, such as in a compact disc (CD-ROM) or a digital versatile disc (DVD); and any other medium that can be used to store the desired data and can be accessed by the computer system 20.

[0155] The system memory 22, removable storage device 27, and non-removable storage device 28 of the computer system 20 can be used to store an operating system 35, additional application programs 37, other program modules 38, and program data 39. The computer system 20 can include a peripheral interface 46 for conveying data from an input device 40, such as a keyboard, mouse, stylus, game controller, voice input device, touch input device, or other peripheral devices, such as a printer or scanner via one or more I / O ports, such as a serial port, parallel port, Universal Serial Bus (USB), or other peripheral interface. A display device 47 (such as one or more monitors, projectors, or integrated displays) can also be connected to the system bus 23 via an output interface 48 (such as a video adapter). In addition to the display device 47, the computer system 20 can also be equipped with other peripheral output devices (not shown), such as speakers and other audio-visual devices.

[0156] The computer system 20 can operate in a network environment using a network connection with one or more remote computers 49. The one or more remote computers 49 can be local computer workstations or servers that include most or all of the elements described previously in connection with the nature of the computer system 20. Other devices can also exist in the computer network, such as, but not limited to, routers, web sites, peer devices, or other network nodes. The computer system 20 can include one or more network interfaces 51 or network adapters for communicating with the remote computers 49 via one or more networks, such as a computer Local-Area Network (LAN) 50, a computer Wide-Area Network (WAN), an intranet, and the Internet. Examples of network interfaces 51 can include an Ethernet interface, a Frame Relay interface, a SONET (Synchronous Optical Network) interface, and a wireless interface.

[0157] Aspects of the present invention can be a system, a method, and / or a computer program product. The computer program product can include one or more computer-readable storage media having computer-readable program instructions thereon for causing a processor to execute aspects of the present invention.

[0158] A computer-readable storage medium can be a tangible device that can hold and store program code in the form of instructions or data structures that can be accessed by a processor of a computing device, such as computer system 20. The computer-readable storage medium can be an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. By way of example, such computer-readable storage media can include random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD), flash memory, hard disk, portable computer diskette, memory stick, floppy disk, or even a mechanical encoding device, such as a punched card or raised structure in a groove having instructions recorded thereon. As used herein, a computer-readable storage medium should not be construed as a transient signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or transmission medium, or an electrical signal transmitted through a wire.

[0159] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing device, or downloaded to an external computer or external storage device via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network). The network can include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network interface in each computing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the respective computing device.

[0160] The computer-readable program instructions for performing the operations of the present invention may be assembly instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state-setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages and conventional procedural programming languages. The computer-readable program instructions, as a stand-alone software package, may be executed entirely on the user's computer, partly on the user's computer, partly on the user's computer and partly on a remote computer, or entirely on the remote computer or server. In the latter case, the remote computer may be connected to the user's computer through any type of network, including a LAN or a WAN, or may make a connection to an external computer (e.g., through the Internet). In some embodiments, an electronic circuit, including, for example, a programmable logic circuit, a field-programmable gate array (FPGA), or a programmable logic array (PLA), may execute the computer-readable program instructions by utilizing the state information of the computer-readable program instructions to personalize the electronic circuit so as to perform aspects of the present invention.

[0161] In various aspects, the systems and methods described in the present invention may be processed in terms of modules. As used herein, the term "module" refers to, for example, a real-world device, component, or arrangement of components implemented using hardware (e.g., via an application-specific integrated circuit (ASIC) or an FPGA), or refers to a combination of hardware and software, such as a combination implemented by a microprocessor system and an instruction set that implements the functions of the module, which, when executed, transforms the microprocessor system into a dedicated device. A module may also be implemented as a combination of two modules, where certain functions are facilitated separately by hardware and other functions are facilitated by a combination of hardware and software. In certain implementations, at least a portion of a module (and in some cases, the entire module) may run on a processor of a computer system. Thus, each module may be implemented in a variety of suitable configurations and should not be limited to any particular implementation illustrated herein.

[0162] For clarity, not all routine features of all aspects are disclosed herein. It should be appreciated that in the development of any actual implementation of the present invention, numerous specific implementation decisions must be made in order to achieve the specific goals of the developer, and such specific goals will vary for different implementations and different developers. It should be understood that such development efforts would be complex and time-consuming, but would still be routine engineering tasks for those of ordinary skill in the art who understand the advantages of the present invention.

[0163] In addition, it should be understood that the phrases or terms used herein are for descriptive and not limiting purposes, so that the terminology or phraseology of this specification should be interpreted by those of ordinary skill in the art in light of the teachings and guidance presented herein, in combination with the knowledge of those of ordinary skill in the relevant art(s). Further, no term in this specification or claims is intended to be accorded an uncommon or special meaning unless expressly set forth as such.

[0164] Each aspect disclosed herein includes presently known and future known equivalents of the known modules recited herein in illustrative fashion. Additionally, while various aspects and applications have been shown and described, it will be apparent to those of ordinary skill in the art who have appreciated the advantages of the present invention that many more modifications are possible without departing from the inventive concepts disclosed herein than are mentioned above.

Claims

1. A method for transferring data from a first network to a second network using a gateway, the method comprising: setting, by a security monitor, a state of the gateway to a first state, the first state indicating to a destination proxy that access to a trusted memory is permitted and access to the second network and an untrusted memory is denied; when the gateway is in the first state, configuring, by the security monitor, the destination proxy based on one or more parameters stored in the trusted memory, wherein the destination proxy is configured to transfer data received from a source proxy to the second network, and the source proxy is configured to receive data to be transferred from the first network; changing, by the security monitor, the state of the gateway to a second state, the second state indicating to the destination proxy that access to the trusted memory is denied and access to the second network and the untrusted memory is permitted; and when the gateway is in the second state, controlling, by the security monitor, data transfer from the source proxy in the first network to the destination proxy in the second network, wherein the destination proxy uses the untrusted memory to perform the data transfer.

2. The method according to claim 1, wherein The first state includes a "secure" state and the second state includes a "working" state.

3. The method according to claim 1, wherein, The second state further indicates that data transfer from the source proxy to the destination proxy is allowed and data transfer from the destination proxy to the source proxy is prohibited.

4. The method according to claim 1, wherein, Performing the data transfer based on the one or more parameters of the destination proxy stored in the trusted memory.

5. The method according to claim 1, wherein, Changing, by the security monitor, the state of the gateway to the second state further includes, after the configuration of the destination proxy is completed, changing, by the security monitor, the state of the gateway to the second state.

6. The method according to claim 1, wherein, The one or more parameters of the destination proxy stored in the trusted memory include one or more authorization parameters for transferring data to the second network.

7. The method according to claim 1, wherein, The one or more parameters of the destination proxy stored in the trusted memory include a list of data to be transferred from the first network to the second network.

8. The method according to claim 5, wherein, Configuring the destination proxy further includes: creating one or more rules to filter received data based on the one or more parameters of the destination proxy, and using the one or more rules to subsequently transfer only the filtered data from the first network to the second network.

9. The method according to claim 1, wherein The untrusted memory contains a buffer for storing data to be transferred and also contains service information related to the destination proxy.

10. The method according to claim 1, wherein, Controlling, by the security monitor, the data transfer further includes controlling, by the security monitor, communication between one or more resources according to one or more predefined security policies, wherein controlling the communication includes permitting or denying access of one resource to another resource, and wherein the one or more resources include: the destination proxy, the source proxy, the trusted memory, and the untrusted memory.

11. The method according to claim 10, wherein, The one or more predefined security policies employ a finite state machine, wherein the state of the finite state machine represents the state of the gateway, and wherein the one or more predefined security policies determine whether to allow or deny access of one gateway component to another gateway component based on the state of the finite state machine and based on a state transition table of the finite state machine.

12. A system for transferring data from a first network to a second network using a gateway, the system comprising: The gateway, a security monitor, a source agent, and a destination agent, wherein a hardware processor of the security monitor is configured to: Set the state of the gateway to a first state, the first state indicating to the destination agent that access to a trusted memory is permitted and access to the second network and an untrusted memory is denied; When the gateway is in the first state, configure the destination agent based on one or more parameters stored in the trusted memory, wherein the destination agent is configured to transfer data received from the source agent to the second network, and the source agent is configured to receive data to be transferred from the first network; Change the state of the gateway to a second state, the second state indicating to the destination agent that access to the trusted memory is denied and access to the second network and the untrusted memory is permitted; and When the gateway is in the second state, control the transfer of data from the source agent in the first network to the destination agent in the second network, wherein the destination agent utilizes the untrusted memory to perform the data transfer.

13. The system according to claim 12, wherein, The first state includes a "secure" state and the second state includes an "operational" state.

14. The system according to claim 12, wherein, The second state further indicates that data transfer from the source agent to the destination agent is allowed and data transfer from the destination agent to the source agent is prohibited.

15. The system according to claim 12, wherein, Perform the data transfer based on the one or more parameters of the destination agent stored in the trusted memory.

16. The system according to claim 12, wherein, The one or more parameters of the destination agent stored in the trusted memory include one or more authorization parameters for transferring data to the second network.

17. The system according to claim 12, wherein, The one or more parameters of the destination agent stored in the trusted memory include a list of data to be transferred from the first network to the second network.

18. The system according to claim 15, wherein, The hardware processor configured to configure the destination agent is further configured to: create one or more rules to filter received data based on the one or more parameters of the destination agent, and utilize the one or more rules to subsequently transfer only the filtered data from the first network to the second network.

19. A non-transitory computer-readable medium having stored thereon computer-executable instructions for using a gateway to transfer data from a first network to a second network, the computer-executable instructions including instructions for: The security monitor sets the state of the gateway to a first state, and the first state indicates to the destination agent that access to the trusted memory is permitted and access to the second network and the untrusted memory is denied; When the gateway is in the first state, the security monitor configures the destination agent based on one or more parameters stored in the trusted memory, wherein the destination agent is configured to transfer data received from the source agent to the second network, and the source agent is configured to receive data to be transferred from the first network; The security monitor changes the state of the gateway to a second state, and the second state indicates to the destination agent that access to the trusted memory is denied and access to the second network and the untrusted memory is permitted; and When the gateway is in the second state, the security monitor controls the data transfer from the source agent on the first network to the destination agent on the second network, wherein the destination agent uses the untrusted memory to perform the data transfer.

20. The non-transitory computer-readable medium of claim 19, wherein, The first state includes a "secure" state, and the second state includes an "operational" state.

Images