METHOD FOR MONITORING CONTAINER APPLICATIONS ON A HOST SYSTEM FOR MANIPULATION AND ATTACHMENT

Description

[0001] The invention relates to a method for monitoring container applications on a host system for manipulation, as well as a system.

[0002] Many new industrial and non-industrial IT systems are being developed to be flexibly adaptable to new requirements. A common approach to this is the deployment of container technology within the IT system and the ability to quickly and flexibly load new or modified software solutions into the IT systems as container applications using this technology.

[0003] Such container applications can be run on known or unknown target systems, also known as host systems. Furthermore, it is possible to run container applications from different vendors on the same system. This flexibility, provided by easily loadable container applications, brings with it the threat that manipulated or malicious container applications can be introduced into the system and compromise it.

[0004] To protect against manipulation, container applications are often isolated using security mechanisms available on the host, particularly virtualization mechanisms such as Linux namespaces, chroot, or hypervisors, or access control mechanisms like user rights management, SELinux, SMACK, or AppArmor. Furthermore, it is crucial to monitor the security status, such as the integrity of the software or configuration components used and the behavior of subsequently loaded container applications during runtime, to detect manipulation or unusual behavior of the container applications early and thus ensure the ongoing integrity of the host system. This monitoring itself, however, must function reliably to reliably detect any integrity violations.However, known surveillance solutions form a central instance that attackers can deactivate or otherwise manipulate with sufficient effort.

[0005] Therefore, there is a need for an improved solution for monitoring container applications for tampering. In particular, the reliability and tamper resistance of the monitoring should be improved.

