METHOD AND TEST ENVIRONMENT FOR DELIVERING AN APPLICATION FOR A COMPUTER-CONTROLLED COMPONENT

Description

[0001] The invention relates to a method for providing an application for a computer-controlled component according to the preamble of patent claim 1, and to an arrangement for providing an application for a computer-controlled component according to the preamble of patent claim 9.

[0002] Application programs, i.e., computer-executable software, especially those for industrial applications and the like—in short, applications—are increasingly offered via so-called app stores. These are program servers ("repositories") that typically store applications from a variety of providers and make them available for download. 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 a public data network (usually the Internet). These devices, on the one hand, provide computing power for data processing in the automation network and, on the other hand, facilitate the exchange of mostly preprocessed data between the automation network and the public network, especially a so-called "cloud."

[0003] Often, the edge devices, i.e. the components for executing the applications, are set up to run multiple applications simultaneously, which is commonly achieved using container virtualization, in particular by processing so-called Docker containers.

[0004] In contrast to traditional, self-contained, and encapsulated automation environments, which are often designed and programmed by a single operator from a single source, applications from numerous providers are made available via application stores in today's systems, making it difficult to monitor applications with regard to data security and other issues. Further complicating the situation is the increased risk of unauthorized access and data transmission due to the connection of components, especially edge devices, to the public network (internet, cloud).

[0005] The applications should therefore be subject to defined security requirements and data processing guidelines (so-called "policies"), i.e., an application ("app") made available via the application store should be checked before delivery (making available via the application store) to determine whether all components of the application are safe with regard to known security leaks and, above all, whether they comply with specified policies, i.e. access rules for data, communication interfaces, connected peripherals, and the like.

[0006] It is known that applications, especially so-called "Docker image files," i.e., encapsulated program packages or "containers," are tested for security vulnerabilities and qualified with regard to the libraries used. This means that, to a rough approximation, it is assumed that the application created using tested runtime libraries and the like is safe. Of course, the use of certified libraries and the like does not necessarily guarantee that the application will not perform unauthorized access.

[0007] The publication US 20190156023 A1 - Gerebe et al. "SYSTEM FOR SECURING SOFTWARE CONTAINERS WITH EMBEDDED AGENT" proposes protecting the integrity of containers with applications using a content-based cryptographic fingerprint.

[0008] It is therefore an object of the present invention to check the rule-compliant behavior of applications for industrial components and, above all, to ensure this at runtime.

[0009] A core idea of ​​the inventive solution to this problem is that an application is operated or executed in a special test environment before publication (preparation for production operation), and that a fingerprint or similar of the behavior pattern and data access is generated, and this fingerprint or similar is stored with the application in the application memory. This means that the data access patterns of the new application are known, and these can also be checked more precisely during this test cycle with regard to their conformity to predetermined rules / policies. The core idea of ​​the solution further provides that at runtime, i.e. during production operation of the application, a new fingerprint or similar is created in a corresponding manner, and that the fingerprint or similar generated during test operation and the fingerprint or similar generated during production operation are compared with each other so that potential attacks (from outside) orMalfunctions (of the app itself) can be detected and reported. Instead of a notification, automatic shutdown or another preprogrammed response can of course also occur. By specifying a degree of permissible deviation between the fingerprints, or similar, a different detection sensitivity can be defined depending on the application's intended use. Different permissible deviations between the fingerprints can also be defined for different aspects of the test, for example, for access to the main memory, access to network interfaces or other communication media, access to data points of connected controllers, etc.

[0010] The solution to the problem provides in particular a method according to patent claim 1 and a test environment according to patent claim 9.

[0011] A method for providing an application for a computer-controlled component, in particular for an industrial edge device, is proposed. After its creation, the application is provided for the component via an application store, in particular via an app store. Before its provision, the application is executed in a test environment. During the execution of the application in the test environment, a first characteristic data set, in particular a fingerprint, a hash value, a profile file, or a feature table, is created via interactions with or via the test environment registered during the execution of the application. The interactions are each accesses to memory cells, registers, or services. The first data set is provided via the application store, assigned to the application. For the execution of the application, this data set and the first data set are transferred to the component.During the execution of the application on the component, a second characteristic data set is created, at least temporarily, about the interactions of the application with or via the execution environment recorded there. The first and second characteristic data sets are compared with each other. If the data sets deviate from each other by more than a predetermined amount, a malfunction is reported and / or the application's execution is stopped. This method can ensure, on the one hand, that an application meets predetermined criteria with regard to its runtime behavior, and, on the other hand, that the permitted behavior patterns of the application determined in test operation during application certification do not deviate significantly during ongoing operation (positive operation).

