EP4088183A1 - Analyse einer container-instanz eines betriebssystems - Google Patents

Analyse einer container-instanz eines betriebssystems

Info

Publication number
EP4088183A1
EP4088183A1 EP21704403.1A EP21704403A EP4088183A1 EP 4088183 A1 EP4088183 A1 EP 4088183A1 EP 21704403 A EP21704403 A EP 21704403A EP 4088183 A1 EP4088183 A1 EP 4088183A1
Authority
EP
European Patent Office
Prior art keywords
container instance
reference image
data
test system
container
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP21704403.1A
Other languages
English (en)
French (fr)
Inventor
Christian Knierim
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Siemens Corp
Original Assignee
Siemens AG
Siemens Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG, Siemens Corp filed Critical Siemens AG
Publication of EP4088183A1 publication Critical patent/EP4088183A1/de
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/577—Assessing vulnerabilities and evaluating computer system security
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/03—Indexing scheme relating to G06F21/50, monitoring users, programs or devices to maintain the integrity of platforms
    • G06F2221/034—Test or assess a computer or a system

Definitions

  • the present invention relates to an automated method for analyzing a container instance of an operating system and to an associated system which can execute the method.
  • industrial systems control devices, industrial PCs, IoT and edge devices, cloud servers
  • IoT and edge devices, cloud servers are often used in the field over a long period of time (10-20 years, sometimes even 30 or 40 years), they are exposed to constantly changing conditions and a dynamic environment.
  • new devices in particular are developed in such a way that they can be flexibly adapted over the period of use. This can be achieved, for example, by supporting reloadable applications / applications / application programs by means of container virtualization / container technologies.
  • Container virtualization is a method to operate several instances (eg application programs), the container instances, of an operating system (as so-called “guests” or clients) isolated from each other on a host system / host computer.
  • Containerization enables the resources used on the host system / host computer to be separated and managed. In this way, it is possible to manage which system resources are assigned to the processes in which container instance.
  • a host system or host computer is a computer integrated into a computer network with an associated operating system that serves clients (eg container instances) or houses servers (that is, provides services).
  • Container instances can be operated in different runtime environments.
  • a runtime environment or execution environment is generally an application framework or a library that supplies executable applications / application programs, such as apps, components, web pages, with the functionality required for their execution at runtime.
  • applications / application programs can be made executable in an “unfamiliar” environment, in that the runtime environment mediates between the application program and the operating system.
  • Operating systems today have a very complex structure. If applications are to run as quickly and easily as possible under several operating systems, it is advisable to implement their own small “operating systems” as runtime environments for these applications. This saves the effort of adapting each individual application separately to the respective operating system.
  • a runtime environment loads the corresponding application and executes it on the platform for which the runtime environment was ultimately created.
  • Container instances that are started in runtime environments can contain weak points that must be identified and remedied in good time so that they cannot be exploited by attackers.
  • the images of the container instance images the / images of the container instance, which can also be referred to as a container image
  • the running container instances are scanned.
  • Case 1 A detection of weak points in the container image (image of the container instance) through a periodic scan of the registry. Regular scanning of container images is carried out here. This has the disadvantage that the started container instance is not examined and thus changes that occur on the container instance during the runtime cannot be taken into account / recognized.
  • Case 2 A detection of weak points in started container instances in the runtime environment.
  • this can be done via privileged container instances which are made available by security manufacturers and which regularly examine the container instances in the runtime environment.
  • privileged container instances which are made available by security manufacturers and which regularly examine the container instances in the runtime environment.
  • This has the disadvantage that a privileged container instance has to be provided.
  • This also has the disadvantage that the optimal times for the investigation by the privileged container instance are not known and may therefore be investigated too often or too seldom and thus weak points cannot be identified in good time.
  • the object of the invention is to provide an improved solution for analyzing and checking started / running container instances, in particular in order to increase the security with regard to undesired operations on the container instance.
  • the invention claims an automated method for analyzing a container instance of an operating system of a host system, the container instance being started in a runtime environment, comprising the steps: Acquisition of an initial reference image of the container instance, the initial reference image being an image the container instance, transmission of the initial reference image to a test system, the test system (4) being arranged outside the host system (2), acquisition of data, the acquisition being carried out triggered by the occurrence of an event and with the event and the data relate to operations on the container instance, the operation representing an operation that actually took place and the data characterizing the operation, - transferring the data to the test system, - creating an updated reference image of the container ner instance, the updated reference image by adapting de s initial reference image is created with respect to effects that the operations have on the container instance, the effects representing expected effects which the operations are expected to cause, and analysis of the updated reference image by the test system.
  • One aspect of the invention is to improve the state of the art in such a way that the analysis of the container Images of the container instance or of the updated reference image of the container instance are event-based, ie triggered by a previous occurrence of an event that relates to operations on the container instance.
  • a container instance is understood to mean an isolated instance of an underlying operating system, which is operated in isolation from other instances on a host system / host computer and runs in the same process space as the operating system itself.
  • Container instances are managed separately and are assigned system resources of the underlying operating system separately. The isolation of the container instance from other instances is achieved with the help of on-board resources of the underlying operating system.
  • a runtime environment is understood to mean an application framework, ie the available and defined requirements of the runtime system, which supplies container instances with the functionality required for their execution at runtime.
  • the fact that the container instance has started means that the container instance is running or is in runtime.
  • the container instance is started in a runtime environment or is running in a runtime environment.
  • the reference image is an image of the container instance and can also be referred to as a clone of the container instance.
  • the analysis of the updated reference image by the test system can also be referred to as checking or checking the current state of the container instance.
  • That the effects represent expected effects, which the operations are expected to cause, means that they are not actual effects, but rather effects te that are a known result of a particular operation, especially if the system is running correctly.
  • the updated reference image therefore does not represent an image of reality, but rather a reference image to be expected on the basis of the operations.
  • Statements about weak points in running container instances can be made by using a container image stored in a registry / register as the initial reference image of the container instance and constantly with the running container when the container instance is started Instance is matched.
  • image ID identification of the container image
  • instance ID identification of the container instance
  • changes can result from operations on the container instance.
  • the changes can result, for example, on a file system of the container instance and through, for example, operations such as installing software or other write operations. It is therefore necessary that when an event occurs that relates to an operation on the container instance, data or an event that represents an operation on the container instance, for this operation on the container instance Instance, all relevant data are also logged / recorded.
  • the data should then be transmitted to a test system, for example when a further / different event occurs and / or at a defined point in time.
  • a transmission to the test system which is to check the container instance can, for example, be carried out with a guarantee of integrity, ie with the prevention of unauthorized modification of information and data.
  • An integrity Secure transmission to the test system can take place, for example, via MTLS (Mutual Transport Layer Security).
  • the inspection system should then update the initial reference image based on the operations on the container instance, ie based on the data, and create an updated reference image. This provides an updated reference image.
  • the test system analyzes and checks the updated reference image, for example with regard to weak points.
  • Operations on the container instance including its content are recorded in the form of data when an event occurs and can be event-based (i.e. directly at the time of the event) via eBPF probes (extended Berklee Packet Filter) or programs based on them on the underlying host system ) can be read out and transmitted / transmitted to the test system which is to check / analyze the updated reference image. Alternatively, the data can be read out at a later point in time and transferred to the test system.
  • the checking of the running container instance is thus carried out in that the operations or data which are determined as described above and which relate to the operations are applied to the initial reference image of the container instance, an updated reference image of the container.
  • ner instance is created and an analysis, for example a weak point scan, of the updated reference image is carried out.
  • Running container instances can thus be event-based triggered by the occurrence of an event (eg via a defined trigger or a defined change operation) scanned / analyzed and do not (only) have to be scanned / analyzed over fixed intervals. This has the advantage that weak points can be identified more quickly can and not only be recognized at the next fixed point in time of an interval.
  • the test system is arranged outside of the host system on which the container instance is operated. A test system outside the container instance and outside the host system has the advantage that no agent / test system is required in the container instance on the runtime environment.
  • test system This has the advantage that the analysis / test by the test system does not take place on the host system itself and therefore no resources are required or used there.
  • the use of a test system outside of the host system also has the advantage that no privileged test instances are required on the runtime system / in the runtime environment, which further container Check instances.
  • This has the advantage that the test system can be managed independently of the operating system / host system and the container instance.
  • malicious software smuggled into the container instance cannot be compromised Means) of the container instance runtime environment and / or security tools.
  • This has the advantage that an initial reference image is made available to the container instance.
  • Subsequent changes to the container instance are recorded in the form of data when an event occurs and can, for example, via eBPF probes (extended Berklee Packet Filter) or programs based on it on the underlying host system in an event-based manner (ie directly at the time of the event) and transmitted / transmitted to the test system which is to check / analyze the updated reference image.
  • the event and / or the operation comprises a write operation on the container instance.
  • the event and / or the operation include changes to the container instance, changes to a file system of the container instance, system calls, modifications and / or creation of files and / or directories, installation processes on the container Instance, changes to authorizations on the container instance and / or changes to files on the container instance.
  • the event and the operation can have different characteristics. The acquisition of data thus takes place when an event occurs and the data relate to an operation on the container instance, the event for which the acquisition of data takes place and the operation to which the data relates may be designed in the same way or differently. For example, a specific write operation on the container instance can be the triggering event for which data is recorded and, at the same time, the data can relate to the specific write operation.
  • data can be collected that relate to a different operation on the container instance than the operation to which the data relate.
  • the time at which the data is transmitted to the test system is not determined immediately after the data has been recorded, but with a time interval after the occurrence of the event.
  • the defined point in time can be established, for example, as a function of a definable cyclical point in time and / or as a function of the available storage capacities of a storage unit provided for the data.
  • the data can be transmitted to the test system at the next defined cyclical point in time in a time sequence (for example every 5 minutes).
  • the time at which the data is transmitted is determined independently of the time of the event.
  • the point in time can be part of a periodic time sequence.
  • the transfer of the data to the inspection system and the subsequent creation of the updated reference image and the analysis of the updated reference image can be carried out, for example, every 5 minutes.
  • the data is not transmitted to the test system in an event-based manner, but the data is still recorded in an event-based manner (that is, triggered by the occurrence of an event).
  • the time at which the data is transmitted is determined as a function of an available storage capacity of a storage unit provided for the data.
  • the data can be transmitted to the test system in a manner assured of integrity, for example via MTLS (Mutual Transport Layer Security).
  • the analysis of the updated reference image is aimed at identifying weak points in the container instance. Identified weak points in the container instance can then be dealt with and / or eliminated.
  • an operation that represents adding an additional file system to the container instance is not taken into account.
  • the input parameter can be provided by an input of a user.
  • An additional file system can be created by an additionally connected storage unit, such as a hardware unit or an additionally connected network drive.
  • This embodiment has the advantage and technical effect of increased flexibility in the use of the test system.
  • a binding test of an additionally connected network drive can be highly complex and therefore take place as an option.
  • the additionally connected network drive can be taken into account or not taken into account as a function of an input by a user or a calculated input parameter (for example calculated on the basis of efficiency parameters). If this is not taken into account, the complexity of the analysis by the test system can be kept lower.
  • the data are temporarily stored before they are transmitted to the test system.
  • an alternative variant is conceivable in which the data is not transferred immediately to the test system, but rather on one local buffer of the underlying host system / operating system and only, for example, when the local buffer is filled to a defined level, an event stored via the above-described guideline / occurrence of a definable second event (such as changes to the container instance, changes to a file system the container instance, write operations on the container instance, system calls, modifications and / or creation of files and / or directories, installation processes on the container instance, changes to authorizations on the container instance and / or changes to files on the container instance) or after an interval has expired to the test system.
  • an event stored via the above-described guideline / occurrence of a definable second event such as changes to the container instance, changes to a file system the container instance, write operations on the container instance, system calls, modifications and / or creation of files and / or directories, installation processes on the container instance, changes to authorizations on the container instance and / or changes to files on the container
  • the invention also claims a system comprising: a container instance of an operating system of a host system, the container instance being started in a runtime environment, a test system, the test system (4) being arranged outside the host system (2) - a first acquisition unit, wherein the first acquisition unit is designed to be able to acquire an initial reference image of the container instance and wherein the initial reference image is an image of the container instance, - a transmission unit, wherein the transmission unit is designed to be able to transmit the initial reference image to a test system, a second acquisition unit, wherein the second acquisition unit is designed to be able to acquire data triggered by the occurrence of an event, whereby the event and the data relate to an operation on the container instance, the operation representing an operation that actually took place and the data characterizing the operation - a transmission unit, the transmission unit being designed to transmit the data to the
  • FIG. 1 shows a flow chart of the method according to the invention and FIG. 2 shows a system according to the invention.
  • DETAILED DESCRIPTION OF THE INVENTION FIG. 1 shows a flow chart of the method according to the invention for analyzing a container instance (3, see FIG. 2) of an operating system of a host system (2, see FIG. 2), the container instance (3) started on a runtime environment.
  • Step S1 acquisition of an initial reference image of the container instance (3), the initial reference image being an image of the container instance (3)
  • Step S2 transmission of the initial reference image to a test system (4, see FIG. 2)
  • step S3 acquisition of data, the acquisition being triggered by the occurrence of an event, and the event and the data relating to an operation on the container instance (3) , the operation representing an operation that actually took place and the data characterizing the operation
  • Step S4 Transmission of the data to the test system (4), the test system (4) being arranged outside the host system (2)
  • Step S5 creating an updated reference image of the container instance (3), the updated reference image being created by adapting the initial reference image with regard to effects that the operations on the container instance z (3), the effects representing expected effects which are expected to cause the operations
  • - Step S6 Analysis of the updated reference image by the test system (4).
  • Step S1 the acquisition of the initial reference image (S1) of the container instance (3), can take place by means of a query on the operating system (2). This can be done initially via an image ID (identification of the container image) of the initial container image and the instance ID (identification of the container instance) are carried out, which are always carried out on the host system (eg using on-board resources, ie using the containers' own resources) Instance runtime environment or security tools).
  • Step S4 the transmission of the data to the test system (S4), can be carried out with a guarantee of integrity, for example via MTLS (Mutual Transport Layer Security).
  • Step S6 the analysis of the updated reference image (S6), is aimed in particular at identifying weak points in the container instance (3).
  • step S5 the creation of the updated reference image (S1) of the container instance (3), operations that represent adding an additional file system to the container instance (3) cannot, depending on an input parameter must be taken into account.
  • the data can be temporarily stored before step S4, the transmission (S4) to the test system (4).
  • 2 shows a schematic representation of a system (1) according to the invention. 2 shows a container instance (3) of an operating system of a host system (2), the container instance (3) being started in a runtime environment. 2 also shows a test system (4), the test system (4) also being designed to be able to analyze an updated reference image created later and the test system (4) being arranged outside the host system (2). Fig.
  • FIG. 2 also shows a first detection unit (5), wherein the first detection unit (5) is designed to be an initia- to capture les reference image of the container instance (3) and wherein the initial reference image is an image of the container instance (3).
  • FIG. 2 also shows a transmission unit (6), the transmission unit (6) being designed to be able to transmit the initial reference image to the inspection system (4).
  • 2 also shows a second acquisition unit (7), the second acquisition unit (7) being designed to be able to acquire data triggered by the occurrence of an event, the event and the data relating to an operation refer to the container instance (3).
  • FIG. 2 also shows a transmission unit (8), the transmission unit (8) being designed to be able to transmit the data to the test system (4).
  • the test system (4) can be arranged outside the container instance (3) and outside the host system (2).
  • the event and / or the operations can be changes to the container instance (3), changes to a file system of the container instance (3), write operations to the container instance (3), system calls, modifications and / or creation of files and / or directories, installation processes on the container instance (3), changes to authorizations on the container instance (3) and / or changes to files on the container instance (3).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Debugging And Monitoring (AREA)
  • Automatic Analysis And Handling Materials Therefor (AREA)

Abstract

Die Erfindung gibt ein automatisiertes Verfahren zur Analyse einer Container-Instanz (3) eines Betriebssystems eines Hostsystems (2) an, wobei die Container-Instanz (3) auf einer Laufzeitumgebung gestartet ist. Das Verfahren weist die folgenden Schritte auf: - Erfassen eines initialen Referenzbilds (S1) der Container-Instanz (3), wobei das initiale Referenzbild ein Abbild der Container-Instanz (3) ist, - Übermitteln des initialen Referenzbilds (S2) an ein Prüfsystem (4), wobei das Prüfsystem (4) außerhalb des Hostsystems (2) angeordnet ist, - Erfassen von Daten (S3), wobei das Erfassen getriggert durch ein Eintreten eines Ereignisses durchgeführt wird und wobei sich die Daten auf eine Operation auf der Container- Instanz (3) beziehen, wobei die Operation eine tatsächlich stattgefundene Operation darstellt und wobei die Daten, die Operation charakterisieren, - Übertragen der Daten (S4) an das Prüfsystem (4), - Erstellen eines aktualisierten Referenzbilds (S5) der Container-Instanz (3), wobei das aktualisierte Referenzbild durch Anpassen des initialen Referenzbilds bezüglich Effekten, die die Operationen auf der Container-Instanz (3) haben, erstellt wird, und - Analysieren des aktualisierten Referenzbilds (S6) durch das Prüfsystem (4). Außerdem gibt die Erfindung ein System (1) an, welches das genannte Verfahren ausführen kann.

Description

Beschreibung Analyse einer Container-Instanz eines Betriebssystems HINTERGRUND DER ERFINDUNG Gebiet der Erfindung Die vorliegende Erfindung betrifft ein automatisiertes Ver- fahren zur Analyse einer Container-Instanz eines Betriebssys- tems und ein zugehöriges System, welches das Verfahren aus- führen kann. Beschreibung des Stands der Technik Da industrielle Systeme (Steuergeräte, Industrie PCs, IoT- und Edge-Geräte, Cloud-Server) oft über einen langen Zeitraum (10-20 Jahre, teilweise auch 30 oder 40 Jahre) im Feld ver- wendet werden, sind sie ständig ändernden Voraussetzungen und einem dynamischen Umfeld ausgesetzt. Um mit diesen Umständen umzugehen, werden vor allem neue Ge- räte so entwickelt, dass sie über die Nutzungszeit flexibel angepasst werden können. Das kann z.B. durch die Unterstüt- zung von nachladbaren Applikatio- nen/Anwendungen/Anwendungsprogrammen mittels Containervirtua- lisierung/Container-Technologien erreicht werden. Containervirtualisierung (oder: Containierisierung) ist eine Methode, um mehrere Instanzen (z.B. Anwendungsprogramme), die Container-Instanzen, eines Betriebssystems (als sog. „Gäste“ oder Clients) isoliert voneinander auf einem Hostsys- tem/Hostrechner zu betreiben. Durch Containierisierung ist eine Trennung und Verwaltung der auf dem Hostsys- tem/Hostrechner genutzten Ressourcen möglich. So lässt sich verwalten, welche Systemressourcen den Prozessen in welcher Container-Instanz zugewiesen werden. Als Hostsystem oder Hostrechner wird ein in ein Rechnernetz eingebundener Computer mit zugehörigem Betriebssystem be- zeichnet, der Clients (z.B. Container-Instanzen) bedient oder Server beherbergt (also Dienste bereitstellt). Container-Instanzen können auf unterschiedlichen Laufzeitum- gebungen betrieben werden. Eine Laufzeitumgebung oder auch Ausführungsumgebung ist ganz allgemein ein Anwendungsrahmenwerk oder eine Bibliothek, die ausführbare Anwendungen/Anwendungsprogramme, wie zum Beispiel Apps, Komponenten, Webseiten zur Laufzeit mit der für ihre Ausführung benötigten Funktionalität versorgt. Durch eine Laufzeitumgebung können Anwendun- gen/Anwendungsprogramme in „ungewohnter“ Umgebung lauffähig gemacht werden, indem die Laufzeitumgebung zwischen dem An- wendungsprogramm und Betriebssystem vermittelt. Betriebssysteme sind heute sehr vielschichtig aufgebaut. Wenn Anwendungen möglichst schnell und einfach unter mehreren Be- triebssystemen laufen sollen, empfiehlt es sich, für diese Anwendungen eigene kleine „Betriebssysteme“ als Laufzeitumge- bungen zu implementieren. Das erspart den Aufwand, jede ein- zelne Anwendung separat an das jeweilige Betriebssystem anzu- passen. Eine Laufzeitumgebung lädt die entsprechende Anwendung und führt sie auf ihrer Plattform aus, für welche die Laufzeitum- gebung letztlich erstellt wurde. Das heißt: Auf diese Weise wird sie selbst zu einer kleinen „Plattform“, auf der die Programme/Anwendungen aufsetzen können. Container-Instanzen, welche auf Laufzeitumgebungen gestartet sind, können Schwachstellen enthalten, die rechtzeitig er- kannt und behoben werden müssen, damit diese nicht von An- greifern ausgenutzt werden können. Um Schwachstellen zu er- kennen, werden die Images der Container-Instanz (Bil- der/Abbilder der Container-Instanz, auch als Container-Image bezeichenbar) oder die laufenden Container-Instanzen ge- scannt. Hierbei sind zwei Fälle zu unterscheiden: Fall 1: Eine Erkennung von Schwachstellen im Container-Image (Bild der Container-Instanz) durch einen periodischen Scan der Registry. Hierbei wird ein regelmäßiges Scannen von Con- tainer-Images durchgeführt. Dies hat den Nachteil, dass nicht die gestartete Container-Instanz untersucht wird und so Ände- rungen, die sich auf der Container-Instanz während der Lauf- zeit ergeben, nicht berücksichtigt/erkannt werden können. Fall 2: Eine Erkennung von Schwachstellen in gestarteten Con- tainer-Instanzen auf der Laufzeitumgebung. Dies kann zum eine über privilegierte Container-Instanz durchgeführt werden, welche von Security Herstellern zur Verfügung gestellt werden und die Container-Instanzen auf der Laufzeitumgebung regelmä- ßig untersuchen. Dies hat den Nachteil, dass eine privile- gierte Container-Instanz bereitgestellt werden muss. Dies hat außerdem den Nachteil, dass die optimalen Zeitpunkte der Un- tersuchung durch die privilegierte Container-Instanz nicht bekannt sind und so möglicherweise zu oft oder zu selten un- tersucht wird und so Schwachstellen nicht rechtzeitig erkannt werden können. Außerdem gibt es die Möglichkeit, Container-Images auf der Laufzeitumgebung zu scannen und von einer Kontrolleinheit überprüfen zu lassen. Dies hat den Nachteil, dass nur beim (Neu-)Start neuer Container-Instanzen ein Scan und eine Über- prüfung durchgeführt wird und keine regelmäßigen Scan- Intervalle vorgesehen sind. Die Aufgabe der Erfindung besteht darin, eine verbesserte Lö- sung bereitzustellen, um gestartete/laufende Container- Instanzen zu analysieren und zu prüfen, insbesondere um die Sicherheit bezüglich unerwünschter Operationen auf der Con- tainer-Instanz zu erhöhen. ZUSAMMENFASSUNG DER ERFINDUNG Die Erfindung ergibt sich aus den Merkmalen der unabhängigen Ansprüche. Vorteilhafte Weiterbildungen und Ausgestaltungen sind Gegenstand der abhängigen Ansprüche. Weitere Merkmale, Anwendungsmöglichkeiten und Vorteile der Erfindung ergeben sich aus der nachfolgenden Beschreibung. Die Erfindung beansprucht ein automatisiertes Verfahren zur Analyse einer Container-Instanz eines Betriebssystems eines Hostsystems, wobei die Container-Instanz auf einer Laufzeit- umgebung gestartet ist, aufweisend die Schritte: - Erfassen eines initialen Referenzbilds der Container- Instanz, wobei das initiale Referenzbild ein Abbild der Container-Instanz ist, - Übermitteln des initialen Referenzbilds an ein Prüfsys- tem, wobei das Prüfsystem (4) außerhalb des Hostsystems (2) angeordnet ist, - Erfassen von Daten, wobei das Erfassen getriggert durch ein Eintreten eines Ereignisses durchgeführt wird und wobei sich das Ereignis sowie die Daten auf Operationen auf der Container-Instanz beziehen, wobei die Operation eine tat- sächlich stattgefundene Operation darstellt und wobei die Daten, die Operation charakterisieren, - Übertragen der Daten an das Prüfsystem, - Erstellen eines aktualisierten Referenzbilds der Contai- ner-Instanz, wobei das aktualisierte Referenzbild durch An- passen des initialen Referenzbilds bezüglich Effekten, die die Operationen auf der Container-Instanz haben, erstellt wird, wobei die Effekte zu erwartenden Effekte darstellen, welche die Operationen erwartungsgemäß verursachen und - Analysieren des aktualisierten Referenzbilds durch das Prüfsystem. Ein Aspekt der Erfindung besteht darin, den Stand der Technik dahingehend zu verbessern, dass die Analyse des Container- Images der Container-Instanz bzw. des aktualisierten Refe- renzbilds der Container-Instanz eventbasiert, d.h. getriggert durch ein vorhergehendes Eintreten eines Ereignisses/Events, das sich auf Operationen auf der Container-Instanz bezieht, durchgeführt wird. Unter Container-Instanz wird im Rahmen der Erfindung eine isolierte Instanz eines darunterliegenden Betriebssystems verstanden, die isoliert von anderen Instanzen auf einem Hostsystem/Hostrechner betrieben wird und im gleichen Pro- zessraum wie das Betriebssystem selbst läuft. Container- Instanzen werden für sich separat verwaltet und bekommen se- parat Systemressourcen des darunterliegenden Betriebssystems zugewiesen. Die Isolierung der Container-Instanz gegenüber anderen Instanzen wird mit Hilfe von Bordmitteln des darun- terliegenden Betriebssystems erreicht. Unter einer Laufzeitumgebung wird im Rahmen dieser Patentan- meldung ein Anwendungsrahmenwerk, d.h. die verfügbaren und festgelegten Voraussetzungen des Laufzeitsystems, verstanden, das Container-Instanzen zur Laufzeit mit der für ihre Ausfüh- rung benötigten Funktionalität versorgt. Dass die Container-Instanz gestartet ist, bedeutet, dass die Container-Instanz läuft bzw. in Laufzeit befindet. Die Con- tainer-Instanz ist in einer Laufzeitumgebung gestartet bzw. läuft in einer Laufzeitumgebung. Das Referenzbild ist ein Abbild der Container-Instanz und kann auch als Klon der Container-Instanz bezeichnet werden. Das Analysieren des aktualisierten Referenzbilds durch das Prüfsystem kann auch als Überprüfen oder Prüfen des aktuellen Zustands der Container-Instanz bezeichnet werden. Dass die Effekte zu erwartenden Effekte darstellen, welche die Operationen erwartungsgemäß verursachen bedeutet, dass es sich nicht um tatsächliche Effekte handelt, sondern um Effek- te, die bei einer bestimmten Operation ein bekanntes Ergebnis sind, insbesondere falls das System korrekt läuft. Das aktua- lisierte Referenzbild stellt somit kein Abbild der Realität dar, sondern ein aufgrund der Operationen zu erwartendes Re- ferenzbild. Aussagen über Schwachstellen von laufenden Container- Instanzen können getroffen werden, indem bei einem Start der Container-Instanz ein in einer Registry/einem Register hin- terlegtes Container-Image als initiales Referenzbild der Con- tainer-Instanz verwendet wird und ständig mit der laufenden Container-Instanz abgeglichen wird. Dies kann initial über eine Image-ID (Identifikation des Container-Image) des initi- alen Container-Image und die Instanz-ID (Identifikation der Container-Instanz) durchgeführt werden, welche ständig auf dem Hostsystem (z.B. über Bordmittel, d.h. über eigene Mittel der Container-Instanz Laufzeitumgebung oder Security-Tools) abgefragt werden kann. Während der Laufzeit der Container-Instanz können sich durch Operationen auf der Container-Instanz Änderungen ergeben. Die Änderungen können sich zum Beispiel auf einem Dateisystem der Container-Instanz und durch zum Beispiel Operationen wie Nachinstallieren von Software oder anderen Schreiboperationen ergeben. Deshalb ist es erforderlich, dass bei einem Eintre- ten eines Ereignisses, das sich auf eine Operation auf der Container-Instanz Daten bezieht bzw. ein Ereignis, dass eine Operation auf der Container-Instanz darstellt, zu dieser Ope- ration auf der Container-Instanz sämtliche relevante Daten mitprotokolliert werden/erfasst werden. Anschließend sollen die Daten zum Beispiel bei Eintreten eines weiteren/anderen Ereignisses und/oder zu einem definierten Zeitpunkt zu einem Prüfsystem übertragen werden. Eine Übertragung zu dem Prüfsystem, welches die Container- Instanz überprüfen soll, kann beispielsweise integritätsgesi- chert, d.h. unter Verhinderung unautorisierter Modifikation von Information und Daten, erfolgen. Eine integritätsgesi- cherte Übertragung zu dem Prüfsystem kann beispielsweise über MTLS (Mutual Transport Layer Security) erfolgen. Das Prüfsystem soll das initiale Referenzbild dann anhand der Operationen auf der Container-Instanz d.h anhand der Daten aktualisieren und ein aktualisiertes Referenzbild erstellen. Dadurch wird ein aktualisiertes Referenzbild bereitgestellt. Das Prüfsystem analysiert und überprüft das aktualisierte Re- ferenzbild anschließend zum Beispiel bezüglich Schwachstel- len. Operationen auf der Container-Instanz mitsamt Inhalt werden bei dem Eintreten eines Ereignisses in Form von Daten erfasst und können beispielsweise über eBPF-Probes (extended Berklee Packet Filter) oder darauf basierende Programme auf dem da- runterliegenden Hostsystem eventbasiert (d.h. direkt zum Zeitpunkt des Ereignisses) ausgelesen werden und an das Prüfsystem, welches das aktualisierte Referenzbild überprü- fen/analysieren soll, übertragen/übermittelt werden. Alterna- tiv können die Daten zu einem späteren Zeitpunkt ausgelesen und an das Prüfsystem übertragen/übermittelt werden. Die Überprüfung der laufenden Container-Instanz wird somit durchgeführt, indem die – wie oben beschrieben – ermittelten Operationen bzw. Daten, welche sich auf die Operationen be- ziehen, auf das initiale Referenzbild der Container-Instanz angewandt werden, ein aktualisiertes Referenzbild der Contai- ner-Instanz erstellt wird und eine Analyse, zum Beispiel ein Schwachstellenscan, des aktualisierten Referenzbilds durchge- führt wird. Laufende Container-Instanzen können somit eventbasiert ge- triggert durch das Eintreten eines Ereignisses (z.B. über ei- nen definierten Trigger oder eine definierte Änderungsopera- tionen) gescannt/analysiert werden und müssen nicht (nur) über feste Intervalle gescannt/analysiert werden. Dies hat den Vorteil, dass Schwachstellen schneller erkannt werden können und nicht erst zu einem nächsten festen Zeitpunkt ei- nes Intervalls erkannt werden. Das Prüfsystem ist außerhalb des Hostsystems, auf dem die Container-Instanz betrieben wird, angeordnet. Ein Prüfsystem außerhalb der Container-Instanz und außerhalb des Hostsystems hat den Vorteil, dass kein Agent/Prüfsystem in der Container-Instanz auf der Laufzeitumgebung erforder- lich ist. Das hat den Vorteil, dass das Analysieren/die Prü- fung durch das Prüfsystem nicht auf dem Hostsystem selbst stattfindet und somit dort keine Ressourcen erforderlich sind bzw. verbraucht werden. Die Verwendung eines Prüfsystems außerhalb des Hostsystems hat außerdem den Vorteil, dass für das Analysieren des aktua- lisierten Referenzbilds und ein mögliches Identifizieren von Schwachstellen der Container-Instanz keine privilegierten Prüf-Instanzen auf dem Laufzeitsystem/in der Laufzeitumgebung erforderlich sind, welche weitere Container-Instanzen über- prüfen. Das hat den Vorteil, dass das Prüfsystem unabhängig von dem Betriebssystem/Hostsystem und der Container-Instanz verwaltet werden kann. Außerdem hat es den Vorteil, dass über in die Container-Instanz eingeschleuste Schadsoftware nicht kompromittiert werden kann In einer weiteren Ausführungsform der Erfindung erfolgt das Erfassen des initialen Referenzbilds der Container-Instanz durch eine Abfrage auf dem Betriebssystem, zum Beispiel über Bordmittel (d.h. über eigene Mittel) der Container-Instanz Laufzeitumgebung und/oder Security-Tools. Das hat den Vor- teil, dass ein initiales Referenzbild der Container-Instanz zur Verfügung gestellt wird. Spätere Änderungen auf der Container-Instanz zum Beispiel durch Operationen auf der Container-Instanz werden inklusive Inhalt bei dem Eintreten eines Ereignisses in Form von Daten erfasst und können beispielsweise über eBPF-Probes (extended Berklee Packet Filter) oder darauf basierende Programme auf dem darunterliegenden Hostsystem eventbasiert (d.h. direkt zum Zeitpunkt des Ereignisses) ausgelesen werden und an das Prüfsystem, welches das aktualisierte Referenzbild überprü- fen/analysieren soll, übertragen/übermittelt werden. In einer weiteren Ausführungsform der Erfindung umfasst das Ereignis und/oder die Operation eine Schreiboperation auf der Container-Instanz. In einer weiteren Ausführungsform der Erfindung umfassen das Ereignis und/oder die Operation Änderungen auf der Container- Instanz, Änderungen eines Dateisystems der Container-Instanz, System Calls, Modifikationen und/oder Anlegen von Dateien und/oder Verzeichnissen, Installationsvorgänge auf der Con- tainer-Instanz, Änderungen von Berechtigungen auf der Contai- ner-Instanz und/oder Änderungen von Dateien auf der Contai- ner-Instanz. In einer weiteren Ausführungsform der Erfindung können das Ereignis und die Operation unterschiedlich ausgeprägt sein. Das Erfassen von Daten erfolgt somit bei einem Eintreten ei- nes Ereignisses und die Daten beziehen sich auf eine Operati- on auf der Container-Instanz, wobei das Ereignis, zu dem das Erfassen von Daten erfolgt und die Operation, auf die sich die Daten bezieht auf dieselbe Weise oder unterschiedlich ausgebildet sein können. So kann zum Beispiel eine bestimmte Schreiboperation auf der Container-Instanz das auslösende Er- eignis sein, zu dem das Erfassen von Daten stattfindet und gleichzeitig können sich die Daten auf die bestimmte Schrei- boperation beziehen. Alternativ können bei einem auslösendem Ereignis Daten erhoben werden, die sich auf eine andere Ope- ration auf der Container-Instanz beziehen als die Operation, auf welche sich die Daten beziehen. In einer weiteren Ausführungsform der Erfindung ist der Zeit- punkt des Übertragens der Daten an das Prüfsystem nicht di- rekt nach dem Erfassen der Daten, sondern mit zeitlichem Ab- stand nach dem Eintreten des Ereignisses festgelegt. Der definierte Zeitpunkt kann beispielsweise in Abhängigkeit eines definierbaren zyklischen Zeitpunkts festgelegt werden und/oder in Abhängigkeit von verfügbaren Speicherkapazitäten einer für die Daten vorgesehenen Speichereinheit festgelegt werden. Es kann somit zum Beispiel nachdem ein bestimmtes Speichervo- lumen/Speicherkapazität belegt ist (definierter Zeitpunkt) zum nächsten festgelegten zyklischen Zeitpunkt einer zeitli- chen Abfolge (zum Beispiel alle 5 Minuten) ein Übertragen der Daten an das Prüfsystem durchgeführt werden. In einer weiteren Ausführungsform der Erfindung ist der Zeit- punkt des Übertragens der Daten unabhängig vom Zeitpunkt des Ereignisses festgelegt. Der Zeitpunkt kann Teil einer perio- dischen zeitlichen Abfolge sein. So kann das Übertragen der Daten an das Prüfsystem und das anschließende Erstellen des aktualisierten Referenzbildes und das Analysieren des aktua- lisierten Referenzbildes zum Beispiel alle 5 Minuten durchge- führt werden. In diesem Fall findet das Übertragen der Daten an das Prüfsystem nicht eventbasiert statt, das Erfassen der Daten findet aber weiterhin eventbasiert (d.h. getriggert durch Eintreten eines Ereignisses) statt. In einer weiteren Ausführungsform der Erfindung ist der Zeit- punkt des Übertragens der Daten in Abhängigkeit einer verfüg- baren Speicherkapazität einer für die Daten vorgesehenen Speichereinheit festgelegt. Diese Option ist mit der zuvor genannten Ausführungsformen des definierten Zeitpunkts, wel- cher in Abhängigkeit von einem Eintreten eines definierbaren zyklischen Zeitpunkts festgelegt ist, kombinierbar. In einer weiteren Ausführungsform der Erfindung ist das Über- tragen der Daten an das Prüfsystem integritätsgesichert z.B. über MTLS (Mutual Transport Layer Security) durchführbar. In einer weiteren Ausführungsform der Erfindung ist das Ana- lysieren des aktualisierten Referenzbilds darauf ausgerich- tet, Schwachstellen der Container-Instanz zu identifizieren. Identifizierte Schwachstellen der Container-Instanz können anschließend behandelt und/oder beseitigt werden. In einer weiteren Ausführungsform der Erfindung wird, abhän- gig von einem Inputparameter, bei dem Erstellen des aktuali- sierten Referenzbilds der Container-Instanz eine Operation, die ein Hinzufügen eines zusätzlichen Dateisystems zu der Container-Instanz darstellt, nicht berücksichtigt. Der Inputparameter kann durch eine Eingabe eines Benutzers bereitgestellt werden. Ein zusätzliches Dateisystem kann durch eine zusätzlich verbundene Speichereinheit, wie eine Hardwareeinheit oder ein zusätzlich verbundenes Netzwerklauf- werk geschaffen werden. Diese Ausführungsform hat den Vorteil und technischen Effekt einer erhöhten Flexibilität des Einsatzes des Prüfsystems. Eine verbindliche Prüfung eines zusätzlich verbundenen Netz- werklaufwerks kann eine hohe Komplexität haben und somit op- tional erfolgen. Das zusätzlich verbundene Netzwerklaufwerk kann in Abhängigkeit von einer Eingabe eines Benutzers oder einem berechneten Inputparameter (zum Beispiel berechnet auf Basis von Effizienzparametern) berücksichtigt werden oder nicht berücksichtigt werden. Im Falle einer Nicht- Berücksichtigung kann die Komplexität des Analysierens durch das Prüfsystem geringer gehalten werden. In einer weiteren Ausführungsform der Erfindung werden die Daten vor dem Übertragen an das Prüfsystem zwischengespei- chert. Neben dem direkten Übertragen der Daten an das Prüfsystem ist eine alternative Variante denkbar, bei der die Daten nicht sofort zum Prüfsystem übertragen werden, sondern auf einem lokalen Zwischenspeicher des darunterliegenden Hostsys- tems/Betriebssystem zwischenspeichert und erst zum Beispiel bei einem definierten Füllgrad des lokalen Zwischenspeichers, einem über die oben beschriebene Richtline hinterlegten Event/ Eintreten eines definierbaren zweiten Ereignisses (wie Änderungen auf der Container-Instanz, Änderungen eines Datei- systems der Container-Instanz, Schreiboperationen auf der Container-Instanz, System Calls, Modifikationen und/oder An- legen von Dateien und/oder Verzeichnissen, Installationsvor- gänge auf der Container-Instanz, Änderungen von Berechtigun- gen auf der Container-Instanz und/oder Änderungen von Dateien auf der Container-Instanz) oder nach Ablauf eines Intervalls an das Prüfsystem übertragen werden. Außerdem können so zum Beispiel in dem Fall, dass das Prüfsystem für mehrere Intervalle nicht erreichbar ist, Da- ten, die noch nicht an das Prüfsystem übertragen wurden, ge- sammelt werden und zu einem späteren Zeitpunkt gesammelt übertragen werden. Die Erfindung beansprucht außerdem ein System aufweisend: - eine Container-Instanz eines Betriebssystems eines Host- systems, wobei die Container-Instanz auf einer Laufzeitum- gebung gestartet ist, - ein Prüfsystem, wobei das Prüfsystem (4) außerhalb des Hostsystems (2) angeordnet ist, - eine erste Erfassungseinheit, wobei die erste Erfas- sungseinheit ausgebildet ist, ein initiales Referenzbild der Container-Instanz erfassen zu können und wobei das initiale Referenzbild ein Abbild der Container-Instanz ist, - eine Übermittlungseinheit, wobei die Übermittlungsein- heit ausgebildet ist, das initiale Referenzbild an ein Prüfsystem übermitteln zu können, - eine zweite Erfassungseinheit, wobei die zweite Erfas- sungseinheit ausgebildet ist, getriggert durch ein Eintre- ten eines Ereignisses Daten erfassen zu können, wobei sich das Ereignis sowie die Daten auf eine Operation auf der Container-Instanz beziehen, wobei die Operation eine tat- sächlich stattgefundene Operation darstellt und wobei die Daten, die Operation charakterisieren, - eine Übertragungseinheit, wobei die Übertragungseinheit ausgebildet ist, die Daten an das Prüfsystem übertragen zu können, und - eine Aktualisierungseinheit, wobei die Aktualisierungs- einheit ausgebildet ist, ein aktualisiertes Referenzbild der Container-Instanz erstellen zu können, wobei das aktua- lisierte Referenzbild durch Anpassen des initialen Refe- renzbilds bezüglich Effekten, die die Operation auf der Container-Instanz hat, erstellbar ist, wobei die Effekte zu erwartenden Effekte darstellen, welche die Operationen er- wartungsgemäß verursachen und wobei das Prüfsystem außerdem ausgebildet ist, das aktuali- sierte Referenzbild analysieren zu können. In einer weiteren Ausführungsform der Erfindung ist das er- findungsgemäße System ausgebildet, das erfindungsgemäße Ver- fahren durchführen zu können. KURZE BESCHREIBUNG DER ZEICHNUNGEN Die Besonderheiten und Vorteile der Erfindung werden aus den nachfolgenden Erläuterungen mehrerer Ausführungsbeispiele an- hand von schematischen Zeichnungen ersichtlich. Es zeigen Fig. 1 ein Ablaufdiagramm des erfindungsgemäßen Verfah- rens und Fig. 2 ein erfindungsgemäßes System. DETAILLIERTE BESCHREIBUNG DER ERFINDUNG Fig. 1 zeigt ein Ablaufdiagramm des erfindungsgemäßen Verfah- rens zur Analyse einer Container-Instanz (3, siehe Fig. 2) eines Betriebssystems eines Hostsystems (2, siehe Fig. 2), wobei die Container-Instanz (3) auf einer Laufzeitumgebung gestartet ist. Fig. 1 zeigt die folgenden Schritte: - Schritt S1: Erfassen eines initialen Referenzbilds der Container-Instanz (3), wobei das initiale Referenzbild ein Abbild der Container-Instanz (3) ist, - Schritt S2: Übermitteln des initialen Referenzbilds an ein Prüfsystem (4, siehe Fig. 2), - Schritt S3: Erfassen von Daten, wobei das Erfassen ge- triggert durch ein Eintreten eines Ereignisses durchgeführt wird und wobei sich das Ereignis sowie die Daten auf eine Operation auf der Container-Instanz (3) beziehen, wobei die Operation eine tatsächlich stattgefundene Operation dar- stellt und wobei die Daten, die Operation charakterisieren, - Schritt S4: Übertragen der Daten an das Prüfsystem (4), wobei das Prüfsystem (4) außerhalb des Hostsystems (2) an- geordnet ist, - Schritt S5: Erstellen eines aktualisierten Referenzbilds der Container-Instanz (3), wobei das aktualisierte Refe- renzbild durch Anpassen des initialen Referenzbilds bezüg- lich Effekten, die die Operationen auf der Container- Instanz (3) haben, erstellt wird, wobei die Effekte zu er- wartenden Effekte darstellen, welche die Operationen erwar- tungsgemäß verursachen und - Schritt S6: Analysieren des aktualisierten Referenzbilds durch das Prüfsystem (4). Schritt S1, das Erfassen des initialen Referenzbilds (S1) der Container-Instanz (3), kann durch eine Abfrage auf dem Be- triebssystem (2) erfolgen. Dies kann initial über eine Image- ID (Identifikation des Container-Image) des initialen Contai- ner-Image und die Instanz-ID (Identifikation der Container- Instanz) durchgeführt werden, welche ständig auf dem Hostsys- tem (z.B. über Bordmittel, d.h. über eigene Mittel der Con- tainer-Instanz Laufzeitumgebung oder Security-Tools) abge- fragt werden kann. Schritt S4, das Übertragen der Daten an das Prüfsystem (S4), ist integritätsgesichert, z.B. über MTLS (Mutual Transport Layer Security), durchführbar. Schritt S6, das Analysieren des aktualisierten Referenzbilds (S6), ist insbesondere darauf ausgerichtet, Schwachstellen der Container-Instanz (3) zu identifizieren. Bei Schritt S5, dem Erstellen des aktualisierten Referenz- bilds (S1) der Container-Instanz (3), können, abhängig von einem Inputparameter, Operationen, die ein Hinzufügen eines zusätzlichen Dateisystems zu der Container-Instanz (3) dar- stellen, nicht berücksichtigt werden. Die Daten können vor Schritt S4, dem Übertragen (S4) an das Prüfsystem (4), zwischengespeichert werden. Fig. 2 zeigt eine schematische Darstellung eines erfindungs- gemäßen Systems (1). Fig. 2 zeigt eine Container-Instanz (3) eines Betriebssystems eines Hostsystems (2), wobei die Container-Instanz (3) auf einer Laufzeitumgebung gestartet ist. Fig. 2 zeigt außerdem ein Prüfsystem (4), wobei das Prüfsys- tem (4) außerdem ausgebildet ist, ein später erstelltes aktu- alisiertes Referenzbild analysieren zu können und wobei das Prüfsystem (4) außerhalb des Hostsystems (2) angeordnet ist. Fig. 2 zeigt außerdem eine erste Erfassungseinheit (5), wobei die erste Erfassungseinheit (5) ausgebildet ist, ein initia- les Referenzbild der Container-Instanz (3) zu erfassen und wobei das initiale Referenzbild ein Abbild der Container- Instanz (3) ist. Fig. 2 zeigt außerdem eine Übermittlungseinheit (6), wobei die Übermittlungseinheit (6) ausgebildet ist, das initiale Referenzbild an das Prüfsystem (4) übermitteln zu können. Fig. 2 zeigt außerdem eine zweite Erfassungseinheit (7), wo- bei die zweite Erfassungseinheit (7) ausgebildet ist, getrig- gert durch ein Eintreten eines Ereignisses Daten erfassen zu können, wobei sich das Ereignis sowie die Daten auf eine Ope- ration auf der Container-Instanz (3) beziehen. Fig. 2 zeigt außerdem eine Übertragungseinheit (8), wobei die Übertragungseinheit (8) ausgebildet ist, die Daten an das Prüfsystem (4) übertragen zu können. Fig. 2 zeigt außerdem eine Aktualisierungseinheit (9), wobei die Aktualisierungseinheit (9) ausgebildet ist, das aktuali- sierte Referenzbild der Container-Instanz (3) erstellen zu können, wobei das aktualisierte Referenzbild durch Anpassen des initialen Referenzbilds bezüglich Effekten, die die Ope- ration auf der Container-Instanz (3) hat, erstellbar ist, wo- bei die Effekte zu erwartenden Effekte darstellen, welche die Operationen erwartungsgemäß verursachen. Das Prüfsystem (4) kann außerhalb der Container-Instanz (3) und außerhalb des Hostsystems (2) angeordnet sein. Das Ereignis und/oder die Operationen können Änderungen auf der Container-Instanz (3), Änderungen eines Dateisystems der Container-Instanz (3), Schreiboperationen auf der Container- Instanz (3), System Calls, Modifikationen und/oder Anlegen von Dateien und/oder Verzeichnissen, Installationsvorgänge auf der Container-Instanz (3), Änderungen von Berechtigungen auf der Container-Instanz (3) und/oder Änderungen von Dateien auf der Container-Instanz (3) umfassen. Das Ereignis und die Operationen können unterschiedlich oder gleich ausgeprägt sein. Obwohl die Erfindung im Detail durch die Ausführungsbeispiele näher illustriert und beschrieben wurde, ist die Erfindung durch die offenbarten Beispiele nicht eingeschränkt und ande- re Variationen können vom Fachmann daraus abgeleitet werden, ohne den Schutzumfang der Erfindung zu verlassen.
Bezugszeichenliste 1 System 2 Hostsystem 3 Container-Instanz 4 Prüfsystem 5 erste Erfassungseinheit 6 Übermittlungseinheit 7 zweite Erfassungseinheit 8 Übertragungseinheit 9 Aktualisierungseinheit 10 Speichereinheit S1 Erfassen eines initialen Referenzbilds S2 Übermitteln des initialen Referenzbilds S3 Erfassen von Daten S4 Übertragen der Daten S5 Erstellen eines aktualisierten Referenzbilds S6 Analysieren des aktualisierten Referenzbilds

Claims

Patentansprüche 1. Automatisiertes Verfahren zur Analyse einer Container- Instanz (3) eines Betriebssystems eines Hostsystems (2), wo- bei die Container-Instanz (3) auf einer Laufzeitumgebung ge- startet ist, aufweisend die Schritte: - Erfassen eines initialen Referenzbilds (S1) der Contai- ner-Instanz (3), wobei das initiale Referenzbild ein Abbild der Container-Instanz (3) ist, - Übermitteln des initialen Referenzbilds (S2) an ein Prüfsystem (4), - Erfassen von Daten (S3), wobei das Erfassen getriggert durch ein Eintreten eines Ereignisses durchgeführt wird und wobei sich das Ereignis sowie die Daten auf eine Operation auf der Container-Instanz (3) beziehen, wobei die Operation eine tatsächlich stattgefundene Operation darstellt und wo- bei die Daten, die Operation charakterisieren, - Übertragen der Daten (S4) an das Prüfsystem (4), wobei das Prüfsystem (4) außerhalb des Hostsystems (2) angeordnet ist, - Erstellen eines aktualisierten Referenzbilds (S5) der Container-Instanz (3), wobei das aktualisierte Referenzbild durch Anpassen des initialen Referenzbilds bezüglich Effek- ten, die die Operationen auf der Container-Instanz (3) ha- ben, erstellt wird, wobei die Effekte zu erwartenden Effek- te darstellen, welche die Operationen erwartungsgemäß ver- ursachen und - Analysieren des aktualisierten Referenzbilds (S6) durch das Prüfsystem (4).
2. Verfahren nach dem vorherigen Anspruch, dadurch gekennzeichnet, dass das Erfassen des initialen Referenzbilds (S1) der Container-Instanz (3) durch eine Abfrage auf dem Betriebs- system erfolgt.
3. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass das Ereignis und/oder die Operation eine Schreibope- ration auf der Container-Instanz (3) umfasst.
4. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass das Ereignis und die Operation unterschiedlich ausge- prägt sind.
5. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass der Zeitpunkt des Übertragens der Daten (S4) an das Prüfsystem (4) mit zeitlichem Abstand nach dem Eintreten des Ereignisses festgelegt ist.
6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass der Zeitpunkt des Übertragens der Daten (S4) unabhän- gig vom Zeitpunkt des Ereignisses festgelegt ist.
7. Verfahren nach Anspruch 5 oder 6, dadurch gekennzeichnet, dass der Zeitpunkt des Übertragens der Daten (S4) in Ab- hängigkeit einer verfügbaren Speicherkapazität einer für die Daten vorgesehenen Speichereinheit (10) festgelegt ist.
8. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass das Übertragen der Daten (S4) an das Prüfsystem (4) integritätsgesichert durchführbar ist.
9. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass das Analysieren des aktualisierten Referenzbilds (S6) darauf ausgerichtet ist, Schwachstellen der Container- Instanz (3) zu identifizieren.
10. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass, abhängig von einem Inputparameter, bei dem Erstellen des aktualisierten Referenzbilds (S1) der Container- Instanz (3) eine Operation, die ein Hinzufügen eines zu- sätzlichen Dateisystems zu der Container-Instanz (3) dar- stellt, nicht berücksichtigt wird.
11. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass die Daten vor dem Übertragen (S4) an das Prüfsystem (4) zwischengespeichert werden.
12. System (1) aufweisend: - eine Container-Instanz (3) eines Betriebssystems eines Hostsystems (2), wobei die Container-Instanz (3) auf einer Laufzeitumgebung gestartet ist, - ein Prüfsystem (4), wobei das Prüfsystem (4) außerhalb des Hostsystems (2) angeordnet ist, - eine erste Erfassungseinheit (5), wobei die erste Erfas- sungseinheit (5) ausgebildet ist, ein initiales Referenz- bild der Container-Instanz (3) erfassen zu können, wobei das initiale Referenzbild ein Abbild der Container-Instanz (3) ist, - eine Übermittlungseinheit (6), wobei die Übermittlungs- einheit (6) ausgebildet ist, das initiale Referenzbild an ein Prüfsystem (4) übermitteln zu können, - eine zweite Erfassungseinheit (7), wobei die zweite Er- fassungseinheit (7) ausgebildet ist, getriggert durch ein Eintreten eines Ereignisses Daten erfassen zu können, wo- bei sich das Ereignis sowie die Daten auf eine Operation auf der Container-Instanz (3) beziehen, wobei die Operati- on eine tatsächlich stattgefundene Operation darstellt und wobei die Daten, die Operation charakterisieren, - eine Übertragungseinheit (8), wobei die Übertragungsein- heit (8) ausgebildet ist, die Daten an das Prüfsystem (4) übertragen zu können, und - eine Aktualisierungseinheit (9), wobei die Aktualisie- rungseinheit (9) ausgebildet ist, ein aktualisiertes Refe- renzbild der Container-Instanz (3) erstellen zu können, wo- bei das aktualisierte Referenzbild durch Anpassen des ini- tialen Referenzbilds bezüglich Effekten, die die Operation auf der Container-Instanz (3) hat, erstellbar ist, wobei die Effekte zu erwartende Effekte darstellen, welche die Operationen erwartungsgemäß verursachen und wobei das Prüfsystem (4) außerdem ausgebildet ist, das ak- tualisierte Referenzbild analysieren zu können.
13. System nach Anspruch 12, wobei das System (1) ausgebildet ist, ein Verfahren nach einem der Ansprüche 1 bis 12 durch- führen zu können.
EP21704403.1A 2020-02-25 2021-01-21 Analyse einer container-instanz eines betriebssystems Pending EP4088183A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP20159204.5A EP3872661A1 (de) 2020-02-25 2020-02-25 Analyse einer container-instanz eines betriebssystems
PCT/EP2021/051262 WO2021170316A1 (de) 2020-02-25 2021-01-21 Analyse einer container-instanz eines betriebssystems

Publications (1)

Publication Number Publication Date
EP4088183A1 true EP4088183A1 (de) 2022-11-16

Family

ID=69742655

Family Applications (2)

Application Number Title Priority Date Filing Date
EP20159204.5A Withdrawn EP3872661A1 (de) 2020-02-25 2020-02-25 Analyse einer container-instanz eines betriebssystems
EP21704403.1A Pending EP4088183A1 (de) 2020-02-25 2021-01-21 Analyse einer container-instanz eines betriebssystems

Family Applications Before (1)

Application Number Title Priority Date Filing Date
EP20159204.5A Withdrawn EP3872661A1 (de) 2020-02-25 2020-02-25 Analyse einer container-instanz eines betriebssystems

Country Status (4)

Country Link
US (1) US12488114B2 (de)
EP (2) EP3872661A1 (de)
CN (1) CN115176230A (de)
WO (1) WO2021170316A1 (de)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3907637A1 (de) * 2020-05-05 2021-11-10 Siemens Aktiengesellschaft Verfahren und vorrichtung zur sicheren inbetriebnahme einer container-instanz
CN114205218B (zh) * 2021-12-16 2023-07-28 杭州谐云科技有限公司 一种容器网络故障的诊断方法和系统
EP4250154A1 (de) * 2022-03-25 2023-09-27 Siemens Aktiengesellschaft Verfahren zum sicheren betrieb einer softwarekomponente
US12554842B2 (en) * 2022-06-29 2026-02-17 International Business Machines Corporation Malware detection in containerized environments
US12580902B2 (en) * 2024-02-21 2026-03-17 Harness Inc Associating probe to a function in an encrypted connection initiated by the function

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8613080B2 (en) * 2007-02-16 2013-12-17 Veracode, Inc. Assessment and analysis of software security flaws in virtual machines
US8918785B1 (en) * 2010-12-29 2014-12-23 Amazon Technologies, Inc. Managing virtual machine network through security assessment
US9619262B2 (en) * 2011-05-31 2017-04-11 Micro Focus Software Inc. Techniques for security auditing of cloud resources
CN105580321A (zh) * 2013-09-27 2016-05-11 慧与发展有限责任合伙企业 转发日志行
US10503895B2 (en) * 2017-04-11 2019-12-10 Red Hat, Inc. Runtime non-intrusive container security introspection and remediation
US10963349B2 (en) * 2017-08-25 2021-03-30 Vmware, Inc. Containerized application snapshots
US20190108340A1 (en) * 2017-09-14 2019-04-11 Commvault Systems, Inc. Ransomware detection
US10885200B2 (en) * 2018-11-15 2021-01-05 International Business Machines Corporation Detecting security risks related to a software component
US11573861B2 (en) * 2019-05-10 2023-02-07 Cohesity, Inc. Continuous data protection using a write filter
US11481487B2 (en) * 2019-07-08 2022-10-25 Google Llc System and method of detecting file system modifications via multi-layer file system state
US11250136B2 (en) * 2019-10-22 2022-02-15 Cohesity, Inc. Scanning a backup for vulnerabilities
US11599643B2 (en) * 2019-10-30 2023-03-07 Rubrik, Inc. Facilitating analysis of software vulnerabilities

Also Published As

Publication number Publication date
US12488114B2 (en) 2025-12-02
CN115176230A (zh) 2022-10-11
US20230090689A1 (en) 2023-03-23
WO2021170316A1 (de) 2021-09-02
EP3872661A1 (de) 2021-09-01

Similar Documents

Publication Publication Date Title
WO2021170316A1 (de) Analyse einer container-instanz eines betriebssystems
DE69210399T2 (de) Rechnerueberwachungsverfahren und system
DE60017457T2 (de) Verfahren zur isolierung eines fehlers in fehlernachrichten
DE69706440T2 (de) Schutzmittel in einem verteilten rechnersystem
DE60311666T2 (de) Methode und vorrichtung zum bestimmen von potenziellem wurm-ähnlichen verhalten eines programmes
EP4187417B1 (de) Erkennen einer abweichung eines sicherheitszustandes einer recheneinrichtung von einem sollsicherheitszustand
EP4154139B1 (de) Erweiterte integritätsüberwachung eines containerabbildes
DE112012004247T5 (de) Passives Überwachen virtueller Systeme unter Verwendung einer erweiterbaren Indexierung
DE102008061480A1 (de) Verfahren und Vorrichtung zum Austauschen einer Komponente eines Computersystems
DE19617976A1 (de) Kommunikationssystem mit Mitteln zum Austausch von Softwareprozessen
DE112014002877T5 (de) Passives Überwachen von virtuellen Systemen mithilfe von agentenunabhängiger, echtzeitnaher Indexierung
DE102022210264A1 (de) Verfahren zur Erkennung von potenziellen Datenexfiltrationsangriffen bei wenigstens einem Softwarepaket
EP1563384A2 (de) Verfahren und system zum erzeugen einer grafischen benutzeroberfläche zum bedienen, zum konfigurieren und/oder zur diagnose eines elektrofotografischen druckersoder kopierers
DE10324384B3 (de) Behandlung eines Fehlerereignisses bei der Installation eines Anwendungsprogramms in einem tragbaren Datenträger
WO2023180083A1 (de) Verfahren zum sicheren betrieb einer softwarekomponente
EP4187423A1 (de) Durchsetzung von integritätsbedingungen einer ersten container-basierten anwendung
DE10041082B4 (de) Verfahren zum Aufzeichnen der Kommunikation zwischen einem Client und einem Server
EP3767503B1 (de) Verfahren und testumgebung zur bereitstellung einer anwendung für eine computergesteuerte komponente
EP4610755A1 (de) Verfahren zum gewähren von zugriff auf funktionalität in einem industriellen automatisierungssystem, computerprogrammprodukt und industrielles automatisierungssystem
WO2023134910A1 (de) Automatische, sicherheitsbedingte verlagerung mindestens einer containerinstanz
DE10055118A1 (de) Offenbarendes Verfahren zur Überwachung ausführbarer oder interpretierbarer Daten in digitalen Datenverarbeitungsanlagen mittels gerätetechnischer Einrichtungen
EP4708768A1 (de) Verfahren und anordnung zur anpassung von zugriffsrechten industrieller anwendungen
EP4603995A1 (de) Verfahren und system zum sicheren betrieb einer container-implementierten softwarekomponente
EP1739559A2 (de) Behandlung von Fehlerereignissen bei einem tragbarem Datenträger
DE102022204717A1 (de) Verfahren zum Testen eines Computerprogramms

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20220809

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20251124