Method and system for providing applications for computer controlled components

Abstract

The invention relates to a method and a test environment for providing an application for a computer-controlled component, wherein the application is provided to the component after the application is created using an application memory. Before providing the application, the application is executed in the test environment, a first data set representing characteristics is formed when the application is executed in the test environment by interactions that are used or registered via the test environment during the execution of the application, the first data set belonging to the application is provided by the application memory, and when the application is executed in the execution environment of the component, a second data set representing characteristics is formed at least temporarily via interactions of the application that are used there or registered via the execution environment, and the first data set representing characteristics and the second data set are compared with each other. By means of the method, it is firstly possible to ensure that the application complies with predefined criteria in terms of its runtime behavior, and it is also possible to ensure that the permitted behavior pattern of the application determined during the certification of the application in the test run does not deviate significantly even in the continuous run (forward run).

Description

Technical Field

[0001] The present invention relates to a method for providing an application for a computer-controlled component and a test environment for providing an application for a computer-controlled component. Background Art

[0002] An application is software that can be executed by a computer, and such applications, in particular for industrial applications and similar applications, are increasingly being offered by so-called application stores, which are program servers (libraries) that usually come from a plurality of providers and store applications and make them available for “downloading”. A common application scenario for such application stores is the provision of applications for so-called edge devices or industrial edge devices, which are located at the interface between an automation network and an open data network (usually the Internet) and which, on the one hand, provide computing power for data processing in the automation network and, on the other hand, enable the exchange of usually pre-processed data between the automation network and an open network, in particular the so-called “cloud”.

[0003] Edge devices, ie components for executing applications, are usually provided for executing multiple applications simultaneously, which is usually achieved with the aid of container visualization, in particular by processing containers of so-called Docker software.

[0004] Compared to traditional closed and encapsulated automation environments, which are usually projected and programmed "single-handedly" by a single operator, the application stores (app stores) in today's systems offer applications from a large number of suppliers, which makes it more difficult to control the data security and similar aspects of the applications. In addition, the connection of components, especially edge devices, to open networks (Internet, cloud) increases the risk of unauthorized access and data transmission.

[0005] Therefore, applications should comply with defined security requirements and data handling rules (so-called "policies"), i.e., in applications (Apps) provided by an application memory, it should be ensured that before delivery (provided via the application memory) a check is made as to whether all components of the application are free of known security vulnerabilities and whether they firstly match the preset policies, i.e. data access rules, communication interfaces, connected peripherals and the like.

[0006] It is known that applications, in particular so-called "Docker images", that is to say encapsulated packages or "containers", are checked and audited for security holes in the libraries used. This means that when using checked runtime libraries and the like, the applications generated in this way are generally considered to be problem-free. However, it is obvious that the use of authenticated libraries and the like does not actually ensure that the application does not perform unauthorized accesses. Summary of the invention

[0007] The object of the present invention is therefore to check and, in particular, also to ensure, during runtime, the compliance with regulations of an application for an industrial component.

[0008] The core idea of ​​the solution according to the invention for this purpose is to run or execute the application in a specific test environment before release (provision to production operation), and generate a fingerprint or the like of the behavior pattern and data access, and store this fingerprint or the like together with the application in the application memory. As a result, the data access pattern of the new application is known, wherein it can also be checked more precisely during this test cycle in terms of its adaptation to the predefined rules / guidelines. The core idea of ​​the solution also provides that a new fingerprint or the like is formed in a corresponding manner during runtime, i.e. in the production operation of the application, and the fingerprints or the like generated in the test operation and in the production operation are compared with each other, so that potential intrusions (from the outside) or erroneous behaviors (application itself) can be detected and reported. As an alternative to reporting, automatic termination or other pre-programmed reactions can obviously also be carried out. By determining the permissible degree of deviation between the fingerprints or the like, different sensitivities of the identification can be determined according to the purpose of use of the application. In this case, other permissible deviations between the fingerprints can also be defined for different aspects of the check (e.g. access to the working memory, access to the network interface or other communication device, access to the data point of the connected control device, etc.).

[0009] In particular, the solution to this object proposes a method and a test environment according to the invention.

[0010] A method for providing an application for a computer-controlled component, in particular an industrial edge device, is proposed, wherein after the application is created, the application is provided to the component by means of an application memory, in particular by means of an application store. Before providing the application, the application is executed in a test environment, wherein when the application is executed in the test environment, a first characteristic data set, in particular a fingerprint, a hash value, a configuration file or a feature table, is formed by interactions registered by means of the test environment during the execution of the application, wherein the first data set assigned to the application is provided by means of the application memory, wherein the application and the first data set are transferred to the component for the execution of the application, wherein during the execution of the application on the component, a second characteristic data set is formed at least temporarily by means of the interactions of the application registered by means of the execution environment at the component, wherein the first characteristic data set and the second characteristic data set are compared with each other, wherein if the first characteristic data set and the second characteristic data set deviate from each other by more than a predefined amount, a fault is reported and / or the execution of the application is stopped. This method makes it possible to ensure firstly that the application complies with predefined criteria with regard to its runtime behavior and secondly to ensure that the permitted behavior pattern of the application determined during certification of the application in a test run does not deviate significantly even in continuous operation (forward operation).

