Procedure for configuring a honeypot

The described procedure automates honeypot configuration and iterative improvement using reinforcement learning, addressing the manual effort challenge and enhancing honeypot effectiveness for threat analysis.

DE102023209601A1Pending Publication Date: 2025-04-03ROBERT BOSCH GMBH
View PDF 0 Cites 1 Cited by

Patent Information

Application Number
DE102023209601
Authority / Receiving Office
DE · DE
Patent Type
Applications
Current Assignee / Owner
Filing Date
2023-09-29
Publication Date
2025-04-03

AI Technical Summary

Technical Problem

The implementation of honeypots requires significant manual effort by experts, making it desirable to simplify the configuration process.

Method used

A procedure for configuring a honeypot involves automatic configuration, observation of attacks, evaluation, and iterative improvement based on attack ratings, using reinforcement learning to enhance honeypot attractiveness for attackers.

Benefits of technology

Enables continuous self-improvement of honeypot configurations, maximizing attacker engagement and providing valuable threat analysis data with reduced manual intervention.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 00000000_0000_ABST
    Figure 00000000_0000_ABST
Patent Text Reader

Abstract

According to various embodiments, a method for configuring a honeypot is described, comprising configuring a honeypot according to a first configuration, deploying the honeypot in a computer network, observing and evaluating attacks on the honeypot carried out by one or more attackers via the computer network, evaluating the first configuration based on the evaluations of the attacks carried out by the one or more attackers on the honeypot, changing the configuration of the honeypot to a second configuration, carrying out attacks on the honeypot configured according to the second configuration, imitating the attacks carried out by the one or more attackers, and evaluating the attacks carried out on the honeypot configured according to the second configuration.Evaluating the second configuration based on the attack evaluations and determining a honeypot configuration based on a comparison of the evaluation of the first configuration with the evaluation of the second configuration.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] The present disclosure relates to methods for configuring a honeypot.

[0002] The number of networked computing devices (including embedded devices) is increasing rapidly. A key aspect of all these devices—be they server computers on the internet or control devices in the automotive or IoT sectors—is product security. Honeypots are decoys that mimic such valuable (target) systems to lure attackers and gather information about their attack strategies and objectives. Honeypots are an established threat analysis tool, especially in corporate IT, and they are now also being used in the (Industrial) Internet of Things (IoT). Although honeypots are a very useful tool to complement cybersecurity strategies, implementing suitable honeypots for specific needs and target systems requires considerable manual work by experts.

[0003] Approaches that enable easier deployment (especially configuration) of a suitable honeypot are therefore desirable.

[0004] According to various embodiments, a method for configuring a honeypot is provided, comprising: • Configuring a honeypot according to an initial configuration; • Deploying (i.e. in particular implementing) the honeypot configured according to the first configuration in a computer network; • Observing and evaluating (“real”) attacks on the honeypot configured according to the first configuration that one or more attackers carry out on the honeypot configured according to the first configuration via the computer network; • Evaluating the first configuration depending on the evaluations of the attacks carried out by one or more attackers on the honeypot configured according to the first configuration; • Changing the honeypot configuration from the first configuration to a second configuration; • Carrying out attacks on the honeypot configured according to the second configuration, imitating the attacks carried out by the one or more attackers (i.e., “reenacting” or “repeating” attacks); • Evaluate the attacks carried out on the honeypot configured according to the second configuration; • Evaluating the second configuration depending on the scores of the attacks carried out on the honeypot configured according to the second configuration; and • Determining a configuration of the honeypot depending on a comparison (ie the comparison result) of the evaluation of the first configuration with the evaluation of the second configuration.

[0005] The above procedure can also be performed iteratively, i.e., the configuration is then changed to a third configuration, which is evaluated analogously to the second configuration above, and the evaluation of the third configuration is compared with the second configuration, and so on. In this case, the attacks observed on the honeypot configured according to the first configuration can be imitated to evaluate the honeypot configured according to the third configuration, and (real) attacks that were executed (and observed) on the honeypot configured according to the second configuration can also be imitated.