[0012] The solution to the problem also provides an arrangement with a test environment for providing an application for a computer-controlled component, in particular for an industrial edge device, and with a component with an execution environment for executing the application, wherein the test environment comprises an encapsulated execution environment, in particular a so-called sandbox, for test-based execution of the application.The test environment is equipped with a monitoring device for registering interactions of the application with or via the test environment, wherein the interactions are each accesses to memory cells, registers or services, wherein the monitoring device is configured to form a first characteristic data set, in particular a (digital) fingerprint, a hash value, a profile file or a feature table, from the registered interactions, and wherein the test environment is configured to transfer the application and the first characteristic data set to an application memory after the test execution of the application and after the creation of the first characteristic data set.For this purpose, the component is configured to create a second characteristic data set based on the application's interactions with or via the execution environment (RT) recorded therein. The first and second characteristic data sets are compared with each other. If the data sets deviate from each other by more than a predetermined amount, a malfunction is reported and / or the application's execution is stopped. This test environment allows the benefits already discussed with reference to the method to be achieved.

[0013] Advantageous embodiments of the method according to the invention are specified in the dependent patent claims. The features described therein and their advantages also apply mutatis mutandis to the test environment according to the invention. The advantageous variants can be implemented both individually and in appropriate combinations with one another.

[0014] In an advantageous embodiment, the test environment is an encapsulated runtime environment, in particular a so-called sandbox, because in such execution environments, access to memory cells, registers, services, etc., can be particularly well controlled, registered, and traced. In particular, it is easy to determine whether unauthorized interactions, such as access to external data or the like, occur. The test environment can also be a virtual machine that replicates the component (execution environment) and its peripherals accessible by the application. This makes it possible to test and, if necessary, certify applications for different target systems (personal computers, edge devices, industrial controllers, HMI devices, embedded systems, and the like) using one and the same test environment, i.e., a "generic" hardware platform, by simply instantiating a suitable virtual machine.

[0015] In an advantageous embodiment, the characteristic data set should be as small as possible to simplify handling, but at the same time reflect the type and / or frequency of accesses to data of an industrial automation component connected to the component or another peripheral in such a way that unwanted interactions can be reliably distinguished from permitted interactions. For this purpose, it is advantageous to divide interactions and other accesses into access classes and, depending on the importance or vulnerability of an individual access class, to configure the generation of the fingerprint or the characteristic data set separately, as well as to define a permitted deviation for each. The entire characteristic data set is then advantageously created from the partial data sets of the individual access classes.

[0016] Advantageously, the first characteristic data set is stored together with the application in the application memory, or at least linked or connected to the application in such a way that shared access is possible. Advantageously, the first characteristic data set is protected against manipulation and the like 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, tamper-proof unit. Advantageously, the integrity of the application and the characteristic data set can be verified using a public key infrastructure.

[0017] Advantageously, the first characteristic data set is linked to information about the type and scope of the interactions to be recorded and about the specific consideration of these interactions for the first and second data sets. This can be done, for example, using explicit rules (e.g., as an XML file) or by specifying a versioning rule for the creation of the data set, fingerprint, or hash value. This has the advantage of ensuring that the first data set and the second data set are each created according to the same rules and regulations, which is a prerequisite for later comparison of the results. Furthermore, the first data set can also contain information ("blacklist," "whitelist") about permitted or prohibited, or possibly even required, interactions, data access, and the like, so that misconduct can be detected more reliably and quickly.This also makes it possible to automatically block corresponding ports, interfaces, and the like on the part of the component, i.e. the test environment in production operation, like a firewall, which offers additional data security.

[0018] An exemplary embodiment of the method according to the invention is explained below with reference to the drawing. It also serves to explain a test environment according to the invention.

[0019] The single figure shows a schematic representation of a network with an application store, a certification facility, a development system for applications and a component as an execution environment for executing the application in productive operation.

[0020] The figure shows a development environment EU, i.e., a workstation for software development. An engineering system ENG runs in the development environment EU, which is used to create an application APP1. In this case, the application APP1 is software for an industrial edge device, which, in the figure, forms the target system for the application APP1 as component K. In the present exemplary embodiment, the application APP1 is configured to collect production data from programmable logic controllers that can exchange data with component K, to statistically evaluate it, and to transmit it to an external SCADA (Supervisory Control and Data Acquisition) system; however, the industrial controller and the SCADA system are not shown in the figure for the sake of simplicity.

[0021] The figure also shows a test environment CE ("certification environment"), which essentially consists of a server on which various test environments BOX1, BOX2 are instantiated. In this example, the test environments BOX1, BOX2 are virtual machines, of which the test environment BOX1 emulates a so-called Docker engine, where the Docker engine corresponds to a runtime environment RT of component K. Additionally, an industrial controller is also simulated as a data source in the same way that the real industrial controller represents a data source for component K. Furthermore, the test environment BOX1 is also designed to simulate a data sink similar to the SCADA system described. In an alternative embodiment, the test environment BOX1, BOX2 can also be embedded in a real environment, i.e., linked to a real controller, etc.; such a scenario is also referred to as "HIL" (hardware-in-the-loop).