[0011] In addition, the solution for this purpose proposes a test environment for providing an application for a computer-controlled component, in particular an industrial edge device, wherein the test environment includes a packaged execution environment, in particular a so-called sandbox, for the test run of the application. In this case, the test environment is equipped with a monitoring device for registering the interaction of the application with or via the test environment, wherein the monitoring device is configured to form a first characteristic data set, in particular a (digital) fingerprint, a hash value, a configuration file or a feature table from the registered interaction, and wherein the test environment is configured to transfer the application and the first characteristic data set to an application memory after the test run of the application and after the first characteristic data set has been created. With this test environment, the advantages already discussed with respect to the method can be achieved.

[0012] The features described here and their advantages also apply expediently to the test environment according to the invention. Advantageous variants can be implemented not only individually but also in expedient combinations with one another.

[0013] In an advantageous embodiment, the test environment is an encapsulated execution environment, in particular a so-called sandbox, since in such an execution environment the access to memory cells, registers, services, etc. can be particularly well controlled, registered and traced. In this case, it is particularly easy to determine whether an impermissible interaction (e.g. access to external data or the like) takes place or does not take place. In particular, the test environment can also be a virtual machine, which simulates the component (execution environment) and its peripherals accessible by the application. It is thus possible to test and, if possible, certify applications for different target systems (personal computers, edge devices, industrial control devices, human-machine interface devices, embedded systems and the like) using the same test environment, i.e. a "universal" hardware platform, by simply instantiating a suitable virtual machine.

[0014] In an advantageous embodiment, the characterizing data set should be as small as possible in order to simplify processing, but on the other hand react to the type and / or frequency of access to the data of the industrial automation components or other peripherals connected to the component in order to ensure that undesired interactions are distinguished from permitted interactions. For this purpose, it is advantageously provided that the interactions and other accesses are divided into access levels and the formation of the fingerprint or the characterizing data set is adjusted separately according to the importance or vulnerability of the respective access level, and the permitted deviations are also defined in each case. Subsequently, the overall characterizing data set is advantageously formed from the sub-data sets of the respective access levels.

[0015] Advantageously, the first characteristic data set is stored together with the application in an application memory or is at least connected or associated with the application to enable joint access. Advantageously, the first characteristic data set is protected against manipulation by means of a digital certificate. In an advantageous variant, the digital certificate also extends to the application, so that the application and the first characteristic data set together form an inseparable, manipulation-proof unit. Advantageously, the integration of the application and the characteristic data set can be checked by means of a public key infrastructure.

[0016] Advantageously, information about the type and size of the interaction to be registered and about special considerations for the first and second data sets for this interaction are connected to the first data set representing the characteristics. This can be achieved, for example, according to special rules (for example as XML data) or by indicating version criteria for forming the data set or fingerprint or hash value. The advantage is that it is ensured that the first and second data sets are respectively created according to the same rules and criteria, which is the basic premise for the subsequent comparison of the results. In addition, the first data set can also contain information about interactions, data accesses and the like that are allowed or not allowed or even possibly specified (blacklist, whitelist), so that incorrect behaviors can be detected safely and quickly. This is achieved by automatically closing the corresponding ports, interfaces and the like on the component side, i.e. the test environment side in production operation, from the beginning, according to the type of firewall that provides additional data security. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] An exemplary embodiment of the method according to the present invention is described below with reference to the accompanying drawings. The accompanying drawings are also suitable for describing the test environment according to the present invention.

[0018] Figure 1 The schematic diagram shows a network which has an application memory, an authentication device, a development system for the application and a component as an execution environment for executing the application in production operation. DETAILED DESCRIPTION

[0019] Figure 1 A development environment EU, i.e. a workstation for developing software, is shown. An engineering system ENG is run in the development environment EU, with which an application APP1 is created. In the present case, the application APP1 is software for an industrial edge device, which is shown in the figure as a component K of a target system for the application APP1. In the present embodiment, the application APP1 is configured to collect production data of a programmable logic controller that can exchange data with the component K, to evaluate it statistically, and to transmit it to an external SCADA (Supervisory Control and Data Acquisition) system. However, the industrial control devices and the SCADA system are not shown in the figures for reasons of simplicity.

