Method of producing honeypot

Abstract

To provide an approach which allows an appropriate honeypot to be provided (especially, set) more easily.SOLUTION: According to various embodiments, a method of producing a honeypot comprises the steps of: transmitting a message to a target system; observing a reaction of the target system to the message; generating a state machine model for one or more interfaces of the target system depending on the observed reaction of the target system; determining, for each weak point of one or more known weak points, a chain of states which allows the weak point to be used when being traced, of the state machine model; removing, for each weak point of the one or more weak points, at least one state of this chain from the state machine model; and producing a honeypot which reacts to the message depending on the state machine model.SELECTED DRAWING: Figure 3

Description

Technical Field

[0001] The present disclosure relates to a method for generating a honeypot.

Background Art

[0002] The number of networked data processing devices (including embedded devices) is increasing rapidly. Whether it is a server computer on the Internet or a control mechanism in the automotive or IoT fields, an important aspect of all these devices is the safety of the product. A honeypot is a replica that mimics such a valuable (target) system in order to attract attackers and obtain information about their attack strategies and targets. Especially in enterprise IT, honeypots are established tools for threat analysis and are now also used in the field of the Internet of Industrial Things ((I)IoT). Although honeypots are very useful tools for supplementing cyber security strategies, the implementation of appropriate honeypots for individual needs and each target system requires a fair amount of manual work by experts.

Summary of the Invention

Problems to be Solved by the Invention

[0003] Therefore, an approach that enables easier provision (especially configuration) of appropriate honeypots is desirable.

Means for Solving the Problems

[0004] A method for generating a honeypot, based on various embodiments, comprising the steps of sending a message to a target system, observing the target system's reaction to the message, generating a state machine model for one or more interfaces of the target system according to the observed reaction of the target system, for each of one or more known vulnerabilities, respectively determining a chain of states that enables the exploitation of this vulnerability when traced in the state machine model, for each of one or more vulnerabilities, removing at least one state of this chain from the state machine model, and generating a honeypot that reacts to the message according to this state machine model.

[0005] The method described above enables full automation of the honeypot implementation process, including settings such as automatically inheriting the behavior of one specific operating system (e.g., one specific version) from multiple different operating systems (versions). For example, this can control and improve the coverage of shell interactions (which are of interest and should be monitored, for example).

[0006] Using the state machine model, the honeypot mimics, for example, an operating system including a command line interface, and / or an application, a network interface, and / or any type of API (Application Programming Interface). Thus, the method described above enables the simulation of complex system environments such as a command line interface (and enables the automatic adaptation of the complex system environment to the target system, resulting in the imitation of this target system).

[0007] At that time, by removing the determined system states (hereinafter also referred to as "filtering" of the state machine model), the risk that an attacker exploits the honeypot (e.g., for an attack on a third-party system) is minimized (or at least significantly reduced). Since complex systems tend to provide relatively powerful tools to attackers, this can prevent attackers from using the honeypot against third parties. In this regard, the state machine model is filtered, for example, so as not to interfere with the attacker's attack path until the third party is affected (e.g., states where communication with a third-party system occurs, which directly implies a crisis for the third-party system, are removed).

[0008] Various exemplary embodiments are presented below. Exemplary embodiment 1 is a method for generating a honeypot as described above. Exemplary embodiment 2 is a method based on exemplary embodiment 1. In this case, for each of one or more vulnerabilities, among the chains of respective states, the state that blocks the exploitation of the vulnerability is determined and removed from the state machine model. At that time, as this state, the one that is as far back as possible within the chain of states (i.e., requires as many interactions with the honeypot as possible to reach it), provided that no damage has been caused when it is reached, is determined.

[0009] This ensures that the attacker is guaranteed to engage with the honeypot for as long as possible without causing damage or can do so. Exemplary embodiment 3 is a method based on exemplary embodiment 1 or 2. In this case, for each of one or more vulnerabilities, among the chains of respective states, the state where communication with a third-party system (i.e., a data processing device different from the attacker's or the honeypot's data processing device) occurs when it is reached is determined and removed from the state machine model.

[0010] This prevents a third - party system from being attacked via the honeypot. Exemplary embodiment 4 is a method based on one of exemplary embodiments 1 - 3, where a pre - generated state machine model for another target system is adapted according to the observed reaction of the target system, thereby generating a state machine model.