[0006] In other words, according to various embodiments, real attacks are collected in a pool of real attacks (referred to below as "real attack registration" in the exemplary embodiment), and attacks are executed from this pool for various configurations of the honeypot (i.e., previous real attacks are imitated, e.g., as dynamic or static attacks (or also tests or checks such as port scans)). When new attacks occur, a score is calculated for them based on the configuration. Previous attacks are also run through, since the attacks may have different effects depending on the configuration.

[0007] The procedure described above enables a continuous improvement of the configuration of a honeypot (i.e., a self-improving honeypot configuration): a “fitness” (i.e., rating) of a honeypot (for different configurations) is determined and, based on this, the configuration of the honeypot is improved (i.e., adapted) to make it more attractive to real attackers.

[0008] Initially, the honeypot can also be generated automatically.

[0009] According to various embodiments, the method described above enables automatic honeypot configuration to maximize attackers' interest and attention through feedback in the form of information about real attacks on the honeypot, e.g., by measuring attackers' investment in attacks on the honeypot using real-world data. This allows for iterative self-improvement of the deployed honeypot configuration.

[0010] Various examples of implementation are given below.

[0011] Embodiment 1 is a method for configuring a honeypot as described above.

[0012] Embodiment 2 is the method of Embodiment 1, wherein each of the attacks is evaluated according to a metric that assesses a credibility of the success of the attack on the honeypot.

[0013] For example, attacks shouldn't be too successful, as otherwise the honeypot won't be credible to an attacker. In other words, the credibility with which the honeypot responds to the attack is assessed.

[0014] Embodiment 3 is the method of Embodiment 1 or 2, wherein each of the attacks is evaluated according to a metric that evaluates an attractiveness of the attack on the honeypot.

[0015] Attacks should be attractive so that an attacker will continue to pursue such an attack for as long as possible (e.g., stay on the system for a longer time or repeat the attack or carry out similar attacks), and thus as much information as possible can be obtained about the attackers' actions.

[0016] Embodiment 4 is the method according to one of the embodiments 1 to 3, comprising observing and evaluating ("real") attacks on the honeypot configured according to the second configuration, which the one or more attackers carry out on the honeypot configured according to the second configuration via the computer network, and evaluating the second configuration further depending on the evaluations of the attacks carried out on the honeypot configured according to the second configuration by the one or more attackers.

[0017] Not only are previous real attacks imitated, but also new (real) attacks that occur are observed in order to evaluate the changed (i.e., the second) configuration.

[0018] Embodiment 5 is the method according to one of the embodiments 1 to 4, comprising performing several iterations, comprising, in each iteration, • Deploying the honeypot configured according to a respective first configuration in the computer network; • Observing and evaluating (“real”) attacks on the honeypot configured according to the respective first configuration, which one or more attackers carry out on the honeypot configured according to the first configuration via the computer network; • Evaluating the respective initial configuration depending on the evaluation of the attacks carried out by the one or more attackers on the honeypot configured according to the respective initial configuration; • Changing the configuration of the honeypot from the respective first configuration to a respective second configuration; • Carrying out attacks on the honeypot configured according to the respective second configuration, imitating the attacks carried out by the one or more attackers from the current iteration and / or from one or more previous iterations; • Evaluate the attacks carried out on the honeypot configured according to the respective second configuration; and • Evaluating the respective second configuration depending on the evaluations of the attacks carried out on the honeypot configured according to the second configuration; and

[0019] Determining a configuration of the honeypot depending on the comparisons (i.e. the comparison results) of the evaluation of the respective first configuration with the evaluation of the respective second configuration.

[0020] This allows the honeypot's configuration to be optimized over several iterations, e.g., using a reinforcement learning (RL) method, where the actions are the configuration changes. A suitably trained RL agent could then also be used to configure additional honeypots.