[0020] The figure also shows a test environment CE (certification environment), which in principle consists of a server, on which different test environments BOX1 and BOX2 are instantiated, wherein the test environments BOX1 and BOX2 are virtual machines in the current instance, and the test environment BOX1 simulates the so-called Docker engine, wherein the Docker engine corresponds to the runtime environment RT of the component K. In addition, the industrial control device as a data source is also simulated in the same way, just as the actual industrial control device represents the data source for the component K. In addition, the test environment BOX1 is also designed to simulate a data receiver according to the described SCADA system. In an alternative embodiment, the test environments BOX1 and BOX2 can also be placed in an actual environment, that is, connected to an actual control device, etc. This scenario is also referred to as "HIL" (Hardware-in-the-loop).

[0021] Accordingly, the application APP1 is a so-called Docker container, which runs in the runtime environment RT in production operation, but is executed in the test environment BOX1 for testing and certification. The test environment BOX1 also includes a logging function UE1 (monitoring engine), with which the data exchanges of the application APP1 can also be recorded and evaluated during its operation in the test environment BOX1 using simulated data sources and data receivers. In addition, the logging function UE1 is configured to form a first data set EDS1 representing characteristics via the registered interactions of the application APP1 (i.e. access to data sources, transmission to data receivers, internal memory accesses, library calls, access to (simulated) hardware resources, etc.), connect it to the application APP1, and transmit it to the application memory REP (library) after the test and certification have been completed.

[0022] The application store REP represents a so-called application store in the overall system shown, with which applications APP1, ..., APPn can be provided for component K and other components. It is pointed out here that other components can also be of other types and various "suppliers" can provide various applications APP1, ..., APPn for payment, if possible.

[0023] As already explained, the component K displays a plurality of runtime environments RT for running so-called Docker containers, of which only one runtime environment RT is shown. The runtime environment RT includes or has access to a second monitoring device UEK, which is created in a similar manner or in the same way as the monitoring device UE1 of the test environment BOX1. In this case, the monitoring device UEK is connected to a comparison device VE, which is configured to compare a first characteristic data set EDS1 with a second characteristic data set (not shown) generated by the monitoring device UEK during production operation of the application APP1. However, the comparison device VE is programmed in this case so that in the event of a manageable significant deviation of the characteristic data sets from one another, a warning is issued, the operation of the application APP1 is stopped or another pre-programmed reaction is implemented.

[0024] The comparison device VE can also perform other control functions, in particular it can receive and take into account a preset blacklist or a preset whitelist (or both) using the characteristic first data set EDS1 or in another type and manner, wherein the blacklist specifies interactions of the application APP1 that are never allowed to be executed and the whitelist specifies interactions that are allowed to be executed at least once or at regular time intervals or under certain conditions or even must be executed, for example invoking a so-called watchdog function or the like.

[0025] The usual workflow in the system shown thus results from the initial programming of the application APP1 using the development system ENG. In this case, a blacklist or a whitelist can also be optionally defined. In addition, it is possible to define the permitted interaction modes during development or at other points in time and by other systems or other workstations, i.e., to define which data points of the underlying programmable logic controller are allowed to access the application for how long and in what manner, which parameters are allowed to be transmitted to the data receiver, which storage areas or information are allowed to be accessed (and also in what type or with what frequency), etc. All the information mentioned in the latter part is provided to the monitoring device UE of the test environment BOX1, based on which the operation of the application APP1 in the virtual machine VM1 formed there in the test environment BOX1 is started. The monitoring device UE1 includes an algorithm, which forms a first characteristic data set EDS1 from the registered interactions of the application APP1 during the test operation or certification operation. In this case, a check value is generated from each registered and monitored interaction at least in the first call-up, which is supplemented with a hash value or a key with other check values. Of course, the frequency of the call-ups, the target of the call-ups or interactions and the like can also have an influence on the formed first characteristic data set EDS1. In this case, the registered interactions are displayed on a separate workstation, so that the test engineer can determine whether only permitted interactions are run or also impermissible interactions, whereby in the latter case the application APP1 is returned for modification.

[0026] After a successful test, the application APP1 and the generated first data set EDS1 are linked to one another to form an archive file, which is authenticated with a digital key so that the storage of the data packets can be traced later, and which is transferred to the application memory REP and thus provides the application. This archive file or container is transferred to the component K for its use, wherein the part with the application APP1 is taken over in production mode in the runtime environment RT and the first characteristic data set EDS1 of the comparison device VE is provided, wherein the part of the first characteristic data set EDS1 is supplied to the second monitoring device UEK, which part indicates the interaction to be monitored and also indicates the algorithm according to which the second characteristic data set is to be formed. When the application APP1 is running in production operation, the interaction of the application APP1 with the "environment" (i.e. generally peripherals, communication connections, memory and the like), in particular with the underlying editable logic memory and / or receivers (such as SCADA systems) is monitored by the monitoring device UEK. In this case, a second characteristic data set is generated according to rules and transmitted at regular intervals to a comparison device VE, wherein it is checked in the comparison device VE whether the actual runtime behavior deviates significantly or insignificantly or does not deviate from the certified runtime behavior during operation in the test environment BOX1.