[0011] Thereby, the state machine model can be efficiently generated, especially when honeypots are generated for various target systems. Exemplary embodiment 5 is a method based on exemplary embodiment 4, where a query and / or another query is sent to another target system, the reaction of the other target system to this query or another query is observed, and another state machine model is generated according to the observed reaction of the other target system, thereby generating another state machine model.

[0012] That is, according to one embodiment, the state machine is learned based on a two - step procedure. Specifically, first, the state machine is learned for a "base" target system (i.e., "another" target system), and this state machine is then adapted for the original target system. In this case, the state machine model for the base target system can be adapted for various target systems. What should be noted is that in the method comprehensively described above, the "base" target system can be applied to the "target system", and the generation of the honeypot that responds to the query according to the state machine model further includes a step of adapting to the target system within this step. In this interpretation, when the original target system (of the honeypot) and the base target system are not very different from each other (for example, when only the version number or other output information is adapted), the honeypot responds to the query "according to the state machine model" despite the adaptation. However, in this case, the honeypot is for the original target system, not for the base target system to which the query was sent.

[0013] For example, a complex system such as an operating system shell is much larger in scale than, for example, network services. According to one embodiment, during adaptation, it is determined which parts of the honeypot must be closely adapted to each critical target system and which parts can be inherited from the base version. This reduces the effort for version adaptation and provides the possibility of quickly reacting to attacks with unknown (newly known) functions or quickly adapting the honeypot to a new version (of the operating system and / or interface).

[0014] Exemplary embodiment 6 is a method based on exemplary embodiment 4 or 5, where adaptation of another state machine model involves adapting the version of one or more interfaces having the behavior modeled by this other state machine model according to the observed reaction of the target system.

[0015] In some cases, the other state machine model may be changed only slightly by supplementing, for example, the specificity of the version of one or more interfaces provided by the target system to this other state machine model.

[0016] Exemplary embodiment 7 is a method based on one of exemplary embodiments 4 to 6, where the other state machine model is selected from another target system or a number of other state machine models for one or more other target systems based on a check of whether this other state machine model fulfills the functions required for mimicking the target system.

[0017] Exemplary embodiment 8 is a method based on one of exemplary embodiments 1 to 7, where during generation of the state machine model, information to be kept secret about the target system is removed from the state machine model based on the secrecy criterion.

[0018] That is, the state machine model can be filtered with respect to information that should be kept secret (e.g., passwords, and also the operator of the honeypot) in order to avoid, for example, security issues regarding the target system (e.g., by known passwords).

[0019] Exemplary embodiment 9 is a honeypot generation mechanism adapted to implement a method based on one of exemplary embodiments 1 - 8. Exemplary embodiment 10 is a computer program having instructions that, when executed by a processor, cause the processor to implement a method based on one of exemplary embodiments 1 - 8.

[0020] Exemplary embodiment 11 is a computer - readable medium storing instructions that, when executed by a processor, cause the processor to implement a method based on one of exemplary embodiments 1 - 8.

[0021] In the drawings, like reference numerals generally refer to the same parts throughout all the various figures. The drawings are not necessarily to scale, and instead generally focus on depicting the principles of the present invention. In the following description, various aspects will be described with reference to the following drawings.

Brief Description of the Drawings

[0022]

Figure 1

Figure 2

Figure 3

Modes for Carrying Out the Invention

[0023] The following detailed description is related to the accompanying drawings, which, for purposes of illustration, show individual details and aspects of the present disclosure that can be used to explain the present invention in detail. Without departing from the scope of protection of the present invention, other aspects can be used, and structural, logical, and electrical changes can be implemented. Since some aspects of the present disclosure can be combined with one or more other aspects of the present disclosure to form new aspects, the various aspects of the present disclosure are not necessarily mutually exclusive.

[0024] The following will explain various examples more precisely. FIG. 1 shows a computer network 100. The computer network 100 includes a number of data processing devices 101 to 105 interconnected by communication connections. The data processing devices 101 to 105 include, for example, a server computer 101 and a control device 102 as well as user terminal devices 103, 104.

[0025] The server computer 101 provides various services such as web pages, banking portals, etc. The control device 102 is, for example, a control mechanism for a robotic device, such as a control mechanism in an autonomous vehicle. That is, the server computer 101 and the control mechanism 102 perform various tasks and can typically be accessed by the user terminal devices 103, 104 to the server computer 101 or the control device 102. This is especially the case when the server computer 101 provides functions such as a banking portal to the user. However, the control device 102 can also enable external access (for example, in order for the control device 102 to be configured). Depending on the tasks of the server computer 101 or the control device 102, they can store data related to security and perform tasks related to security. Therefore, they must be protected against attackers. For example, an attacker using one of the user terminal devices 104 may obtain secret data (such as a key) through an effective attack, may tamper with an account, or may even tamper with the control device 102 to cause an accident.