[0021] Embodiment 6 is the method according to embodiment 5, comprising using the respective second configuration as the first configuration for a subsequent iteration or as the final configuration for the honeypot if the respective second configuration was rated better than the respective first configuration and using the respective first configuration as the first configuration for a subsequent iteration or as the final configuration for the honeypot if the respective first configuration was rated better than the respective second configuration.

[0022] In this way, the configuration of the honeypot is successively improved (e.g., until a termination criterion is reached, where the last better configuration is chosen as the final configuration).

[0023] Embodiment 7 is the method according to any one of embodiments 1 to 6, wherein each configuration is evaluated depending on the ratings of the attacks carried out on the honeypot configured according to the configuration by weighted averaging the ratings of the attacks carried out on the honeypot configured according to the configuration, wherein for each attack the respective rating is weighted depending on a target of the attack.

[0024] For example, the honeypot's configuration can be determined in such a way that the assessment of attacks on elements of the target system that the honeypot is intended to imitate that are of particular interest, e.g. certain APIs, services or applications, are given particular weight (and thus, for example, these elements are simulated particularly credibly by the honeypot), by giving them a higher rating when calculating the assessment of the honeypot's configuration than other elements that are of lesser interest.

[0025] Embodiment 8 is a honeypot configuration device configured to carry out the method according to one of the embodiments 1 to 7.

[0026] Embodiment 9 is a computer program including instructions that, when executed by a processor, cause the processor to perform a method according to any one of embodiments 1 to 7.

[0027] Embodiment 10 is a computer-readable medium storing instructions that, when executed by a processor, cause the processor to perform a method according to any one of embodiments 1 to 7.

[0028] In the drawings, like reference characters generally refer to the same parts throughout the several views. The drawings are not necessarily to scale, emphasis instead generally being placed upon illustrating the principles of the invention. In the following description, various aspects are described with reference to the following drawings. Fig. 1 shows a computer network. Fig. 2 illustrates the configuration of a honeypot according to one embodiment. Fig. 3 shows a flowchart illustrating a method for configuring a honeypot according to one embodiment.

[0029] The following detailed description refers to the accompanying drawings, which, by way of illustration, show specific details and aspects of this disclosure in which the invention may be practiced. Other aspects may be utilized, and structural, logical, and electrical changes may be made without departing from the scope of the invention. The various aspects of this disclosure are not necessarily mutually exclusive, as some aspects of this disclosure may be combined with one or more other aspects of this disclosure to form new aspects.

[0030] Various examples are described in more detail below.

[0031] Fig. 1 shows a computer network 100. The computer network 100 includes a plurality of data processing devices 101-105 interconnected by communication links. The data processing devices 101-105 include, for example, server computers 101 and control devices 102, as well as user terminals 103, 104.

[0032] Server computers 101 provide various services, such as websites, banking portals, etc. A control unit 102 is, for example, a control device for a robotic device such as a control device in an autonomous vehicle. The server computers 101 and control units 102 therefore perform various tasks, and typically a server computer 101 or a control unit 102 can be accessed from a user terminal 103, 104. This is particularly the case when a server computer 101 offers a user a functionality, such as a banking portal. However, a control unit 102 can also enable external access (e.g., so that it can be configured). Depending on the task of a server computer 101 or control unit 102, they can store security-relevant data and perform security-relevant tasks. Accordingly, they must be protected against attackers.For example, an attacker using one of the user terminals 104 could, through a successful attack, obtain secret data (such as keys), manipulate accounts, or even manipulate a control device 102 in such a way that an accident occurs.

[0033] One security measure against such attacks is a so-called honeypot 106 (implemented by one of the data processing devices 105). It supposedly provides functionality and thus serves as bait to attract potential attackers. However, it is isolated from secret information or critical functionality so that attacks on it take place in a controlled environment and the risk of compromising the actual functionality is minimized. It thus makes it possible to gain knowledge about attacks on a target system (e.g., one of the server computers 101 or one of the control units 102)—and thus the threat landscape—to which the implementation of suitable measures on the target system can respond without these attacks endangering the target system.