[0027] In one embodiment, information about runtime performance, i.e., registered interactions of application APP1, can be used to train a neural network, i.e., an artificial intelligence, wherein automatically generated feedback and / or feedback from monitoring workstations enables training of the neural network to be able to distinguish between permitted and impermissible interactions and behavior patterns.

[0028] The trained neural network can then be protected from further changes and, by means of provision, in particular by means of the application memory REP, can finally be made available to the monitoring device UEK in order to monitor the interaction, runtime behavior and access behavior of the application APP1 in production operation. In this variant, the comparison device VE is configured to receive and process reports, in particular warnings due to impermissible interactions, and to initiate a corresponding reaction (report, interruption, etc.).

Claims

1. A method for providing an application to a computer-controlled component, providing the application to the component after the application is created by means of an application memory having an application store, the method comprising: executing the application in a test environment by means of the application memory having the application store before providing the application to the computer-controlled component, before providing the application to the computer-controlled component, during execution of the application in the test environment, forming a first data set representative of characteristics by interactions registered during execution of the application with or via the test environment, providing the first data set, which is associated with the representation properties of the application, by means of the application memory with the application store, For executing the application, the application and the first characteristic data set are transmitted to the component in a runtime execution environment of the computer-controlled component, During execution of the application in the runtime execution environment of the component controlled by the computer, at least temporarily forming a second data set representative of characteristics via utilization of the application or via interactions registered via the runtime execution environment, and The first characteristic data set and the second characteristic data set are compared with each other and, if a deviation between the first characteristic data set and the second characteristic data set exceeds a preset amount, a fault is reported and / or runtime execution of the application is stopped.

2. The method according to claim 1, characterized in that The computer controlled components are industrial edge devices.

3. The method according to claim 1, characterized in that The first data set representing characteristics is a fingerprint, a hash value, a configuration file or a signature table.

4. The method according to any one of claims 1 to 3, characterized in that The packaged execution environment is used as the test environment.

5. The method according to claim 4, characterized in that The encapsulated execution environment is a sandbox.

6. The method according to any one of claims 1 to 3, characterized in that A virtual machine running on computer hardware is used for the test environment, wherein the component is simulated by the virtual machine.

7. The method according to any one of claims 1 to 3, characterized in that The type and / or frequency of access to data of indirectly or directly associated industrial automation components is respectively recorded by the application.

8. The method according to claim 7, characterized in that The industrial automation component is an industrial control device.

9. The method according to any one of claims 1 to 3, characterized in that The first characteristic data set is stored together with the application in the application memory, wherein the first characteristic data set and the application are transmitted to the component by a common transmission process.

10. The method according to any one of claims 1 to 3, characterized in that The first characteristic data set is protected against manipulation by means of a digital certificate.

11. The method according to any one of claims 1 to 3, characterized in that Information about the type and / or size of the interaction to be registered and about the considerations of the interaction to be registered for the first and second data sets is connected to the first characteristic data set.

12. The method according to any one of claims 1 to 3, characterized in that The first characteristic data set comprises information about impermissible interactions.

13. The method according to claim 12, characterized in that The information about the impermissible interaction is information about the impermissible access to functions or data of the component and / or of a peripheral device connected to the component.

14. A system for providing an application for a computer-controlled component, the system comprising: a test environment for providing an application to a computer-controlled component, the test environment comprising a packaged execution environment for trial running of the application, the test environment further comprising first monitoring means for registering interactions of the application using or via the test environment before providing the application to the computer-controlled component, the first monitoring means being arranged to form a first data set representing characteristics from the registered interactions, an application store having an application store, said application store providing said application to said computer-controlled component after said application is created, second monitoring means for forming a second data set representing characteristics at least temporarily during the execution of the application in a runtime execution environment of at least one computer-controlled component via utilization of the application or via interactions registered by the runtime execution environment of at least one computer-controlled component, and a comparison device for comparing the first characteristic data set and the second characteristic data set with each other and reporting a fault and / or stopping the runtime execution of the application if the deviation between the first characteristic data set and the second characteristic data set exceeds a preset amount, Therein, the test environment is configured to transfer the application and the first characteristic data set to the application memory having the application store after a test run of the application and after the formation of the first characteristic data set.

15. The system according to claim 14, characterized in that The computer controlled components are industrial edge devices.

16. The system according to claim 14, characterized in that The encapsulated execution environment is a sandbox or a virtual machine.

17. The system according to claim 14, characterized in that The first data set representing characteristics is a fingerprint, a hash value, a configuration file or a signature table.

Images