[0006] Solutions for monitoring container applications are known, such as those offered by the company AquaSec ( Enforcer or MicroEnforcer). https: / / www.aquasec.com / news / aqua-3-0-delivers-runtime-security-for-zero-infrastructure-containeras-a-service-environments / ). Other solutions for monitoring container applications are offered by providers such as NeuVector ( https: / / neuvector.com / ) or Sysdig ( https: / / sysdig.com / ). This typically involves monitoring one or more containers for malicious behavior (unauthorized network access or use of specific commands / system calls). General monitoring systems for integrity monitoring, such as Wazuh, are also well-known. www.wazuh.com ), OSSEC ( www.ossec.net ), Nagios ( www.nagios.org ) Tripwire ( www.tripwire.org ) and Falco ( www.falco.org These solutions support, among other things, the detection of illegitimate processes, unauthorized file modifications, write access, or the establishment or use of network connections by processes. If unauthorized events or deviations from a reference are detected, an alarm is generated, for example, in the form of a log message. The article "ConMon: An automated container based network performance monitoring system" by Moradi Farnaz et al., published on May 8, 2017, describes decentralized monitoring of the network performance of container applications. The book "Developing multi-agent systems with Jade," ISBN 978-0-470-05747-6, describes JADE, a decentralized monitoring system for container applications. EP3451576 describes blockchain-based manipulation detection for container applications.

[0007] Against this background, it is therefore an object of the invention to provide an improved method for monitoring container applications on a host system for manipulation. Furthermore, it is an object of the invention to provide an improved system with which such an improved method can be carried out.

[0008] These problems of the invention are solved by a method having the features specified in claim 1 and by a system having the features specified in claim 9. Preferred embodiments of the invention are specified in the dependent claims, the following description, and the drawing.

[0009] In the method for monitoring container applications on a host system, a monitoring process is started on the host system for at least two of the container applications and assigned, preferably by means of a data link, wherein the monitoring processes compare the current behavior of at least one other container application (besides the one assigned to it) with a reference behavior of the at least one other container application. The method according to the invention serves to monitor container applications for manipulation and / or for monitoring container applications for manipulation attempts.In a preferred embodiment of the invention, the assignment of the monitoring process to a container application by means of a data-related link can be achieved in particular by the monitoring process gaining access to a resource of the container application, preferably managed by the host system. For this purpose, the monitoring process can in particular use a file handle (English: ". file handle ") and / or a pointer and / or a link and / or a key (English: "key" or "magic number" ) or use a so-called capability to access the resource of the associated container application managed by a host system. The monitoring process has a link or reference to the resource of the associated container application. The resource is preferably an inter-process communication resource and / or a shared memory area (English: " shared memory ") and / or a pipe and / or a message queue and / or a socket and / or a namespace (English: " name space "), and / or a control group (English: " control group The monitoring process preferably has at least read access to the operating system-managed resource of the assigned container application. Using the operating system-managed resource, the monitoring process can, in particular, determine runtime integrity monitoring information of the assigned container application that depends on the current behavior of the container application and verify it against reference information of the assigned container application. Thus, in the method according to the invention, monitoring of at least one other container application besides the one assigned to it can also be carried out indirectly by the monitoring process assigned to the container application.Their current behavior can be verified by having the monitoring process determine their interaction with the container application assigned to it and with at least one other container application, and then compare this interaction to the reference behavior of that other container application. This constitutes indirect monitoring of the other container application. Specifically, the interaction allows the monitoring process to determine whether the other container application is being monitored by its own assigned monitoring process. Furthermore, the other container application, or its assigned monitoring process, can explicitly provide monitoring information to the container application, which can then be reviewed by the monitoring process assigned to that container application.

[0010] It is understood that a container application associated with a monitoring process is understood to be the container application to which the monitoring process is assigned. It is expedient to assign different, i.e., non-identical, monitoring processes to different container applications.

[0011] Using the method according to the invention, container applications are not monitored by a central component, but rather decentralized monitoring processes are started and assigned to the respective container applications. The monitoring processes are designed and configured to capture the current behavior of at least one other container application and compare it with a reference behavior of the at least one other container application. In this way, at least two container applications are monitored by at least two monitoring processes. Consequently, it is not sufficient for an attacker to manipulate a single central monitoring process to manipulate container applications; rather, at least two monitoring processes must be compromised to manipulate the container applications. It is particularly preferred that each of the container applications be assigned a different, i.e.,Each container application is assigned its own monitoring process. This means that monitoring processes are assigned to only one of the container applications, and not to multiple container applications. Preferably, not just at least two container applications are each assigned a monitoring process, but three, four, or more container applications each have their own dedicated monitoring process. The more monitoring processes there are, the more difficult it becomes for an attacker to manipulate each monitoring process individually. Preferably, all monitoring processes are configured to compare the current behavior of at least two, preferably three or more, or all of the container applications other than their assigned container application with a reference behavior of at least one other container application.Consequently, the monitoring processes do not just monitor a single container application, but can monitor multiple or all container applications running on the host system. This significantly increases the security of the host system with the container applications running on it.

[0012] Advantageously, in the method according to the invention, a conclusion is drawn, depending on the comparison, as to whether or not manipulation of the at least one container application under comparison has occurred. In particular, a conclusion is preferably drawn as to whether or not manipulation has occurred for each of the several or all of the at least one container application under comparison; that is, the conclusion as to whether manipulation has occurred is preferably drawn for each of the at least one container application. In this way, individual manipulated container applications can advantageously be identified. If the comparison reveals a deviation between the behavior of the container application and the reference behavior, a conclusion is drawn that manipulation of the container application has occurred.Subsequently, an alarm message or signal can be provided, and / or network communication of the affected container application or the host can be restricted, and / or access to an input / output interface of the host by the affected container application can be blocked or generally blocked, and / or the affected container application can be stopped, terminated, or restarted. Furthermore, in a further embodiment of the invention, it is possible to block a restart of the program code, i.e., the container image, of the affected container application on the host.Preferably, in the method according to the invention, when it is concluded that the at least one container application has been manipulated, an alarm message or alarm signal is provided and / or network communication of the affected at least one container application or the host is limited and / or access to an input / output interface of the host by the affected at least one container application is blocked or generally blocked, and / or the affected at least one container application is stopped, terminated or restarted and / or a restart of program code, i.e. a container image, of the affected at least one container application on the host is blocked.

[0013] Advantageously, in the method according to the invention, the reference behavior of the container application is communicated to the monitoring processes upon startup, shutdown, and / or modification of at least one other container application; that is, information about the reference behavior is transmitted. This allows for flexible responses to newly started, modified, and / or stopped container applications. Preferably, the reference behavior of a stopped container application is not considered further. Preferably, the reference behavior is supplemented for newly started container applications, and the reference behavior is advantageously adjusted for modified container applications.

[0014] In an advantageous embodiment of the method according to the invention, the monitoring process is assigned to the respective container application by starting the monitoring process as part of the respective container application. Particularly preferably, the monitoring processes are assigned to the at least two container applications such that each monitoring process is part of one of the at least two container applications. In this way, the monitoring process is automatically initialized with the starting of the respective container application. By starting the container application and the monitoring process together, this embodiment of the invention automatically assigns the monitoring process to the respective container application, as the host system necessarily registers and manages the monitoring process as part of the container application and continuously assigns the monitoring process internally to the container application.The monitoring process can, in particular, be an operating system process. In this further development, the invention can also be described as a method for monitoring container applications on a host system, in which a monitoring process is started on the host system as part of at least two of the container applications, and the monitoring processes compare the current behavior of at least one of the container applications other than the container application of which they are a part, with a reference behavior of the at least one other container application.

[0015] In a preferred embodiment of the invention, the current behavior of at least one other container application is compared with the reference behavior with regard to a response behavior to a request, i.e. a request message, and / or with regard to an operational behavior and / or with regard to a behavior during a manipulation attempt and / or during a successful manipulation.

[0016] Preferably, in the method according to the invention, a reference behavior component communicates the reference behavior to the monitoring processes. The reference behavior component can advantageously be provided as a central component. In this embodiment of the invention, the reference behavior component is easy and reliable to administer. Alternatively, and also advantageously, the reference behavior component can be assigned, expediently redundantly, to at least two or more container applications or be part of the two or more container applications.

[0017] Preferably, in the method according to the invention, the reference behavior component is cryptographically protected. In this further development, the reference behavior component itself is particularly protected against manipulation. Reference information used by the reference behavior component can preferably be cryptographically protected, preferably encrypted and / or protected by a cryptographic checksum. Alternatively or additionally, and equally advantageously, the program code of the reference behavior component can be encrypted or protected by a cryptographic checksum, or it can be in obfuscated form. Furthermore, and more preferably, the reference behavior component can include a self-integrity monitoring component that monitors the integrity of the reference behavior component at runtime.

[0018] Advantageously, in a further development of the invention, the reference behavior component is implemented using a distributed database. In this further development, the reference behavior component is advantageously not provided as a central and therefore potentially easier-to-manipulate component, but rather as a distributed database, making it significantly more difficult to manipulate. This is because, in this further development, manipulation of at least a predominant part or the entire distributed database would be a prerequisite for manipulating the reference behavior component. The distributed database can be implemented as a distributed ledger database or as a blockchain database, in which a data record is cryptographically verified by a block of a blockchain.In addition to the reference behavior component, the monitoring information of a container in a distributed database can also be made available to one or more monitoring processes for inspection. Alternatively, the monitoring process can be implemented using smart contract program code within the distributed database.

[0019] The system according to the invention comprises container images for container applications and a host system and is configured to carry out a method according to the invention as described above.

[0020] In an advantageous embodiment of the invention, the system is a manufacturing and / or processing system, preferably a machine tool, an unmanned transport system or a robot.

[0021] The invention will now be explained in more detail with reference to exemplary embodiments shown in the drawing.

[0022] The single drawing figure 1 shows a system according to the invention with a host system for carrying out a method according to the invention for monitoring container applications on a host system schematically in a schematic diagram.

[0023] On the host system H of the in Fig. 1 In the illustrated system A according to the invention, a container runtime environment is started. Within the container runtime environment, container applications CONT1, CONT2, and CONT3 are started using container images. Unlike prior art, in the method according to the invention, which is executed on the host system H, the container applications CONT1, CONT2, and CONT3 are not monitored for manipulation and attempted manipulation by means of a central monitoring component. Instead, the method according to the invention performs decentralized monitoring of the container applications CONT1, CONT2, and CONT3. According to the invention, in the illustrated embodiment, the monitoring of the container applications CONT1, CONT2, and CONT3 is performed reciprocally by the container applications CONT1, CONT2, and CONT3 themselves.On the host system according to the invention, all usual and known hardening measures are first carried out for the container runtime environment, namely mandatory access control, namespace control, and restriction of the permissions of the container applications CONT1, CONT2, CONT3 and / or restriction of communication, for example by means of Calico or other known SDN solutions (SDN = English). "Software Defined Networking "). By implementing these hardening measures, container applications CONT1, CONT2, CONT3 on host system H cannot view sensitive data from other container applications CONT1, CONT2, CONT3.

[0024] On the host system H, a configuration component KOKO is implemented that provides monitoring configuration information UKONF for a currently active runtime configuration, i.e., for a configuration of currently running container applications. This configuration component KOKO can, for example, be the container runtime environment itself or an independent configuration component KOKO and forms a reference behavior component within the meaning of the present invention.

[0025] The monitoring configuration information UKONF contains a set of reference values ​​for monitoring. In the illustrated example, these reference values ​​include information about the type and number of running container applications, their checksums, their permissions, permitted network activities, and maximum resource consumption (such as CPU time or RAM). Other, not specifically illustrated, examples may include additional monitoring configuration information, or this information may be omitted.

[0026] The monitoring configuration information UKONF belonging to each container application can either be set or calculated by the configuration component KOKO itself, or it can already be contained in the container image. For example, the container image might contain a default value specifying how many network resources or CPU resources the container applications CONT1, CONT2, and CONT3 each require. These default values ​​in the container image are checked by the configuration component KOKO and either accepted and incorporated into the monitoring configuration information UKONF, or rejected. In the latter case, the container application is prevented from starting.

[0027] The KOKO configuration component is also responsible for changes to the monitoring configuration information UKONF when container applications are started, modified, or stopped. For example, when a container application is started or updated, the monitoring configuration information UKONF is updated. This might involve setting or changing reference values ​​for network activity, or determining or recalculating checksums for the container application's content. The KOKO configuration component then either updates the monitoring configuration information UKONF itself or initiates the adjustment of the monitoring configuration information to the newly determined or changed reference values. When container applications are stopped, the corresponding elements of the monitoring configuration information UKONF (CONT1, CONT2, CONT3) are deleted.The monitoring configuration information UKONF is appropriately deleted by the configuration component KOKO and by the container applications CONT1, CONT2, CONT3 to which it has been transmitted.

[0028] In the illustrated embodiment, the configuration component KOKO is implemented as a trusted execution environment, making it more difficult for an attacker with appropriate privileges to manipulate the KOKO configuration component and allowing it to be considered trustworthy. The monitoring configuration information UKONF is provided to the container applications CONT1, CONT2, and CONT3 as reference information, enabling each to implement monitoring functionality using a monitoring component UEKO, as described below.

[0029] In the illustrated embodiment, the monitoring component UEKO is not implemented as a central component, but rather as a decentralized monitoring component UEKO for each of the container applications CONT1, CONT2, and CONT3, which each monitors the other container applications CONT1, CONT2, and CONT3. The monitoring components UEKO of the container applications CONT1, CONT2, and CONT3 are configured to perform monitoring actions UEB in the form of capturing activities of other container applications CONT1, CONT2, and CONT3 and comparing these activities with reference values ​​contained in the monitoring configuration information UKONF. Furthermore, the monitoring actions UEB include a liveness check of other, not specifically configured, container applications. Fig. 1The depicted container applications and port scans on the host system H, as well as a request for activities of container applications CONT1, CONT2, CONT3 captured by other container applications CONT1, CONT2, CONT3 and an attestation of captured activities of container applications CONT1, CONT2, CONT3 to other monitoring components UEKO.

[0030] If a monitoring component UEKO detects deviations in the recorded activities of a container application CONT1 compared to the provided reference values, it initiates countermeasures. These include, for example, notifying the other monitoring components UEKO about the measured deviation of the monitored container application CONT1, as well as notifying a component outside of the container applications CONT1, CONT2, CONT3, which then executes further measures, such as stopping the monitored container application.

[0031] In the illustrated embodiment, the monitoring configuration information UKONF is managed by the configuration component KOKO. Each container application CONT1, CONT2, CONT3 has its own monitoring component UEKO, which is responsible for monitoring the other container applications CONT1, CONT2, CONT3 on the host system H and loads the monitoring configuration information UKONF, managed by the configuration component KOKO, using load operations LAE. In the illustrated embodiment, the monitoring UEB of the container applications CONT1, CONT2, CONT3 is performed simultaneously by many container applications CONT1, CONT2, CONT3 and no longer by a central instance. However, the described method has the disadvantage that the monitoring configuration information UKONF, along with the central configuration component KOKO, itself becomes a central point of attack for potential manipulation.

[0032] In another embodiment, not shown in detail, the monitoring configuration information UKONF is no longer managed by a central configuration component KOKO, but rather by the container applications themselves. For this purpose, the current monitoring configuration information UKONF is inserted as reference information into the respective container image or the file system of the loaded container instance when a container application CONT1, CONT2, or CONT3 is started. In this embodiment, the configuration component KOKO is only configured to transmit changes to the reference values ​​in the monitoring configuration information UKONF to all containers when a container application is started, modified, or stopped.The configuration component KOKO monitors, at most, the consistency of the monitoring configuration information UKONF with the currently running container applications CONT1, CONT2, CONT3. This is achieved, for example, by pausing the current monitoring process until the changes in all monitoring configuration information UNKONF of the running container applications CONT1, CONT2, CONT3 have been implemented. Alternatively, a time window can be defined within which the monitoring component UEKO accepts deviations from reference values ​​in the monitoring configuration information UKONF, or missing elements of the monitoring configuration information UKONF, or elements that have become obsolete due to stopped container applications CONT1, CONT2, CONT3.

[0033] In the illustrated embodiment, a monitoring component UEKO is integrated into each of the container applications CONT1, CONT2, and CONT3. Optionally, when a new container application is started, a check can be performed to see if a suitable monitoring component UEKO is present in the container image of the new container application. Otherwise, the execution of the new container application is prevented. This advantageous configuration ensures that each of the container applications contains a monitoring component UEKO.

[0034] Alternatively, in further embodiments, a monitoring component UEKO can be integrated into the container image during the construction of the container image to be executed on a host system or several different host systems.

[0035] In alternative implementations, a separate monitoring process can be started on the host system H for each container application CONT1, CONT2, CONT3. This process compares its monitoring configuration information UKONF with the monitoring processes of other container applications CONT1, CONT2, CONT3. In these implementations, the monitoring configuration information UKONF and the monitoring components UEKO are therefore not located within the container applications CONT1, CONT2, CONT3 themselves, but rather in corresponding monitoring processes on the host system H.

[0036] The monitoring components UEKO of the illustrated embodiment, which are part of the respective container applications CONT1, CONT2, CONT3, can monitor not only other container applications CONT1, CONT2, CONT3 from the same manufacturer, but also container applications from other manufacturers. In further embodiments, it can be specified that no information in the monitoring configuration information UNKONF contains sensitive data about the container application itself. This can be achieved, for example, by a policy defined in the container image, which is provided to the configuration component KOKO when the respective container application from the third-party manufacturer is started and describes which reference values ​​are permitted for monitoring UEB.The configuration component KOKO then decides whether it wants to start this container application or whether a start is forbidden, for example because the policy of the container application CONT1, CONT2, CONT3 is too restrictive.

[0037] The monitoring process itself, which is carried out by the monitoring components UEKO of the individual container applications CONT1, CONT2, CONT3, can either be carried out independently of each container application CONT1, CONT2, CONT3 itself, or the monitoring processes can use a peer-to-peer (P2P) mechanism in which the container applications exchange the captured activities in order to then compare them with the reference values ​​in the monitoring configuration information UKONF.

[0038] In addition to comparing reference values ​​in the monitoring configuration information UKONF, the monitoring components UEKO of the container applications CONT1, CONT2, CONT3 can also actively detect unusual activity from other container applications CONT1, CONT2, CONT3. Specifically, the activities of container applications CONT1, CONT2, CONT3 can be monitored and classified as potentially dangerous if these applications do not provide the expected response to a normal request. Therefore, monitoring by the components is not limited to passive observation but can also include actively sending requests to the monitored container applications CONT1, CONT2, CONT3.

[0039] The monitoring components UEKO can also actively monitor UEB by sending dynamic test queries (i.e., request messages) to other container applications, for example, to query information about internal hash values ​​or the contents of specific files. The responses received are then captured by the monitoring components UEKO and compared with values ​​calculated by the monitoring components themselves.

[0040] In the illustrated example, the monitoring component UEKO can also send requests to other container applications that deviate from normal behavior. If successful, the monitoring component UEKO then issues an alarm.

Claims

1. Method for monitoring (UEB) container applications (CONT1, CONT2, CONT3) on a host system (H) for manipulation, in which a monitoring process (UEKO) is started on the host system (H) for each of at least two of the container applications (CONT1, CONT2, CONT3) and is assigned, preferably by means of a data link, wherein the monitoring processes (UEKO) subject the current behaviour of at least one of the container applications (CONT1, CONT2, CONT3) other than the respective assigned container application (CONT1, CONT2, CONT3) to a comparison with a reference behaviour (UKONF) of the at least one other container application (CONT1, CONT2, CONT3), wherein occurring manipulation of the at least one container application (CONT1, CONT2, CONT3) subjected to the comparison is concluded depending on the comparison, and, when an occurring manipulation of the at least one container application is concluded, an alarm message or an alarm signal is provided and / or network communication of the affected at least one container application and / or the host is limited and / or the access to an input / output interface of the host by the affected at least one container application is blocked or is blocked in general, and / or the affected at least one container application is stopped or ended or restarted and / or a restart of a program code, i.e. a container image, of the affected at least one container application on the host is blocked.

2. Method according to the preceding claim, in which the reference behaviour (UKONF) of the container application (CONT1, CONT2, CONT3) is communicated to the monitoring processes (UEKO) upon the start and / or stop and / or upon a change of the at least one other container application (CONT1, CONT2, CONT3).

3. Method according to one of the preceding claims, in which the monitoring process (UEKO) is assigned to the respective container application (CONT1, CONT2, CONT3) in that the monitoring process (UEKO) is started as part of the respective container application (CONT1, CONT2, CONT3).

4. Method according to one of the preceding claims, in which the current behaviour of the at least one other container application (CONT1, CONT2, CONT3) is subjected to a comparison with the reference behaviour (UKONF) with respect to a response behaviour to a question and / or with respect to an operating behaviour and / or with respect to a behaviour upon a manipulation attempt and / or upon an occurring manipulation.

5. Method according to one of the preceding claims, in which a reference behaviour component (KOKO) communicates the reference behaviour (UKONF) to the monitoring processes (UEKO).

6. Method according to Claim 5, in which the reference behaviour component (KOKO) is cryptographically protected.

7. Method according to Claim 5 or 6, in which the reference behaviour component (KOKO) is implemented by means of a distributed database.

8. System, including container images for container applications (CONT1, CONT2, CONT3) and a host system (H), designed to execute a method according to one of the preceding claims.

9. System according to the preceding claim, which is a manufacturing (A) and / or processing system.