[0034] A honeypot is a deception system that mimics a target system (also referred to as a "high-value target"). It entices attackers to attack the honeypot and reveal attack vectors aimed at the real high-value target. For example, a web server (or web server software) is a popular option mimicked by a honeypot. Since web servers make up a large part of the public internet, it is important to continuously monitor threats targeting them. Honeypots are particularly interesting for the automotive industry, as there is hardly any data on real attacks. According to various embodiments, the honeypot 106 can therefore be implemented in a vehicle, for example. The computer network 100 can then at least partially include an internal network of the vehicle (but also a network that provides connectivity to the vehicle from outside, such as a cellular network).

[0035] Honeypots are designed to (1) attract real attackers and (2) capture the attention of attackers in order to learn as much as possible from these attackers. To fulfill their purpose, honeypots must be attractive and maintain this attractiveness. According to various embodiments, an approach is provided to automatically generate honeypots with "best attractiveness," i.e., to automatically improve a (possibly automatically generated) configuration of a honeypot so that it is as attractive as possible to attackers. This is done, according to various embodiments, using feedback regarding attacks on the honeypot.

[0036] Fig. 2 illustrates the configuration of a honeypot 200 according to one embodiment.

[0037] The following components are involved: • Vulnerability Database 201: This is a collection of internal and publicly known vulnerabilities, similar to the National Vulnerability Database (NVD). The vulnerability database is continuously updated and / or repeatedly queried to obtain an overview of the latest vulnerabilities. This can be used to determine the attacks being carried out. • Attack database 202: According to one embodiment, this database contains attacks that are best represented in a minimal form (as opposed to a full attack log, which also includes unnecessary steps for an attack). The attack database 202 also stores attack scripts that can be used in an automated manner, as well as tools that can be used automatically, such as network and vulnerability scanning tools (such as Nessus). • Real Attack Registry 203: This database stores logs and traces of real attacks (which have been recorded and tracked), which are used to replay (imitate) these attacks against the honeypot in order to evaluate different configurations.

[0038] For example, static checks and scans 204 are performed based on or dependent on information from the vulnerability database 201, the attack database 202, and the real attack registry 203. These are checks and scans that do not execute the honeypot (e.g., do not cause the execution of a program to provide a service), but rather statically analyze it. This includes, for example, searching for high-entropy locations in the honeypot's file system that reveal passwords and access tokens. It may also include a search for the service version used in the honeypot.

[0039] In addition, dynamic tests and attacks 205 of / on the honeypot 200 are executed (again, for example, based on or dependent on information from the vulnerability database 201, the attack database 202, and the real attack registry 203). For this purpose, an environment can be implemented in the same environment as one for static tests and scans to exchange the results between the dynamic methods and the static analysis. Dynamic attacks include, for example, automated attack scripts and fuzzing of the honeypot, i.e., attacks in which the honeypot is executed (e.g., a program is executed to provide a service).

[0040] Attackers 206 conduct real attacks 207 on the honeypot 200 (when it is "live," ie, in real use). The analysis of the real attacks 207 supplements the results of the dynamic and static tests 205 with real-world data.

[0041] The honeypot 200 itself can be viewed or configured in the form of a layered model, e.g., with several application programming interfaces (APIs) 208, several services 209, several applications 210, and an operating system (OS) 211, such as Debian 10. This list can be expanded (or reduced accordingly) with everything that is to run on the honeypot.

[0042] The APIs 208 point at least partially outwards, ie they form an interface to the outside world (from the perspective of the honeypot 200), ie, for example, to other components of the computer network 100, in particular to the attackers 206.

[0043] The applications 210 run on the honeypot 200 and an attacker 206 can potentially interact with them.

[0044] The honeypot 200 provides the services 209 (by executing appropriate utilities running on the honeypot), such as a Secure Shell (SSH) service.

[0045] The honeypot 200, in particular the aforementioned components such as the APIs 208, applications 210, and services 209, are configured in a specific way. A configuration database 212 stores the current configuration c of the entire honeypot 200.