[0022] Accordingly, the APP1 application is a so-called Docker container that runs in the RT runtime environment during production, but is executed in the BOX1 test environment for testing and certification. The BOX1 test environment also includes a logging function UE1 (monitoring engine), which, among other things, can log and evaluate the data exchange of the APP1 application with the simulated data sources and data sinks during its operation in the BOX1 test environment. Furthermore, the UE1 logging function is configured to record the registered interactions of the APP1 application, i.e., access to the data sources, transfers to the data sinks, internal memory accesses, library calls, access to (simulated) hardware resources, etc.to create a first characteristic data set EDS1 and link it to the application APP1 and, after testing and certification, to transmit it to the application repository REP (repository).

[0023] The application store REP represents a so-called APP store in the overall system shown, with which the applications APP1, ..., APPn can be made available for component K and other components. It should be noted that other components may also be of a different type, and that different "suppliers" may provide the various applications APP1, ..., APPn, possibly for a fee.

[0024] As already mentioned, component K shows a number of runtime environments RT ("runtime environment") for running so-called Docker containers, with only one runtime environment RT being shown. The runtime environment RT includes or has access to a second monitoring device UEK, which is structured similarly or identically to the monitoring device UE1 of the test environment BOX1. The monitoring device UEK is connected to a comparison device VE, which is configured to compare the first characteristic data set EDS1 with a second characteristic data set (not shown) generated by the monitoring device UEK during the productive run of the application APP1.The comparison device VE is programmed in such a way that in the event of an administrable, significant deviation between the characteristic data sets, a warning is issued, the APP1 averting process is stopped, or another pre-programmed reaction is carried out.

[0025] The comparison device VE can also perform further control functions, in particular a predefined blacklist or a predefined whitelist (or both) can be received and taken into account with the first characteristic data set EDS1 or in another way, whereby the blacklist describes interactions of the application APP1 that must not be carried out under any circumstances, and the whitelist prescribes interactions that may be carried out at least once or at regular intervals or under certain conditions or even must be carried out unconditionally, for example calling a so-called watchdog function or the like.

[0026] The typical workflow in the system shown assumes that the APP1 application is first programmed using the ENG development system. Optionally, a blacklist or a whitelist can also be defined. Furthermore, during development or at another time and by another system or workstation, a permitted interaction pattern can be defined. This means defining which data points of a lower-level programmable logic controller the application may access, how often, and in what way; which parameters may be transferred to a data sink; which memory areas or information may be accessed (and also in what way and with what frequency), etc.All of the latter information is made available to the monitoring device UE of the test environment BOX1, after which the application APP1 is executed in the test environment BOX1, specifically in the virtual machine VM1 created there. The monitoring device UE1 comprises an algorithm that creates a characteristic data set EDS1 from the registered interactions of the application APP1 during test operation or certification operation. A check value is generated from each registered and monitored interaction, at least upon initial call, which is then added to a hash value or key with other check values. Of course, the frequency of a call, the target of a call or interaction, and the like can also have an impact on the generated first data set EDS1.The registered interactions are displayed on a separate workstation so that a test engineer can determine whether only permitted interactions have expired or whether unauthorized interactions have also occurred, in which case the application APP1 is rejected for revision.

[0027] After a successful test, the application APP1 and the generated first data set EDS1 are linked to form an archive file. This archive file is certified with a digital key so that the integrity of this data packet can be verified later. It is transferred to the application memory REP and thus made available for use. This archive file or container is transferred to component K for use. The portion containing the application APP1 is transferred to the runtime environment RT for productive use, and the first characteristic data set EDS1 is made available to the comparison device VE. The portion of the first characteristic data set EDS1 that describes the interactions to be monitored and further describes the algorithm used to generate the second characteristic data set is sent to the second monitoring device UEK.During the runtime of the APP1 application in productive operation, the monitoring device UEK monitors the interactions of the APP1 application with the "environment," i.e., generally peripherals, communication connections, memory, and the like, in particular interactions with a lower-level industrial control system and / or a data sink such as a SCADA system. In accordance with regulations, a second characteristic data set is generated and transmitted at regular intervals to the comparison device VE. The comparison device VE checks whether the actual runtime behavior deviates significantly or insignificantly from the certified runtime behavior during operation in the test environment BOX1.

[0028] In one embodiment, information about the runtime behavior, i.e. the registered interactions of the application APP1, can be used to train a neural network, i.e. an artificial intelligence, wherein either automatically generated feedback and / or feedback from a monitoring workstation makes it possible to train the neural network in such a way that it can distinguish between permitted and non-permitted interactions and behavior patterns.