[0026] A security measure against such attacks is a so-called honeypot 106 (implemented by one of the data processing devices 105). The honeypot 106 serves as bait to mislead into providing a function and attracting potential attackers. However, the attacker is isolated from secret information or critical functions, so attacks on the honeypot 106 are carried out in a controlled environment, minimizing the risk of damage to the original function. Thus, the honeypot 106 enables the acquisition of knowledge about attacks on the target system (such as one of the server computers 101 or one of the control devices 102), and thus the threat landscape, and the threat landscape can be reacted to by implementing appropriate measures on the target system, without the attack exposing the target system to danger.

[0027] That is, the honeypot is a decoy system that mimics the target system (also referred to as a "high-value target"). The honeypot tempts the attacker to attack the honeypot, revealing the attack vectors aimed at the real high-value target. Thus, for example, a web server (or the software of a web server) is a preferred option to be mimicked by the honeypot. Since web servers make up most of the public Internet, it is important to continuously monitor the threats targeting them.

[0028] In particular, for the automotive industry, the honeypot is interesting because there is little data on real attacks. Thus, the honeypot 106 can be implemented, for example, in a vehicle based on various embodiments. In this case, the computer network 100 can include at least partially the internal network of the vehicle (as well as a network establishing a connection from the outside to the vehicle, such as a mobile wireless network).

[0029] However, when setting up a honeypot manually, the implementation of appropriate honeypots for individual requirements and each target system requires a significant amount of manual work by respective experts. For example, to mimic a target system running the Debian operating system, the honeypot developer has to manually implement shell commands that reflect the functionality of Debian, including their interaction with the file system. Therefore, developers often implement only a subset of the commands that they expect an attacker to use. To mimic another operating system such as Windows or Ubuntu, the developer has to newly implement all the command-line interactions manually to mimic the desired operating system.

[0030] Therefore, based on various embodiments, an approach is provided that enables, for the implementation of a honeypot, automatic inheritance (i.e., automatic generation of a honeypot by implementing an interface based on a learned state machine) of any implementation and version of various interfaces (especially operating system interfaces such as command-line interfaces) by a learned state machine.

[0031] The state machine of a program or software (especially its interface) can be learned by using appropriately formulated inputs (i.e., generally messages to the interface) and observing the resulting outputs (i.e., responses). The learning of the state machine can be classified into two dimensions, namely activity and visibility. In terms of activity, there are active and passive learning algorithms. Passive algorithms only learn from the observation of data traffic, for example, recorded data traffic between a client and a server, while active algorithms can send new queries to a server, for example, to discover more states. To ensure visibility, the learning algorithm works in a black-box setting, a gray-box setting, or a white-box setting. In the white-box setting, everything in the software and code is visible to the algorithm. Thus, the learning of the state machine can proceed with the help of additional static analysis tools. In the black-box setting, one can only create messages to the learning target and observe the responses of the learning target, without knowing the internal structure of the software in any form. In the gray-box setting, generally, lightweight instrumentation is compiled into the learning target, thereby obtaining some additional coverage information during execution and facilitating state estimation.

[0032] Figure 2 specifically shows the generation of a honeypot based on one embodiment. The following components are involved. Target system 201 of non-critical examples: The states of the base state machine 202, which will later be adapted to the state machine 203 for each target system 204, are learned by examining one or more target systems 201 of non-critical examples. This target system 201 of non-critical examples uses, for example, an operating system simulated by the generated honeypot 205 (although in some cases it may not be the correct version).

[0033] State Machine 203 for Target System 204: A derived state machine that models a complex system such as the operating system of target system 204. Instead, this operating system may be estimated as one of a group of state machines.

[0034] Data Bank for Target System 204 or Information about Target System 204: The base state machine 202 is adapted to the target system 204 that the honeypot 205 should mimic.

[0035] Data Bank 206 of Honeypot Records (e.g., Protocols, English: Logs): This data bank contains information about previous honeypot recognitions (i.e., among other things, attacks executed on other honeypots). Based on this information, the priorities of components and functions to be simulated by the honeypot can be derived.