[0046] The determination of a configuration for the honeypot (and possibly also the selection of an architecture for the honeypot to be configured) is performed by a honeypot configuration device, which corresponds, for example, to one of the user terminals 104 (e.g., a computer with which a user (such as a system administrator) configures the honeypot 106 and instructs the data processing device 105 to provide the thus-configured honeypot 106). The methods described herein for configuring a honeypot are thus performed (e.g., automatically) by such a honeypot configuration device.

[0047] According to various embodiments, the honeypot configuration device implements a honeypot configuration agent (also referred to as a "honeypot fitness agent") 213. This agent observes attacks 205, 207 (in particular their results) and evaluates the attacks 205, 207 and the static tests / scans 204 with respect to the honeypot 200 (for a respective configuration). The type of evaluation of an attack, test, or scan depends on the type of attack, scan, or test. For example, coverage could be a good evaluation for fuzzing (i.e., a fuzzing test run) of the honeypot 200. For password detection, however, a good evaluation would mean, for example, that some passwords are still within the honeypot, but not too many or none (thus avoiding the possibility that it is obvious to an attacker that they are operating within a honeypot).

[0048] The honeypot fitness agent 213 also has access to the honeypot's configuration c and assigns a fitness value (or configuration rating, e.g., a "score") s to it, e.g., as a list of individual ratings (c API1 , s API1 ), ..., (c APIK , s APIK ), (c App1 , s App1 ), ..., (c AppL , s AppL ): (c Service1 , s Service1 ), :::, (c ServiceM , c ServiceM ), where K, L,M ≥ 0.

[0049] Here, (c APIk , s APIk ) the evaluation of an attack on a particular API or a test of a particular API (where the API can be the same for different attacks / tests). Analogous are (c Appl , s Appl ) the evaluation of an attack on a particular application or a test of a particular application and (c Servicem , s Servicem ) the evaluation of an attack on a particular service or a test of a particular service.

[0050] Based on such a list of attack scores, the honeypot fitness agent 213 can determine a (honeypot configuration) score for a respective honeypot configuration. It can then change the configuration and control which attacks (or tests and checks) are performed for the changed configuration, e.g., start, stop, and re-execute dynamic tests and attacks 205 and static tests and checks 204, and also intercept (new) incoming real attacks 207 (which are then registered in the real attack registry 203 as a basis for later attacks) to find a configuration such that the total score (i.e., score) for a honeypot (or configuration) is maximized (or at least increased). For example, the honeypot fitness agent 213 can change the honeypot configuration for testing purposes (e.g.,as an “action” in the sense of a reinforcement learning agent) and re-execute dynamic tests and attacks 205 and static tests and checks 204 or monitor incoming real attacks in order to evaluate the changed configuration (and thus receive a “reward” for the change, which may also be negative) and, for example, retain or discard the configuration change if necessary.

[0051] The honeypot fitness agent 213 can calculate a honeypot configuration score s for a particular honeypot configuration (to evaluate whether it has improved or worsened) in various ways.

[0052] An example is the averaging of all attack ratings (for the respective configuration): S=(∑0ksAPIk+∑0lsAppl+∑0msServicem) / (k+l+m)

[0053] The Honeypot Fitness Agent 213 can also weight the attack scores, e.g. according to S=(∑0ksAPIkθk+∑0LsApplθl+∑0MsServicemθm) / (k+l+m) where the θ k , θ l and θ m The respective weights are given. For example, the honeypot fitness agent 213 can weight a running SSH service in a particular vulnerable version higher than an operating system version. The honeypot fitness agent 213 can weight a real attack 207 (or its rating), for example, based on the duration of the attack and the number of attacker interactions: Since real-world attackers 206 are the target of the honeypot 200 operation, it makes sense for their attacks to have a higher weighting than attacks and tests 204, 205 performed by the honeypot fitness agent 213 itself.