[0029] The trained neural network can then be protected against further changes and, by making it available, particularly via the application memory REP, finally made available to the monitoring device UEK to monitor interactions, runtime behavior, and access behavior of the APP1 application during productive operation. In this variant, the comparison device VE is configured to receive and process messages, particularly alarms regarding unauthorized interaction behavior, and initiate appropriate responses (messages, interruptions, etc.).

Claims

1. Method for providing an application (APP1, ..., APPn) for a computer-controlled component (K), in particular for an industrial edge device, wherein the application (APP1, ..., APPn) is provided for the component (K) according to its creation by means of an application store (REP), in particular by means of an APP store, characterised in that the application (APP1, ..., APPn) is executed in a test environment (BOX1, BOX2) before its provision, with the execution of the application (APP1, ..., APPn) in the test environment (BOX1, BOX2), a first characteristic dataset (EDS1), in particular a fingerprint, a hash value, a profile file or a feature table, is formed with or via the test environment (BOX1, BOX2) by way of interactions registered with the execution of the application (APP1, ..., APPn), wherein the interactions are in each case accesses to storage cells, registers or services, the first data set is provided assigned to the application (APP1, ..., APPn) by means of the application store (REP), in order to execute the application (APP1, ..., APPn), this and the first dataset (EDS1) are transmitted to the component (K), during the execution of the application (APP1, ..., APPn) in an execution environment (RT) of the component (K), a second characteristic dataset relating to the interactions of the application (APP1, ..., APPn) registered there with or via the execution environment (RT) is formed at least temporarily, the first and the second characteristic dataset are compared with one another, wherein with a deviation of the datasets from one another, which exceeds a predetermined degree, a malfunction is reported, and / or the execution of the application (APP1, ..., APPn) is stopped.

2. Method according to claim 1, characterised in that an encapsulated execution environment, in particular a so-called sandbox, is used as the test environment (BOX1, BOX2).

3. Method according to one of the preceding claims, characterised in that a virtual machine (VM1, VM2) running on a computer hardware is used for the test environment (BOX1, BOX2), wherein the component (K) is reproduced by the virtual machine (VM1, VM2).

4. Method according to one of the preceding claims, characterised in that using the first and the second characteristic dataset, in each case the type and / or the frequency of accesses to data of an industrial automation component tethered directly or indirectly, in particular an industrial controller, is documented by the application (APP1, ..., APPn).

5. Method according to one of the preceding claims, characterised in that the first characteristic dataset is stored together with the application (APP1, ..., APPn) in the application store (REP), wherein the first characteristic dataset and the application (APP1, ..., APPn) are transmitted by a shared transmission process to the component (K).

6. Method according to one of the preceding claims, characterised in that the first characteristic dataset (EDS1) is protected against manipulations by means of a digital certificate.

7. Method according to one of the preceding claims, characterised in that information relating to the type and scope of the interactions to be registered and relating to the consideration thereof for the first and the second dataset is linked to the first characteristic dataset (EDS1).

8. Method according to one of the preceding claims, characterised in that the first characteristic dataset (EDS1) comprises information relating to non-permitted interactions, in particular relating to non-permitted accesses to data or functions of the component (K) and / or the periphery linked to the component (K), wherein corresponding ports, interfaces and such like on the part of the component are automatically blocked during productive operation.

9. Arrangement with a test environment (BOX1, BOX2) for providing an application (APP1, ..., APPn) for a computer-controlled component (K), in particular for an industrial edge device, and with a component (K) with an in an execution environment (RT) for executing the application (APP1, ..., APPn), wherein the test environment (BOX1, BOX2) comprises an encapsulated execution environment, in particular a so-called sandbox or a virtual machine (VM1, VM2), for executing the application (APP1, ..., APPn) for test purposes, characterised in that the test environment (BOX1, BOX2) is equipped a monitoring facility (UE1, UE2) for registering interactions of the application (APP1, ..., APPn) with the or relating to the text environment (BOX1, BOX2), wherein the interactions are accesses to storage cells, registers or services in each case, wherein the monitoring facility (UE1, UE2) is designed to form a first characteristic dataset (EDS1), in particular a fingerprint, a hash value, a profile file or a feature table, from the registered interactions, the test environment (BOX1, BOX2) is designed to transmit the application (APP1, ..., APPn) and the first characteristic dataset (EDS1) to an application store (REP) after the execution of the application (APP1, ..., APPn) for test purposes and after creating the first characteristic dataset (EDS1), the component (K) is designed for forming a second characteristic dataset relating to the interactions of the application (APP1, ..., APPn) registered there with or relating to the execution environment (RT) and is provided so that the first and the second characteristic dataset are compared with one another, wherein with a deviation in the datasets from one another, which exceeds a predetermined degree, a malfunction is reported, and / or the execution of the application (APP1, ..., APPn) is stopped.