[0036] Data Bank 207 of Attack Traces (English: traces): This data bank stores the protocols and traces of actual attacks. These can also be used for prioritizing components and functions to be simulated by the honeypot.

[0037] Data Bank 208 of Security Holes: A data bank of vulnerabilities for all types of operating systems, e.g., National Vulnerability Database (NVD).

[0038] The determination of the settings for the honeypot (and in some cases also the selection of the architecture to be set for the honeypot) is performed by the honeypot generation mechanism (or the honeypot setting mechanism), and the honeypot generation mechanism corresponds to, for example, one of the user terminal devices 104 (for example, a computer that a user (such as a system administrator) uses to set the honeypot 106 and to instruct the data processing device 105 to provide the honeypot 106 set in this way). That is, the honeypot generation method described here is implemented, for example, by such a honeypot generation mechanism (for example, automatically).

[0039] For example, the following steps are performed. At 209, based on the target system 201 (or a plurality thereof) of non-critical examples, the base state machine 202 is determined (for example, by observing the response of the target system 201 of non-critical examples by a message sent to the target system 201 (for example, by the honeypot generation mechanism)).

[0040] At 210, in order to check whether the base state machine 202 (or, for example, a plurality of such base state machines 202 for a plurality of target systems 201 or a plurality of components) functions correctly, that is, whether each complex system is modeled in a reliable and convincing manner, dynamic testing and static inspection are performed.

[0041] At 211, based on the information about the target system 204, the version compatibility of each (for example, appropriately selected) base state machine 202 is performed. At that time, in order to sort the system components and determine which components are to be simulated within the honeypot 205, prioritization (e.g., by means of a weighting mechanism) can be used based on the data bank 206 of the honeypot records and the data bank 207 of the attack traces. Since it is much more difficult to learn an automaton for a complete system or an automaton of automata, this prioritization makes it possible to reduce the effort by selecting which components to consider, for example which seldom-used components to consider. Thereby, resources in the form of computing power, for example, can also be used as intended for learning a more detailed version of the determined components instead of less important components.

[0042] In 212, sensitive (e.g., secret or brand-damaging) data is removed because the base state machine 202 is adapted based on the critical target system. The result is a version-adapted (and filtered with respect to sensitive data) state machine 203.

[0043] In 213, states that enable the exploitation of (known) vulnerabilities are removed from the version-adapted state machine 203, i.e., states that are in a bad state. State transitions to such bad states can also be removed. For example, states related to communication with third parties are removed (e.g., communication with a third-party system is carried out in this state). Thereby, it can be prevented that an attacker attacks a third party via the honeypot 205.

[0044] This filtering may already be carried out (at least partially) before version adaptation. At 214, a weakness (optionally) is inserted: A selected known weakness may be introduced into the version - compliant (and filtered with respect to sensitive data) state machine 203 to further entice an attacker to explore the honeypot 205. Since the state machine is not a real operating system (and since the version - compliant state machine 203 is filtered), this does not pose an additional risk.

[0045] At 215, within the honeypot 205, i.e., within the container, this thus - generated state machine (i.e., the version - compliant state machine 203 processed as described above) that mimics a complex operating - system environment such as the target system 204, e.g., the shell of a system, is used to collect data about the attacker's procedure against the critical system. For this purpose, the generated state machine is placed, for example, into a honeypot framework that provides the honeypot 205, and in so doing, additional (e.g., user - defined) configuration data 216 may be taken into account. The state machine simulates the complex system that the honeypot 205 mimics.

[0046] In summary, based on various embodiments, a method as shown in FIG. 3 is provided. FIG. 3 shows a flowchart 300 representing a method for generating a honeypot according to one embodiment.

[0047] At 301, a message (such as a shell command, a network packet, an application - specific query, etc.) is sent to the target system. At 302, the target system's reaction to this message is observed.

[0048] In 303, a state machine model for one or more interfaces (command line interface, network interface, API, etc.) of the target system is generated according to the observed reactions of the target system (i.e., a state machine that models one or more interfaces (or their behaviors)).

[0049] In 304, for each of one or more known vulnerabilities, a chain of states that enables the exploitation of this vulnerability when traced in the state machine model is determined respectively.

[0050] In 305, for each of one or more vulnerabilities, at least one state of this chain is removed from the state machine model (i.e., among this chain, the state that breaks this chain is determined, and this state is removed, for example, removed as far back as possible within the chain).