[0054] For example, the Honeypot Fitness Agent 213 performs the following: 1. Determining information for the dynamic tests / attacks 205 and the static checks / scans 204 are different databases that contain, for example, information about known vulnerabilities, scripted attacks and logs. 2. Executing the attacks and scans 204, 205 for a current configuration of the honeypot 200 and registering real attacks 207, which provide real attack data and time expenditure of attackers 206. 3. According to one embodiment, the honeypot fitness agent 213 then performs three tasks (e.g., in parallel and / or repeatedly): - Determine the attack scores and the honeypot configuration score for the current configuration. - Selecting, based on the attack scores, which attacks and scans the Honeypot Fitness Agent 213 repeats or interrupts, while continuously collecting attack results that are reflected in the various attack scores and in the Honeypot Configuration Score for the respective current configuration. - The Honeypot Fitness Agent 213 changes the current configuration of the honeypot to increase the honeypot configuration score. 4. The honeypot fitness agent 213 executes steps 2 and 3, for example, until they are aborted by a threshold metric, a maximum honeypot configuration score is reached, or the search is aborted by a timeout. Step 1 can be repeated at regular intervals, ie, the databases can be updated, e.g., once per day.

[0055] One way to evaluate attacks is the Common Vulnerability Scoring System (CVSS), which rates the severity of Common Vulnerabilities and Exposures (CVE). This can be used to estimate the time an attacker spends on the honeypot and the insights a defender gains from the attack. Further evaluations can include whether (or how far) an attacker penetrates a system, e.g., can they gain root privileges? Can they read the stored file with passwords? Can they trigger a buffer overflow and thus write their own code onto the stack? Exploitability can be described in the VEX format and can be uniformly recorded in a BOM (bill of materials).

[0056] In summary, according to various embodiments, a method is provided as described in Fig. 3 shown.

[0057] Fig. 3 shows a flowchart 300 illustrating a method for configuring a honeypot according to one embodiment.

[0058] In 301, a honeypot is configured according to a first configuration.

[0059] In 302, the honeypot configured according to the first configuration is deployed in a computer network.

[0060] In 303, ("real") attacks on the honeypot configured according to the first configuration, which one or more attackers carry out via the computer network, are observed and evaluated. These real attacks are also recorded (in order to imitate them later).

[0061] In 304, the first configuration is evaluated depending on the scores of the attacks carried out by the one or more attackers on the honeypot configured according to the first configuration.

[0062] In 305, the honeypot configuration is changed from the first configuration to a second configuration.

[0063] In 306, attacks are carried out (or, in other words, simulated) on the honeypot configured according to the second configuration, imitating the attacks carried out by the one or more attackers.

[0064] In 307, the attacks carried out on the honeypot configured according to the second configuration are evaluated.

[0065] In 308, the second configuration is evaluated depending on the scores of the attacks carried out on the honeypot configured according to the second configuration.

[0066] In 309, a configuration of the honeypot is determined depending on a comparison of the evaluation of the first configuration with the evaluation of the second configuration.

[0067] The procedure of Fig.3 may be performed by one or more computers having one or more data processing units. The term “data processing unit” may be understood as any type of entity that enables the processing of data or signals. The data or signals may, for example, be handled according to at least one (i.e., one or more than one) specific function performed by the data processing unit. A data processing unit may include or be formed from an analog circuit, a digital circuit, a logic circuit, a microprocessor, a microcontroller, a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), a programmable gate array (FPGA) integrated circuit, or any combination thereof.Any other way of implementing the respective functions described in more detail herein may also be understood as a data processing unit or logic circuit arrangement. One or more of the method steps described in detail herein may be executed (e.g., implemented) by a data processing unit through one or more specific functions performed by the data processing unit.

[0068] According to various embodiments, the method is therefore particularly computer-implemented.

Claims

[1] A method for configuring a honeypot (106, 200), comprising: Configuring (301) a honeypot (106, 200) according to a first configuration; deploying (302) the honeypot (106, 200) configured according to the first configuration in a computer network (100); Observing and evaluating (303) attacks (207) on the honeypot (106, 200) configured according to the first configuration, which one or execute multiple attackers on the honeypot (106, 200) configured according to the first configuration via the computer network (100); Evaluating the first configuration (304) depending on the evaluations of the attacks (207) carried out by the one or more attackers on the honeypot (106, 200) configured according to the first configuration; Changing the configuration (305) of the honeypot (106, 200) from the first configuration to a second configuration; Carrying out (306) attacks (204, 205) on the honeypot (106, 200) configured according to the second configuration, wherein the attacks (207) carried out by the one or more attackers are imitated; Evaluating (307) the attacks carried out on the honeypot (106, 200) configured according to the second configuration; Evaluating the second configuration (308) depending on the evaluations of the attacks (204, 205) carried out on the honeypot (106, 200) configured according to the second configuration; Determining a configuration (309) of the honeypot (106, 200) depending on a comparison of the evaluation of the first configuration with the evaluation of the second configuration. [2] The method of claim 1, wherein each of the attacks (204, 205, 207) is evaluated according to a metric that evaluates a credibility of the success of the attack (204, 205, 207) on the honeypot (106, 200). [3] The method of claim 1 or 2, wherein each of the attacks (204, 205, 207) is evaluated according to a metric that evaluates an attractiveness of the attack (204, 205, 207) on the honeypot (106, 200). [4] Method according to one of claims 1 to 3, comprising observing and evaluating attacks (207) on the honeypot (106, 200) configured according to the second configuration, which the one or more attackers carry out on the honeypot (106, 200) configured according to the second configuration via the computer network (100) and evaluating the second configuration further depending on the evaluations of the attacks (207) carried out by the one or more attackers on the honeypot (106, 200) configured according to the second configuration. [5] Method according to one of claims 1 to 4, comprising performing a plurality of iterations, comprising, in each iteration, deploying the honeypot (106, 200) configured according to a respective first configuration in the computer network (100); Observing and evaluating attacks (207) on the honeypot (106, 200) configured according to the respective first configuration, which attacks are carried out by one or more attackers on the honeypot (106, 200) configured according to the first configuration via the computer network (100); Evaluating the respective first configuration depending on the evaluation of the attacks (207) carried out by the one or more attackers on the honeypot (106, 200) configured according to the respective first configuration; Changing the configuration of the honeypot (106, 200) from the respective first configuration to a respective second configuration; Carrying out attacks (204, 205) on the honeypot (106, 200) configured according to the respective second configuration, wherein the attacks (207) carried out by the one or more attackers from the current iteration and / or from one or more previous iterations are imitated; Evaluating the attacks (204, 205) carried out on the honeypot (106, 200) configured according to the respective second configuration; and Evaluating the respective second configuration depending on the evaluations of the attacks (204, 205) carried out on the honeypot (106, 200) configured according to the second configuration; and determining a configuration of the honeypot (106, 200) depending on the comparisons of the evaluation of the respective first configuration with the evaluation of the respective second configuration. [6] Method according to one of claims 5, comprising using the respective second configuration as the first configuration for a subsequent iteration or as the final configuration for the honeypot (106, 200) if the respective second configuration was rated better than the respective first configuration and using the respective first configuration as the first configuration for a subsequent iteration or as the final configuration for the honeypot (106, 200) if the respective first configuration was rated better than the respective second configuration. [7] Method according to one of claims 1 to 6, wherein each configuration is evaluated depending on the evaluations of the attacks (204, 205, 207) carried out on the honeypot (106, 200) configured according to the configuration by weighted averaging the evaluations of the attacks (204, 205, 207) carried out on the honeypot (106, 200) configured according to the configuration, wherein for each attack (204, 205, 207) the respective evaluation is weighted depending on a target of the attack (204, 205, 207). [8] Honeypot configuration device, arranged to carry out the method according to one of claims 1 to 7. [9] A computer program comprising instructions which, when executed by a processor, cause the processor to perform a method according to any one of claims 1 to 7. [10] A computer-readable medium storing instructions which, when executed by a processor, cause the processor to perform a method according to any one of claims 1 to 7.

Citation Information

Cited By

  • Network attack defense system based on virtual honeypot

    CN120825333A