[0051] In 306, a honeypot is generated, and this honeypot reacts to messages according to the state machine model (as the honeypot is brought about from 305). In other words, based on various embodiments, a state machine for one or more components (operating system, software program) of the target system (and thus possibly a very complex system in some cases) is determined and used as a basis for the automatic generation of a honeypot. For example, one or more state machines of the system environment of, for example, the command line interface of an operating system (OS) are estimated. Then, the one or more (estimated) state machines brought about based on it can be used for one or more interactive honeypots. The porting and adaptation of this estimated state machine, that is, making it appear to have a specific operating system version or system version, can be done automatically.

[0052] The method of FIG. 3 can be implemented by one or more computers having one or more data processing units. The term "data processing unit" can be understood as any type of entity that enables the processing of data or signals. The data or signals can be processed, for example, based on at least one (i.e., one or more than one) individual function performed by the data processing unit. The data processing unit can include, or be formed from, analog circuits, digital circuits, logic circuits, microprocessors, microcontrollers, central units (CPUs), graphics processing units (GPUs), digital signal processors (DSPs), field-programmable gate array integrated circuits (FPGAs), or any combination thereof. Any other way of implementing each of the functions described relatively precisely here may be understood as a data processing unit or a logic circuit device. One or more of the process steps described in detail here can be executed (e.g., implemented) by the data processing unit by one or more individual functions performed by the data processing unit.

[0053] That is, this method is implemented on a computer, among other things, based on various embodiments.

Description of Reference Numerals

[0054] 100 Computer network 101 Server computer, data processing device 102 Control device, data processing device 103 User terminal device, data processing device 104 User terminal device, honeypot generation mechanism, data processing device 105 Data processing device 106, 205 Honeypot 201 Another target system 202 Another state machine model 203 State machine model 204 Target system 206 Data bank for recording of honeypots 207 Attack Trace Data Bank 208 Security Hole Data Bank 216 Setting Data

Claims

Claim 1 A method for generating a honeypot (106, 205), comprising: sending a message to a target system (204) (step 301); observing the reaction of the target system (204) to the message (step 302); generating a state machine model (203) for one or more interfaces of the target system (204) according to the observed reaction of the target system (204) (step 303); for each of one or more known vulnerabilities, respectively determining a chain of states in the state machine model (203) that enables exploitation of the vulnerability when traced (step 304); for each of the one or more vulnerabilities, removing at least one state of the chain from the state machine model (203) (step 305); generating a honeypot (106, 205) that reacts to messages according to the state machine model (203) (step 306). A method having the above steps. Claim 2 For each of the one or more vulnerabilities, a state that prevents exploitation of the vulnerability is determined and removed from the state machine model (203) within the chain of states for each vulnerability. At this time, as the state, a state that is as far back as possible within the chain of states but has not yet caused damage when reached is determined. The method according to claim 1. Claim 3 For each of the one or more vulnerabilities, a state in the chain of states for each vulnerability where communication with a third party system is performed when reached is determined and removed from the state machine model (203). The method according to claim 1 or 2. Claim 4 The state machine model (203) is generated by adapting a pre-generated another state machine model (202) for another target system (201) according to the observed reaction of the target system (204). The method according to any one of claims 1 to 3. Claim 5 Sending a query and / or another query to the other target system (201), observing a reaction of the other target system (201) to the query or the other query, and generating the other state machine model (202) according to the observed reaction of the other target system (201), wherein the other state machine model (202) is generated, the method according to claim 4.

6. The adaptation of the other state machine model (202) includes adapting the version of the one or more interfaces having the behavior modeled by the other state machine model (202) according to the observed reaction of the target system (204), the method according to claim 4 or 5.

7. The other state machine model (202) is selected from a number of other state machine models (202) for the other target system (201) or one or more other target systems (201) based on a check of whether the other state machine model (202) fulfills the functions necessary for emulating the target system (204), the method according to any one of claims 4 to 6.

8. During the generation of the state machine model (203), information to be kept secret about the target system (204) is removed from the state machine model (203) based on a confidentiality criterion, the method according to any one of claims 1 to 7.

9. A honeypot generation mechanism (104) adapted to implement the method according to any one of claims 1 to 8.

10. A computer program having instructions that, when executed by a processor, cause the processor to implement the method according to any one of claims 1 to 9.

11. A computer-readable medium storing instructions that, when executed by a processor, cause the processor to implement the method according to any one of claims 1 to 9.

Images