INTRUSION RECOGNIZED FOR COMPUTER SYSTEMS

Description

TECHNICAL FIELD

[0001] Various examples generally concern techniques for intrusion detection of computer systems based on the analysis of computer system log messages. Various examples specifically concern the use of a distributed database in the context of intrusion detection. BACKGROUND

[0002] An intrusion detection system (IDS) is a device that monitors computer systems (e.g., individual computers or networks comprising multiple computers) with the aim of detecting attacks. IDSs generally use two different techniques for attack detection. First, signature-based attack detection uses attack patterns stored in a database to monitor the active computer system. Attacks are detected by comparing attack signatures from the database with the active system behavior. If the stored attack signature matches the current system behavior, the IDS concludes that an attack has occurred. Second, anomaly-based IDS. This technique attempts to detect attacks by detecting changes in the system behavior of the computer system. This means that in the first step, the IDS learns / analyzes (orA trusted third party learns the normal behavior) and, in the second step, compares the active behavior of the system with the previously learned normal behavior. If the current behavior deviates from the previously learned normal behavior, this can be considered an anomaly and may be a sign of an attack or compromise of the computer system. The decision as to whether the system has deviated from normal behavior can be made using statistical methods or machine learning algorithms.

[0003] A host-based IDS (HIDS) is installed on a computer system and collects information about its operating status in order to use this information to detect attacks. A network-based IDS (network-based intrusion detection system, NIDS) attempts to detect attacks by analyzing network traffic. Both HIDS and NIDS typically create log messages of the current system behavior. Log messages document the system behavior. These log messages are then analyzed and evaluated by the IDS. The result of this analysis provides information about whether an attacker was / is active or not.

[0004] Such previously known techniques have certain disadvantages and limitations. Attackers who gain control of a computer system or the IDS can manipulate the analysis of the log messages. In concrete terms, this means that even though the log messages contain clues about an attacker, the analysis results are incorrect because the IDS is now controlled by the attacker, and the results are therefore falsified. This means that known IDS can have limited security against manipulation. BRIEF SUMMARY OF THE INVENTION

[0005] Therefore, there is a need for improved techniques for intrusion detection of computer systems. In particular, there is a need for secure and efficient intrusion detection techniques.

[0006] This problem is solved by the features of the independent patent claims. The features of the dependent patent claims define embodiments.

[0007] Blockchain technology, or "distributed ledgers," is currently a hotly debated technology, particularly one that can be implemented as a distributed database system. In addition to applications for decentralized payment systems (e.g., Bitcoin), new applications are being developed in the financial industry. In particular, transactions between companies can be carried out without intermediaries or clearing houses, ensuring they are protected from manipulation. This enables new business models without a trusted intermediary, reduces transaction costs, and allows new digital services to be offered flexibly without the need for a dedicated infrastructure and trust relationships. A transaction record (or transaction for short) protected by a blockchain includes, for example, program code, which can also be referred to as a "smart contract."

[0008] An IDS comprises a processor and a communication interface. The processor is configured to load and execute program code from a memory and, based thereon, to perform the following steps: communicating with at least one node of a distributed database infrastructure via the communication interface to obtain authorization for intrusion detection of a computer system; and, depending on whether authorization is obtained: performing intrusion detection of the computer system based on an analysis of log messages of the computer system received from the computer system via the communication interface.

[0009] A method comprises communicating with at least one node of a distributed database infrastructure to obtain authorization for intrusion detection of a computer system. The method also comprises, depending on whether authorization is obtained, performing intrusion detection of the computer system based on an analysis of computer system log messages received by the computer system.

[0010] A computer program or a computer program product or a computer-readable storage medium comprises program code. The program code is executable by a processor. This causes the processor to perform a method comprising: communicating with at least one node of a distributed database infrastructure to obtain authorization for intrusion detection of a computer system. The method also comprises, depending on whether authorization is obtained: performing intrusion detection of the computer system based on an analysis of computer system log messages received by the computer system.

[0011] A node of a distributed database infrastructure comprises a processor and a communication interface. The processor is configured to load and execute program code from a memory and, based thereon, perform the following steps: executing a smart contract to obtain a corresponding result value; and selecting at least one IDS from a plurality of IDSs depending on the result value; and communicating with the at least one IDS via the communication interface to grant the at least one IDS authorization to detect intrusions of a computer system.

[0012] A method comprises: executing a smart contract to obtain a corresponding result value; and selecting at least one IDS from a plurality of IDSs depending on the result value; and communicating with the at least one IDS to grant authorization to the at least one IDS for intrusion detection of a computer system.

[0013] A computer program or a computer program product or a computer-readable storage medium comprises program code. The program code can be executed by a processor. This causes the processor to perform a method comprising: executing a smart contract to obtain a corresponding result value; and selecting at least one IDS from a plurality of IDSs depending on the result value; and communicating with the at least one IDS to grant authorization to the at least one IDS for intrusion detection of a computer system. A computer system comprises a processor and a communication interface, wherein the processor is configured to load and execute program code from a memory and, based thereon, to perform the following steps: receiving registration information from an IDS via the communication interface. The registration information is indicative of an identity of the IDS.The processor is also configured to initiate a verification of the registration information, for example, by comparing it with a corresponding entry in a distributed database. The processor is also configured to transmit log messages from the computer system to the IDS and via the communication interface depending on the result of the verification.

[0014] A method comprises: receiving registration information from an IDS, wherein the registration information is indicative of an identity of the IDS; and triggering a verification of the registration information, for example by comparing it with a corresponding entry in a distributed database or a public-key infrastructure; and depending on a result of the verification: transmitting log messages of the computer system to the IDS.

[0015] A computer program or a computer program product or a computer-readable storage medium comprises program code. The program code can be executed by a processor. This causes the processor to perform a method comprising: receiving registration information from an IDS, wherein the registration information is indicative of an identity of the IDS; and triggering a verification of the registration information, for example by comparing it with a corresponding entry in a distributed database; and depending on a result of the verification: transmitting log messages of the computer system to the IDS.

[0016] Unless otherwise stated in the following description, the terms "perform," "calculate," "computer-aided," "calculate," "determine," "generate," "configure," "reconstruct," and the like preferably refer to actions and / or processes and / or processing steps that modify and / or generate data and / or convert the data into other data, wherein the data may be represented or present as physical quantities, for example, as electrical impulses. In particular, the term "computer" should be interpreted as broadly as possible to cover, in particular, all electronic devices with data processing capabilities.Computers can therefore be, for example, personal computers, servers, programmable logic controllers (PLCs), embedded systems, microcontrollers, handheld computer systems, pocket PC devices, mobile radio devices and other communication devices that can process data in a computer-aided manner, processors and other electronic devices for data processing.

[0017] In the context of the invention, "computer-aided" can be understood as meaning, for example, an implementation of the method in which, in particular, a processor carries out at least one method step of the method.

[0018] In the context of the invention, a processor can be understood to mean, for example, a machine or an electronic circuit. A processor can in particular be a main processor (Central Processing Unit, CPU), a microprocessor or a microcontroller, for example an application-specific integrated circuit or a digital signal processor, possibly in combination with a memory unit for storing program instructions, etc. A processor can also be, for example, an IC (Integrated Circuit), in particular an FPGA (Field Programmable Gate Array) or an ASIC (Application-Specific Integrated Circuit), or a DSP (Digital Signal Processor) or a graphics processor GPU (Graphic Processing Unit).A processor can also be understood as a virtualized processor, a virtual machine, or a soft CPU. For example, it can also be a programmable processor that is equipped with configuration steps for executing the aforementioned method according to the invention or is configured with configuration steps such that the programmable processor implements the inventive features of the method, the component, the modules, or other aspects and / or sub-aspects of the invention.

[0019] In the context of the invention, a "memory", a "memory unit" or "memory module" and the like can be understood to mean, for example, a volatile memory in the form of random-access memory (RAM) or a permanent memory such as a hard disk or a data carrier.

[0020] In the context of the invention, a "module" can be understood, for example, as a processor and / or a memory unit for storing program instructions. For example, the processor is specifically configured to execute the program instructions in such a way that the processor performs functions to implement or realize the method according to the invention or a step of the method according to the invention. A module can also be, for example, a node of the distributed database system that, for example, realizes the specific functions / features of a corresponding module. The respective modules can also be designed, for example, as separate or independent modules.

[0021] For this purpose, the corresponding modules can, for example, comprise further elements. These elements are, for example, one or more interfaces (e.g., database interfaces, communication interfaces - e.g., network interfaces, WLAN interfaces) and / or an evaluation unit (e.g., a processor) and / or a storage unit. Data can be exchanged (e.g., received, transmitted, sent, or provided) via the interfaces. Data can be compared, checked, processed, assigned, or calculated, for example, in a computer-aided and / or automated manner, using the evaluation unit. Data can, for example, be stored, retrieved, or provided in a computer-aided and / or automated manner, using the storage unit.

[0022] In the context of the invention, "comprise", particularly with regard to data and / or information, can be understood as meaning, for example, a (computer-aided) storage of corresponding information or a corresponding datum in a data structure / data record (which, for example, is in turn stored in a storage unit).

[0023] In the context of the invention, "assigning," particularly with regard to data and / or information, can be understood, for example, as a computer-assisted assignment of data and / or information. For example, a first datum is assigned a second datum using a memory address or a unique identifier (UID), in which, for example, the first datum is stored together with the memory address or the unique identifier of the second datum in a data record.

[0024] In the context of the invention, "providing," particularly with regard to data and / or information, can be understood, for example, as computer-assisted provision. Provision occurs, for example, via an interface (e.g., a database interface, a network interface, an interface to a storage unit). Via this interface, corresponding data and / or information can be transmitted and / or sent and / or retrieved and / or received, for example, during provision.

[0025] In the context of the invention, "providing" can also be understood, for example, as loading or storing, for example, a transaction with corresponding data. This can be done, for example, to or from a storage module. "Providing" can also be understood, for example, as transferring (or sending or transmitting) corresponding data from one node to another node of the blockchain or the distributed database system (or its infrastructure).

[0026] In the context of the invention, "executing a smart contract" or a "smart contract process" can be understood as meaning, in particular, the execution of a program code (e.g., the control commands) in a process by the distributed database system or its infrastructure.

[0027] A "checksum," for example, a data block checksum, a data checksum, a node checksum, a transaction checksum, a chain checksum, or the like, can be understood in the context of the invention as, for example, a cryptographic checksum or cryptographic hash or hash value, which is formed or calculated, in particular, using a cryptographic hash function, over a data record and / or data and / or one or more of the transactions and / or a subsection of a data block (e.g., the block header of a block of a blockchain or the data block header of a data block of the distributed database system or only a portion of the transactions of a data block). A checksum can, in particular, be a checksum(s) or hash value(s) of a hash tree (e.g., Merkle tree, Patricia tree).Furthermore, this can also be understood, in particular, as a digital signature or a cryptographic message authentication code. Using checksums, cryptographic protection / tamper protection for transactions and the data (sets) stored therein can be implemented at different levels of the database system. If, for example, a high level of security is required, the checksums are generated and verified at the transaction level. If less security is required, the checksums are generated and verified at the block level (e.g., across the entire data block or only across a portion of the data block and / or a portion of the transactions).

[0028] In the context of the invention, a "data block checksum" can be understood as a checksum that is calculated, for example, over part or all of the transactions of a data block. A node can then, for example, check / determine the integrity / authenticity of the corresponding part of a data block using the data block checksum. Additionally or alternatively, the data block checksum can also have been formed, in particular, over transactions of a previous data block / predecessor data block of the data block. The data block checksum can also be implemented, in particular, using a hash tree, for example, a Merkle tree [1] or a Patricia tree, wherein the data block checksum is, in particular, the root checksum of the Merkle tree or a Patricia tree or a binary hash tree. In particular, transactions are secured using additional checksums from the Merkle tree or Patricia tree (e.g.,using the transaction checksums), whereby in particular the further checksums are leaves in the Merkle tree or Patricia tree. The data block checksum can thus, for example, secure the transactions by forming the root checksum from the further checksums. The data block checksum can, in particular, be calculated for transactions of a specific data block of the data blocks. In particular, such a data block checksum can be included in a subsequent data block of the specific data block in order to, for example, concatenate this subsequent data block with its preceding data blocks and, in particular, thus make the integrity of the distributed database system verifiable. In this way, the data block checksum can, for example, take on the function of the concatenation checksum or be included in the concatenation checksum. The header of a data block (e.g.of a new data block or the data block for which the data block checksum was created) may, for example, include the data block checksum.

[0029] In the context of the invention, "transaction checksum" can be understood as a checksum that is generated, in particular, over a transaction of a data block. In addition, the calculation of a data block checksum for a corresponding data block can be accelerated, for example, because previously calculated transaction checksums can be used as leaves, e.g., of a Merkle tree.

[0030] In the context of the invention, a "concatenation checksum" can be understood as a checksum that, in particular, specifies or references a respective data block of the distributed database system to the previous data block of the distributed database system (frequently referred to in the specialist literature as a "previous block hash") [1]. For this purpose, a corresponding concatenation checksum is formed, in particular, for the corresponding previous data block. For example, a transaction checksum or the data block checksum of a data block (i.e., an existing data block of the distributed database system) can be used as a concatenation checksum to concatenate a new data block with an (existing) data block of the distributed database system.However, it is also possible, for example, for a checksum to be formed over a header of the previous data block or over the entire previous data block and to be used as a concatenation checksum. This can, for example, also be calculated for several or all previous data blocks. It is also possible, for example, for the concatenation checksum to be formed over the header of a data block and the data block checksum. However, a respective data block of the distributed database system preferably comprises a concatenation checksum that was calculated for a previous data block, in particular even more preferably the directly previous data block, of the respective data block or that relates to this. It is also possible, for example, for a corresponding concatenation checksum to be formed only over a part of the corresponding data block (e.g. previous data block).This makes it possible, for example, to create a data block that includes an integrity-protected part and an unprotected part. This would allow, for example, a data block to be created in which the integrity-protected part is immutable and the unprotected part can be modified later. Integrity-protected means, in particular, that any changes to integrity-protected data can be detected using a checksum.

[0031] The data stored in a transaction of a data block, for example, can be provided in different ways. Instead of the data itself, e.g., user data such as measurement data or data / ownership of assets, a transaction of a data block can, for example, only include the checksum for this data. The corresponding checksum can be implemented in different ways. This can, for example, be a corresponding data block checksum of a data block (with the corresponding data) of another database or of the distributed database system, a transaction checksum of a data block with the corresponding data (of the distributed database system or another database), or a data checksum created using the data.

[0032] In addition, the corresponding transaction can also include a reference or information about a storage location (e.g., an address of a file server and information about where the corresponding data can be found on the file server; or an address of another distributed database that contains the data). The corresponding data could then, for example, also be provided in another transaction of another data block of the distributed database system (e.g., if the corresponding data and the associated checksums are contained in different data blocks). However, it is also conceivable, for example, that this data is provided via a different communication channel (e.g., via a different database and / or a cryptographically secured communication channel).

[0033] For example, in addition to the checksum, an additional data record (e.g., a reference or a specification of a storage location) can be stored in the corresponding transaction, which, in particular, specifies a storage location where the data can be retrieved. This is particularly advantageous for keeping the data size of the blockchain or the distributed database system as small as possible.

[0034] In the context of the invention, "security-protected" can be understood, for example, as protection that is implemented in particular by a cryptographic method. For example, this can be achieved by using the distributed database system to provide, transmit, or send corresponding data / transactions. This is preferably achieved by a combination of the various (cryptographic) checksums, in particular by having them interact synergistically, for example, to improve the security or cryptographic security of the transaction data. In other words, "security-protected" in the context of the invention can also be understood as "cryptographically protected" and / or "tamper-proof," whereby "tamper-proof" can also be referred to as "integrity-protected" and / or "authenticity-protected."

[0035] In the context of the invention, "concatenating the data blocks of a distributed database system" can be understood, for example, to mean that data blocks each comprise information (e.g., concatenation checksum) that refers to or references another data block or several other data blocks of the distributed database system [1] [4] [5].

[0036] In the context of the invention, "storing in the distributed database system" or "inserting into the distributed database system" and the like can be understood, for example, to mean that, in particular, a transaction or transactions or a data block with its transactions is transmitted to one or more nodes of a distributed database system. If these transactions are successfully validated (e.g., by the node(s), these transactions are, in particular, concatenated as a new data block with at least one existing data block of the distributed database system [1][4][5]. For this purpose, the corresponding transactions are stored, for example, in a new data block. In particular, this validation and / or concatenation can be performed by a trusted node (e.g., a mining node, a blockchain oracle, or a blockchain platform).In particular, a blockchain platform can be understood as a blockchain as a service, as proposed in particular by Microsoft or IBM. In particular, a trusted node and / or a node can each store a node checksum (e.g., a digital signature) in a data block (e.g., in the data block they validate and generate, which is then concatenated), in particular to enable the identification of the creator of the data block and / or to enable the identification of the node. This node checksum indicates, for example, which node has concatenated the corresponding data block with at least one other data block of the distributed database system.

[0037] In the context of the invention, "transaction" or "transactions" can be understood, for example, as a smart contract [4] [5], a data structure, or a transaction data record, each of which particularly comprises one or more transactions. In the context of the invention, "transaction" or "transactions" can also be understood, for example, as the data of a transaction in a data block of a blockchain. A transaction can, in particular, comprise program code that implements a smart contract, for example. For example, in the context of the invention, a transaction can also be understood as a control transaction and / or a confirmation transaction. Alternatively, a transaction can, for example, be a data structure that stores data (e.g.,the control commands and / or contract data and / or other data such as video data, user data, measurement data, machine learning algorithms, hash values ​​of the algorithms, other variables, etc.).

[0038] In particular, "storing transactions in data blocks," "storing transactions," and the like are understood to mean direct storage or indirect storage. Direct storage can be understood, for example, to mean that the corresponding data block (of the distributed database system) or the corresponding transaction (of the distributed database system) contains the respective data. Indirect storage can be understood, for example, to mean that the corresponding data block or transaction contains a checksum and optionally an additional data record (e.g., a reference or an indication of a storage location) for the respective data, and the respective data is thus not stored directly in the data block (or transaction) (instead, only a checksum for this data is stored).In particular, when storing transactions in data blocks, these checksums can be validated, for example, as explained under "Inserting into the distributed database system".

[0039] In the context of the invention, "program code" (e.g., a smart contract) can be understood to mean, for example, one or more program instructions, which are stored in particular in one or more transactions. The program code is, in particular, executable and is executed, for example, by the distributed database system. This can be realized, for example, by means of an execution environment (e.g., a virtual machine), wherein the execution environment or the program code is preferably Turing-complete. The program code is preferably executed by the infrastructure of the distributed database system [4][5]. In this case, a virtual machine is realized, for example, by the infrastructure of the distributed database system.

[0040] In the context of the invention, a "smart contract" can be understood, for example, as executable program code [4][5] (see in particular the definition of "program code"). The smart contract is preferably stored in a transaction of a distributed database system (e.g., a blockchain), for example, in a data block of the distributed database system. For example, the smart contract can be executed in the same way as explained in the definition of "program code," particularly in the context of the invention.

[0041] In the context of the invention, "proof-of-work" can be understood, for example, as solving a computationally intensive task that is to be solved, in particular, depending on the data block content / content of a specific transaction [1][4][5]. Such a computationally intensive task is also referred to, for example, as a cryptographic puzzle.

[0042] A "distributed database system," which can also be referred to as a distributed database, can be understood in the context of the invention as, for example, a decentralized distributed database, a blockchain, a distributed ledger, a distributed storage system, a distributed ledger technology (DLT)-based system (DLTS), an audit-proof database system, a cloud, a cloud service, a blockchain in a cloud, or a peer-to-peer database. Different implementations of a blockchain or DLTS can also be used, such as a blockchain or DLTS using a directed cyclic graph (DAG), a cryptographic puzzle, a hash graph, or a combination of the aforementioned implementation variants [6][7]. Different consensus algorithms can also be implemented, for example.This can be, for example, a consensus process using a cryptographic puzzle, gossip about gossip, virtual voting, or a combination of the aforementioned processes (e.g., gossip about gossip combined with virtual voting) [6][7]. If, for example, a blockchain is used, this can be implemented in particular using a Bitcoin-based implementation or an Ethereum-based implementation [1][4][5]. A "distributed database system" can also be understood, for example, as a distributed database system whose at least some of its nodes and / or devices and / or infrastructure are implemented in a cloud. For example, the corresponding components are implemented as nodes / devices in the cloud (e.g., as virtual nodes in a virtual machine). This can be done, for example, using VMWare, Amazon Web Services, Microsoft Azure, or Siemens MindSphere.Due to the high flexibility of the implementation variants explained, partial aspects of the implementation variants mentioned can also be combined with each other, for example by using a hashgraph as a blockchain, whereby the blockchain itself can also be blockless.

[0043] For example, if a Directed Acyclic Graph (DAG) is used (e.g., IOTA or Tangle), transactions, blocks, or nodes of the graph are connected to each other via directed edges. This means, in particular, that (all) edges (always) have the same direction, similar to, for example, time. In other words, it is not possible to access or jump to the transactions, blocks, or nodes of the graph backward (i.e., against the common, same direction). Acyclic means, in particular, that there are no loops when traversing the graph.

[0044] The distributed database system can, for example, be a public distributed database system (e.g., a public blockchain) or a closed (or private) distributed database system (e.g., a private blockchain).

[0045] For example, if it is a public distributed database system, this means that new nodes and / or devices can join or be accepted into the distributed database system without any credentials or authentication, or without login information or credentials. In particular, in such a case, the operators of the nodes and / or devices can remain anonymous.

[0046] For example, if the distributed database system is a closed distributed database system, new nodes and / or devices require, for example, valid credentials and / or valid authentication information and / or valid credentials and / or valid login information in order to join or be accepted by the distributed database system.

[0047] A distributed database system can also be a distributed communication system for data exchange. This can be a network or a peer-to-peer network, for example.

[0048] In the context of the invention, a "data block," which may also be referred to as a "link" or "block" depending on the context and implementation, can be understood, for example, as a data block of a distributed database system (e.g., a blockchain or a peer-to-peer database), which is implemented, in particular, as a data structure and preferably comprises one or more of the transactions. In one implementation, for example, the database (or database system) can be a DLT-based system (DLTS) or a blockchain, and a data block can be a block of the blockchain or DLTS. A data block can, for example, include information on the size (data size in bytes) of the data block, a data block header, a transaction counter, and one or more transactions [1].The data block header can, for example, include a version, a chaining checksum, a data block checksum, a timestamp, a proof-of-work, and a nonce (a one-time value, random value, or counter used for the proof-of-work) [1][4][5]. A data block can, for example, also be just a specific memory area or address range of the entire data stored in the distributed database system. This allows, for example, blockless distributed database systems, such as the IoT Chain (ITC), IOTA, and Byteball, to be implemented. In particular, the functionalities of the blocks of a blockchain and the transactions are combined in such a way that, for example, the transactions themselves secure the sequence or chain of transactions (of the distributed database system) (i.e., they are stored in a secure manner).For this purpose, the transactions themselves can be linked together using a chaining checksum, for example, by preferably using a separate checksum or the transaction checksum of one or more transactions as the chaining checksum, which is then stored in the corresponding new transaction when a new transaction is saved in the distributed database system. In such an embodiment, a data block can, for example, also comprise one or more transactions, with one data block corresponding to one transaction in the simplest case.

[0049] In the context of the invention, "nonce" can be understood, for example, as a cryptographic nonce (abbreviation for "used only once" [2] or "number used once" [3]). In particular, a nonce refers to a single number or letter combination that is preferably used only once in the respective context (e.g., transaction, data transmission).

[0050] In the context of the invention, "preceding data blocks of a (specific) data block of the distributed database system" can be understood, for example, as the data block of the distributed database system that directly precedes a (specific) data block. Alternatively, "preceding data blocks of a (specific) data block of the distributed database system" can also be understood, in particular, as all data blocks of the distributed database system that precede the specific data block. This allows, for example, the chaining checksum or the transaction checksum to be formed, in particular, only over the data block (or its transactions) directly preceding the specific data block or over all data blocks (or their transactions) preceding the first data block.

[0051] In the context of the invention, a "blockchain node," "node," "node of a distributed database system," and the like can be understood to mean, for example, devices (e.g., field devices, mobile phones), computers, smartphones, clients, or participants that perform operations (with) the distributed database system (e.g., a blockchain) [1][4][5]. Such nodes can, for example, execute transactions of a distributed database system or their data blocks, or insert or link new data blocks with new transactions into the distributed database system using new data blocks. In particular, this validation and / or linking can be performed by a trusted node (e.g., a mining node) or exclusively by trusted nodes. A trusted node is, for example, a node that has additional security measures (e.g.,Firewalls, access restrictions to the node or similar) to prevent manipulation of the node. Alternatively or additionally, for example, a trusted node can store a node checksum (e.g. a digital signature or a certificate) in the new data block when chaining a new data block with the distributed database system. This can in particular provide proof that indicates that the corresponding data block was inserted by a specific node or indicates its origin. The devices (e.g. the corresponding device) are, for example, devices of a technical system and / or industrial plant and / or an automation network and / or a production plant, which in particular are also a node of the distributed database system. The devices can, for example, be field devices or devices in the Internet of Things, which in particular are also a node of the distributed database system.Nodes may also include at least one processor, for example, to execute their computer-implemented functionality.

[0052] In the context of the invention, a "blockchain oracle" and the like can be understood as, for example, nodes, devices, or computers that have, for example, a security module that includes, for example, software protection mechanisms (e.g., cryptographic methods), mechanical protection devices (e.g., a lockable housing), or electrical protection devices (e.g., tamper protection or a protection system that deletes the security module's data in the event of unauthorized use / handling of the blockchain oracle). The security module can, for example, include cryptographic keys necessary for calculating the checksums (e.g., transaction checksums or node checksums).

[0053] In the context of the invention, a "computer" or a "device" can be understood as, for example, a computer (system), a client, a smartphone, a device, or a server, each of which is located outside the blockchain or is not a participant in the distributed database system (e.g., the blockchain) (i.e., it does not perform any operations with the distributed database system or only queries them, but without executing transactions, inserting data blocks, or calculating proof-of-work). Alternatively, a computer can also be understood as a node of the distributed database system. In other words, a device can be understood as a node of the distributed database system or as a device outside the blockchain or the distributed database system. A device outside the distributed database system can, for example, access the data (e.g.,Transactions or control transactions) of the distributed database system and / or can be controlled by nodes (e.g., via smart contracts and / or blockchain oracles). For example, if a device (e.g., a device configured as a node or a device outside the distributed database system) is controlled by a node, this can be done, for example, via a smart contract, which is stored in a transaction of the distributed database system.

[0054] The features set forth above and features described below may be used not only in the corresponding explicitly set forth combinations, but also in further combinations or in isolation, without departing from the scope of the present invention. SHORT DESCRIPTION OF THE CHARACTERS

[0055] FIG. 1 illustrates a system including a computer system, a blockchain infrastructure, and an IDS according to various examples. FIG. 2 is a flowchart of an example method. FIG. 3 is a flowchart of an example method. FIG. 4 is a flowchart of an example method. FIG. 5 schematically illustrates the operation of the IDS according to various examples. DETAILED DESCRIPTION OF EMBODIMENTS

[0056] The above-described properties, features and advantages of this invention, as well as the manner in which they are achieved, will become clearer and more clearly understood in connection with the following description of the embodiments, which are explained in more detail in connection with the drawings.

[0057] The present invention is explained in more detail below using preferred embodiments with reference to the drawings. In the figures, identical reference numerals designate identical or similar elements. The figures are schematic representations of various embodiments of the invention. Elements shown in the figures are not necessarily drawn to scale. Rather, the various elements shown in the figures are depicted in such a way that their function and general purpose will be understood by those skilled in the art. Connections and couplings between functional units and elements shown in the figures can also be implemented as an indirect connection or coupling. A connection or coupling can be implemented wired or wirelessly. Functional units can be implemented as hardware, software, or a combination of hardware and software.

[0058] The following describes techniques related to intrusion detection of a computer system. The computer system can be, for example, a single computer or a network comprising multiple computers.

[0059] Intrusion detection is implemented on an IDS. The IDS is generally located spatially and functionally separate from the computer system. This means that the IDS and the computer system may use different operating systems or operating system instances. The IDS and the computer system may be located in different rooms, locations, or countries.

[0060] In some examples, the IDS and the computer system can also be co-implemented. An example implementation would look like this: The computer system runs in normal mode. The IDS runs in a secure environment on the same device. Among other things, the secure environment could be a Trusted Execution Environment (see, for example, the TEE / Trust Zone from ARM). Since the Trusted Execution Environment is separated from the normal operating system by physical CPU-internal measures, this could be an alternative implementation type with a high level of security.

[0061] The intrusion detection techniques described herein utilize analysis of computer system log messages. Generally, such log messages may be indicative of the computer system's current behavior. For example, the log messages may be indicative of one or more of the following: system calls, data accesses, network packets, communication protocols, user logins, failed calls, active network connections, etc.

[0062] In general, the analysis can use signature-based attack detection, i.e., comparing current system behavior with an attack pattern stored in a database. Alternatively or additionally, the analysis could also use statistical methods or machine learning algorithms, for example, to detect anomalies. Other algorithms, such as anomaly detection, can also be used.

[0063] The techniques described herein enable an unconventional and novel approach to intrusion detection. In particular, the techniques described herein enable particularly secure and efficient intrusion detection through the interaction of several different devices. In particular, the use of multiple devices can avoid the need for a single central authority. This will be explained in more detail below.

[0064] In a reference implementation, log message analysis occurs on a central instance, which is operated in a secure environment with enhanced security measures. The problems of such a central instance according to the reference implementation are: First, the central instance is viewed as a central security node for the entire ecosystem and could therefore represent a single point of failure. Therefore, the system must not only be integral at runtime, but the integrity of previous analyses must also be safeguarded. This makes the central analysis instance complex, costly, and a single point of failure. Second, since a central instance typically performs analysis for multiple clients, such a system must ensure very high uptime through redundancy mechanisms. This also makes the central analysis instance complex and costly.Thirdly, such systems are often complex because multiple clients must be served in parallel (remote attestation for multiple devices, high parallelization).

[0065] To enable simplified and particularly secure intrusion detection compared to such a reference implementation, various examples use a distributed database. In some examples, the distributed database can be implemented as a blockchain in a blockchain infrastructure. While the following examples primarily describe implementations based on a blockchain, other examples may also use a different type of distributed database.

[0066] In various examples, so-called smart contracts are used. The smart contracts can be stored in the distributed database and contain executable program code. Certain conditions can be taken into account when executing the program code, and, for example, the outcome of the smart contract can depend on one or more of these conditions.

[0067] According to various examples, particularly small smart contracts can be used. This means that the logic represented in the smart contracts can be very limited compared to other implementations. This means that the costs of the smart contracts—for example, those paid to a blockchain infrastructure operator or a node operator—can be particularly low and / or the costs of executing the smart contracts can be particularly low due to the reduced size.

[0068] In various examples, log messages from a monitored computer system can be analyzed in a decentralized manner based on the outcome of a smart contract execution. The results of this analysis can, in turn, be stored in the blockchain. For example, the IDS to be used can be selected from several candidate IDSs based on the outcome of the smart contract execution. The log messages can be received directly from the computer system via an end-to-end channel at the IDS; this means that the "payload" (i.e., the log messages) do not have to be processed via the blockchain. This allows the logic implemented by the blockchain to be kept lean and efficient. However, one or more parameters of the end-to-end channel could be exchanged between the IDS and the computer system with the participation of the blockchain, e.g., registration information indicative of an identification of the IDS.

[0069] Fig. 1 illustrates a system 90 that may be used in conjunction with the various intrusion detection techniques described herein.

[0070] The system 90 comprises a computer system 101, in the example of Fig. 1 implemented by a single computer. Computer system 101 includes a processor 102, a memory 103, and a communications interface 104. Processor 102 can load and execute program code from memory 103. This causes the processor to perform various techniques related to the intrusion detection described herein: for example, receiving, verifying, or executing information or data via communications interface 104, creating log messages, transmitting log messages 101 via communications interface 104, etc.

[0071] The computer system 101 is connected to other devices via a communication network 130, such as the Internet or a local area network. In the example of Fig. 1 An IDS 111 is also provided. The IDS 111 is configured to perform intrusion detection for the computer system 101 based on log messages 191 sent by the computer system 101 and received by the IDS 111.

[0072] For this purpose, the IDS 111 comprises a processor 112, a memory 113, and a communication interface 114. The processor 112 is connected to the network 130 via the communication interface 114. The processor 112 can, in turn, load and execute program code from the memory 113. Executing the program code causes the processor 112 to perform various techniques related to intrusion detection as described herein, for example: communicating with a node 121 of a distributed database infrastructure 129 via the communication interface 114; receiving a command for intrusion detection, e.g., by looking up the blockchain and / or by requesting the deposit of registration information; performing intrusion detection of the computer system 101 based on an analysis of the log messages 191; receiving and / or sending information or data via the communication interface 114; etc.

[0073] The system 90 also includes the infrastructure 129 of the distributed database, in the example of Fig. 1 a blockchain infrastructure 129. The blockchain infrastructure 129 comprises a plurality of nodes, where in the example the Fig. 1 in particular a node 121 is shown. The various nodes can also be referred to as mining nodes and can be configured according to node 121 according to Fig. 1 be configured.

[0074] The mining node 121 in the example of Fig. 1 comprises a processor 122, a memory 123, and a communication interface 124. The processor 122 is, in turn, connected to the network 130 via the communication interface 124. The processor 122 can load and execute program code from the memory 123. When the processor 122 executes the loaded program code, this causes the processor 122 to perform various techniques related to intrusion detection as described herein, for example: executing a smart contract 192 stored in the blockchain; selecting from a plurality of IDSs, for example, selecting the IDS 111 depending on a result of executing the smart contract 192; granting an authorization 193 for the selected IDS, for example, the IDS 111, to trigger intrusion detection; depositing registration information of the selected IDS depending on an application of the analyzer device to thus grant the authorization.

[0075] In general, the mining node 121 is a participant in the blockchain infrastructure 129 that can execute smart contracts 192 and attempt to store the result of executing the smart contract 192 in the blockchain. In some examples, mining nodes 121 can be paid for executing smart contracts, and this payment can be conditional upon them managing to generate a block in the blockchain that is indicative of the result of executing the smart contract. To generate this block in the blockchain, the mining nodes 121 often have to solve a consensus algorithm or cryptographic puzzle (e.g., proof-of-work or proof-of-stake or another common consensus algorithm); however, this is not always required.

[0076] Below, various terms that have been previously used in connection with Fig. 1 mentioned above are explained in more detail. The descriptions given below may serve as definitions in some examples. Other examples may also use different implementations.

[0077] Smart contracts 192 are programs written to the blockchain that define a contract. Smart contracts 192 are programs executed by mining nodes 121, which are paid for their execution. Examples of smart contracts are: "If sum x arrives from address y, execute z." or "If sum y > 2*x arrives from address z, send 2*x to v." An example of smart contracts 192 are so-called multi-signature contracts. Multi-signature contracts are smart contracts 192 that can only be executed if multiple nodes of the blockchain infrastructure 129 agree to the validity of a contract (i.e., a smart contract) and thus to its execution.

[0078] Gas & Gas Price (literally gasoline) is a medium required to run computational operations in the blockchain infrastructure 129. The more computationally intensive a smart contract 192 is, the more gas is required. The gas price indicates how much one is willing to pay to the mining nodes 121 for a computational operation—such as solving a cryptographic puzzle (such as proof-of-work or proof-of-stake) and / or the complexity of the smart contract to be executed. The more one is willing to pay, the greater the probability that the smart contract 192 will be executed.

[0079] In the context of a blockchain infrastructure 129, oracles are a type of agent that verifies real-world events and provides them to smart contracts 192. An oracle can also be used as a trusted third party. For example, it would be possible for an oracle to receive log messages 191 from computer system 101. For example, the oracle could forward the log messages to one or more IDSs 111, e.g., if they are selected and authenticated, to perform intrusion detection.

[0080] Wake-up calls: In some implementations, smart contracts 192 cannot execute themselves after a period has expired. So-called wake-up calls exist to trigger the execution of a smart contract 192. Wake-up calls are special nodes in the blockchain infrastructure that pay mining nodes 121 to execute specific smart contracts 192.

[0081] Computer system 101: Log messages 191 of this device are being analyzed.

[0082] IDS 111 is responsible for analyzing log messages 191 of computer system 101. In some examples, a plurality of IDSs may be present, with one or more of them being tasked with performing intrusion detection.

[0083] The following describes the functionality of System 90 in connection with intrusion detection using the flowcharts according to Fig. 2 , Fig. 3 as well as Fig. 4 explained in more detail.

[0084] Fig. 2 is a flowchart of an exemplary method. For example, the method according to Fig. 2 be carried out by an IDS, for example by the IDS 111 of the system 90 in the example of Fig. 1 In particular, the procedure under Fig. 2 for example, be executed by the processor 112 based on program code loaded from the memory 113.

[0085] In block 2001, communication takes place with at least one node of a distributed database infrastructure, for example with the mining node 121 of the blockchain infrastructure 129 in the example of Fig. 1 . This communication is carried out in order to obtain authorization for intrusion detection of a computer system - for example, computer system 101 - (see Authorization 193 in Fig. 1 ).

[0086] In one example, authorization could be based on a result value of a smart contract executed by the node.

[0087] Sometimes, a two-step authorization process could be performed: (i) If the result value is compatible with a registration information of the IDS 111, then the IDS can be pre-authorized; (ii) the IDS can then apply to be finally authorized, namely by sending the registration information to the blockchain infrastructure to deposit the registration information in the blockchain. If this application is successful, then the registration information is deposited in the blockchain, and the IDS 111 is finally authorized. This means that the IDS 111 could actively check whether it receives authorization to perform intrusion detection. In such a variant, the mining node 121 stores the IDSs 111 preselected for intrusion detection in the blockchain. The IDSs 111 then look up the blockchain by accessing a corresponding storage of the blockchain infrastructure, i.e.in the blockchain—whether they have been selected. In some examples, a final application for the intrusion detection contract may then be submitted.

[0088] In another example, the authorization could also be received as a command from the mining node. In this case, the IDS 111 can passively accept the authorization.

[0089] If authorization is received in block 2001, intrusion detection is performed in block 2002. In some examples, this may be based on an analysis of log messages from the computer system (see log messages 191 in Fig. 1 ). For this purpose, the log messages can be received from the computer system via a communication interface. This can occur, for example, in response to a corresponding request (see Block 2004), as described in more detail below.

[0090] The analysis in block 2002 may be based on at least one machine-learned algorithm.

[0091] For example, it would be possible for a specific algorithm, such as a specific machine-learned algorithm, to be selected from a multitude of possible candidate algorithms. This selection could be made, for example, based on a corresponding entry in the blockchain of the blockchain infrastructure 129. For example, a corresponding configuration could be communicated via authorization 193. Furthermore, it is possible for the operator of the computer systems 101, the IDS 111, oracles, the machine-learned algorithms, the smart contract, etc., to firmly anchor the necessary parameters for the correct operation of the entire system in the blockchain via a mining node, oracle, etc. when starting the blockchain-based log message analysis. Another implementation variant of bootstrapping could be to firmly anchor the necessary parameters in the blockchain when the blockchain is initially started.

[0092] Furthermore, the parameters during bootstrapping could also be simply a pointer to an external storage unit. Any parameters needed to operate the entire system according to the invention could be stored in this external storage unit. For example, the following parameters could be passed to the blockchain during initial startup: trusted oracles, approved IDSs, approved computer systems, etc. Such a configuration is sometimes referred to as bootstrapping.

[0093] In such an implementation, it is possible to operate an IDS without requiring the use of a central authority; instead, intrusion detection is performed dynamically based on authorization. Authorization can be selectively granted to one or more dynamically selected IDSs. This increases security because, for example, different IDSs can be entrusted with intrusion detection in different instances, making it more difficult for an attacker to corrupt the IDS. By obtaining authorization from a mining node, for example, as the result value of a smart contract executed by the mining node, the distribution of authorizations can also be made attack-proof.

[0094] Details of block 2002 are described below. For example, block 2002 could include blocks 2003, 2004, and 2005. However, these blocks 2003 to 2005 are generally optional.

[0095] For example, in block 2003, an application is made to deposit registration information. This registration information can be indicative of the identity of the IDS. For example, the registration information could include a unique identifier, e.g., a MAC address, a hardware code, a cryptographic key, etc. The registration information is deposited in the blockchain, i.e., it can be provided to the blockchain infrastructure. For example, the registration information could be provided to the mining node from which authorization was previously obtained. This node can then write the registration information, e.g., into the smart contract that was previously executed to implement the authorization for intrusion detection. To do this, the mining node can execute the smart contract and then solve a cryptographic puzzle to store the corresponding data in the blockchain.

[0096] In optional block 2004, a request is then sent to the computer system 101 to be monitored. The request concerns the implementation of intrusion detection and is indicative of the registration information. If the application in block 2003 was successful, the registration information is stored in the blockchain; by sending the request, which is indicative of the registration information, the computer system 101 is enabled to compare the request with the registration information stored in the blockchain to verify the authorization of the IDS 111. This increases security against tampering.

[0097] The request could include at least one of a public cryptographic key material and a certificate of the IDS 111 in conjunction with the registration information. In this way, a particularly high level of security can be achieved in the communication between the IDS 111 and the computer system 101.

[0098] In block 2005, the result of the intrusion detection is stored in the blockchain. For this purpose, a result value from the analysis of the log messages could be sent, for example, to the mining node from which authorization was received in block 2001 and / or a result value could be sent to the oracle and / or another third party (administrator, operator, etc.). However, this is only an example implementation. It would also be possible to execute a corresponding function of the smart contract. This would allow various mining nodes 121 of the blockchain infrastructure 129 to store a corresponding variable in a block of the blockchain.

[0099] Fig. 3 is a flowchart of an exemplary method. For example, the flowchart could be Fig. 3 be executed on a node of a distributed database infrastructure, for example on a mining node such as the mining node 121 of the blockchain infrastructure 129 according to the example of Fig. 1 . The following is an example of Fig. 3 described for an implementation in connection with the mining node 121; however, in other examples, it would be possible for the method according to Fig. 3 is executed by another node.

[0100] In block 2011, a smart contract is executed (see Fig. 1 , smart contract 192). For example, the smart contract could be executed when a timer event occurs and / or when an external request is received, for example, from a wake-up call and / or in response to an operational event on the computer system 101.

[0101] The following is an example of an operation-related event on computer system 101: It is assumed that computer system 101 is a field device in a production environment (e.g., a robot arm). If a new order is now sent to the robot arm to create a specific product, this new order can be viewed as a trigger event for executing the smart contract. If such a trigger event occurs, the integrity or log messages of the robot arm could be checked. This does not necessarily require the entire protocol to be run: It is sometimes sufficient to control the IDS 111 that has been selected (see variable 215 in block 203) and send the respective log messages to IDS 111 via channel 302.The robot arm can begin production, and only at a later point in time can the operator of the production facility verify, by checking variable 216 in block 204, whether the robot arm has not been tampered with, and thus the product can be sold. This can be referred to as an external trigger.

[0102] It is possible that the execution of the smart contract in block 2011 includes at least one of a random component, a time-varying component, a situation-varying component, and blockchain-based authentication. This means that depending on the situation and / or time, or even randomly, a different result is obtained during the execution of the smart contract.

[0103] This can ensure that the result of the execution of the smart contract cannot be predicted or can only be predicted with difficulty by an attacker, or that the execution of the smart contract cannot be manipulated or can only be manipulated with great difficulty by an attacker.

[0104] Then, in block 2012, an IDS is selected from a plurality of IDSs depending on a result of the execution of the smart contract 192. For example, a first subset of IDSs (including the IDS 111) could be selected from a plurality of potential candidate IDSs. This means that depending on the result of the execution of the smart contract, a different subset can be selected. A corresponding result value can be decisive for this selection.

[0105] Then, in block 2013, communication occurs with the selected IDS 111 to grant authorization 193 to perform intrusion detection. This is based on the selection from block 2012.

[0106] This authorization can be granted based on an application from the IDS 111 or, in general, from at least some of the plurality of candidate IDSs. The application can be made by those IDSs of the plurality of candidate IDSs that were pre-selected by a result value from executing the smart contract; this corresponds to a first selection stage. In a second selection stage, the pre-selected candidate IDSs can then provide an application containing their registration information. The mining node 121 can then attempt to deposit this registration information in the blockchain. If this is successful, d.h. If the application is successful, the respective IDS is authorized.

[0107] In some examples, it may be desirable to prevent an IDS from paying a very high gas price in block 2012 and thus being prioritized by all mining nodes, d.h. The deposit of the respective registration information is prioritized. To achieve this, the gas price can be predefined in advance via smart contract 192. A certain price window can also be specified. If the gas price is not lucrative for the mining nodes, this price window or the predefined (fixed) price should be increased for all nodes simultaneously. The price increase can occur via the oracle, via the IDS 111, or via another mechanism.

[0108] In optional block 2014, the result of the smart contract execution is stored in the blockchain. Alternatively or additionally, the identification of the computer system 101 for which intrusion detection is requested could also be stored in the blockchain. Alternatively or additionally, an identification of the selected IDS 111 could also be stored in the blockchain. This allows the process to be audited.

[0109] Fig. 4 is a flowchart of an exemplary method. For example, the method according to Fig. 4 be executed by a computer system for which intrusion detection is to be performed. For example, the method according to Fig. 4 from the computer system 101 of the system 90 according to the example of Fig. 1 The following are examples related to the execution of the procedure according to Fig. 4 described by the computer system 101, whereby corresponding examples could alternatively be executed by other computer systems.

[0110] For example, the procedure according to Fig. 4 executed by the processor 102 of the computer system 101 based on program code loaded from the memory 103.

[0111] In block 2021, registration information is received from IDS 111. IDS 111 has been tasked with performing intrusion detection. In this respect, block 2021 corresponds to block 2004 according to Fig. 2 The registration information is indicative of the identity of the IDS.

[0112] In block 2022, a verification of the registration information is then triggered. As a general rule, there are several ways to implement the verification. For example, the verification can be performed by comparing it with information stored in the blockchain. Computer system 101 could look it up in the blockchain accordingly. However, it would also be possible for the verification to be implemented as a functionality of the blockchain, such as smart contract 192. Computer system 101 can then trigger the verification with a corresponding request. In another variant, it would be possible to use a public-key infrastructure for verification.

[0113] Verification can ensure that an authorized request for log messages has been made.

[0114] If the verification in block 2022 was successful—i.e., a positive result is obtained—then in block 2023, log messages 191 are transmitted to the now authenticated IDS 111 so that it can perform intrusion detection. The transmission of the log messages 191 could also be delayed until, for example, a specific operational event occurs on the computer system 101. Alternatively or optionally, the log messages 191 could also be transmitted to the oracle until the IDS is ready to retrieve these log messages 191.

[0115] As a general rule, the transfer can be done directly or via a proxy, e.g. the oracle.

[0116] To implement block 2022, the IDS 111 may log on to the computer system 101 (see 302 in Fig. 5 ).

[0117] Fig. 5 illustrates aspects related to an exemplary implementation of the intrusion detection techniques according to various examples. Fig. 5 For example, the one related to the Figs. 2 bis 4 describe the examples described above.

[0118] The example of Fig. 5 uses the system 90. In Fig. 5 a blockchain 200 is shown as a distributed database implemented on the infrastructure 129. In FIG. 5 There are several IDSs 111-1 - 111-3. There are also several mining nodes 121-1 - 121-3.

[0119] The block chain 200 comprises chained blocks 201-205.

[0120] The blockchain 200 stores, among other things, smart contracts 220 (in Fig. 5 denoted by D1Contr) for the IDS 111. The smart contracts 220 are used to analyze the log messages 191 of the computer system 111 through a decentralized mechanism. An exemplary implementation concerns the smart contract 192.

[0121] In the example of Fig. 5 It is assumed that the technology for analyzing log messages, for example a corresponding algorithm, has already been deposited in the blockchain 200 of the blockchain infrastructure 129, in connection with the smart contract (see block 201). For example, a corresponding machine-learned algorithm (in Fig. 5 denoted by D1M) can be stored in the blockchain 200 via a corresponding variable 211. The variable can contain the machine-learned algorithm itself or implement a pointer to it.

[0122] The exchange of log messages 191 is enabled by an end-to-end secure channel 302. The authorization that authorizes IDSs 111-1 - 111-3 to perform the analysis of log messages 191 for intrusion detection is negotiated via smart contracts 220 and mining nodes 121-1 - 121-3 and IDSs 111-1 - 111-3. This functionality is explained in more detail below.

[0123] First, reference is made to step 1001. The smart contract 220 D1contr is stored in the blockchain 200 and is executed periodically after a certain time has elapsed (e.g., every 10 minutes or once a day). This time is also referred to as the activation interval and is stored as variable 212 D1Time in the smart contract 220. D1Time also provides information about how long the smart contract 220 is valid. An external trigger event would also be conceivable. Furthermore, the machine-learned algorithm or a hash value of the machine-learned algorithm is stored in the variable 211 D1M. The algorithm for analyzing the log messages 191 can therefore be selected based on the entry in the variable 211 D1M in the blockchain 200.

[0124] The smart contract 220 may be specific to the computer system 101. A different smart contract may be used for a different computer system.

[0125] Step 1002: Once the time specified by variable 212 has elapsed, the smart contract 220 D1Contr will be executed. The wake-up call 162 sends an order 301 to all mining nodes 121-1 - 121-3 to execute the register_randnr() function of the smart contract 220 D1Contr and to save the result of the register_randnr() function in the blockchain 200. The wake-up call also sends the following values ​​as input parameters to the register_randnr() function: Gas Price + IP Address + D1Contr + RandN + UniqID.

[0126] The unique identifier UniqID is a value that provides information about the last block(s) in the blockchain 200. This can be a hash value or an inherent mechanism of the blockchain 200 to perform this identification.

[0127] RandN is a random value that indicates which IDSs 111-1 - 111-3 can store their public key / certificate in the block chain 200 in order to perform the analysis later.

[0128] Below, a few example implementations related to steps 1001 and 1002 are described.

[0129] The execution of the smart contract 220 D1Contr can be triggered either by a wake-up call, the smart contract 220, or the oracle, or the smart contract 220 can execute itself. This means that a timer event, an external trigger, or an external request can evaluate the execution of the smart contract 220.

[0130] The gas price indicates how much the wake-up call is willing to pay for the processing of smart contract 220. If the gas price was too low, it could be that smart contract 220 or register_randnr() was not executed by mining nodes 121-1 - 121-3, and mining nodes 121-1 - 121-3 were processing other, even more lucrative smart contracts. Therefore, it is possible to increase the gas price gradually, similar to an auction, until the smart contract is successfully executed and the result of register_randnr() is stored in blockchain 200 (supply-demand pricing). This means that a predefined gas price—such as a price window—can prevent certain IDSs from offering a gas price that is far too high and thus being immediately selected as IDSs by the mining nodes.The gas price increase should also be regulated and transparent for all IDS analysis nodes so that no security gaps arise for attackers.

[0131] The IP address points to the address of computer system 101. The IP address can also be that of a proxy server. A proxy server may be necessary if computer system 101 is operated behind a firewall. The IP address is stored in the variable IPAddr in D1Contr, also using the register_randnr() function. The variable IPAddr could also be a pointer to another memory location. This other memory location could contain the actual information needed to establish communication with computer system 101 (e.g., IP address with additional information necessary for successful communication).

[0132] RandN is a random value and could be generated by the devices in (I) as follows: RandN= Hash(Random number / current time+date) or RandN= Hash(current block number).

[0133] UniqID is a hash value generated over the last n blocks 201-205 in the blockchain 200 (e.g. let x=3: UniqID = Hash (Block n-2 | Block n-1 | Block n )).

[0134] The register_randnr() function of the D1Contr smart contract 220 performs the following calculation: RN=Hash(RandN|UniqID). The execution of the smart contract 220 is therefore based on the random component RandN. If the blockchain infrastructure 129 and / or the smart contract 192 and / or the wake-up call 162 and / or the oracle 161 do not support a random value RandN, only RN=Hash(UniqID) can be used.

[0135] All mining nodes 121-1 - 121-3 that find the task of wake-up call 162 interesting execute the function register_randnr(). The mining nodes 121-1 - 121-3 then attempt to create a new valid block 202 for the block chain 200 by attempting to solve a cryptographic puzzle (e.g., Proof-of-Work, Proof-of-Stake). The mining node 121-1 - 121-3 that first succeeds in solving the puzzle creates the new block 202, saves this block 202 with the value RN in the smart contract 220 D1Contr, and receives payment. In this block 202, in addition to the value RN, the IP address of the computer system 101 is also stored under the variable 213 IPAddr. However, the implementation of variable 213 as an IP address is optional; alternatively or additionally, one or more other values ​​could be used to establish the connection to computer system 101, for example, if a firewall is used.If the computer system 101 is behind a firewall, additional parameters can be added to route packets through the firewall. Alternatively, if the communication takes place via a proxy, fewer parameters are required, as the proxy takes care of the routing and firewall issues.

[0136] Sometimes smart contracts do not allow mining nodes 121-1 - 121-3 to generate a random number and store it in the blockchain 200. Therefore, in the example described, the random generation was shifted to the wake-up call 162 / oracle 161 side (i.e., the value RandN). However, in other smart contracts 222, it might be possible for mining nodes 121-1 - 121-3 to generate a random value (e.g., RandN or similar) and store it in the variable 214 RN in the smart contract 220. This is an interesting approach because it is not deterministic which mining node 121-1 - 121-3 will generate a new block, and therefore the random number that is ultimately stored in the blockchain 200 would also be randomly selected by a node.

[0137] Since it is uncertain whether mining nodes 121-1 - 121-3 will succeed, it may sometimes be desirable to provide security against replay attacks. To prevent replay attacks, the UniqID is also used as an input parameter for the register_randnr() function. This means that executing the register_randnr() function requires authentication using the UniqID; this UniqID is—as described above—a value that provides information about the last block(s) in blockchain 200. This means that executing the smart contract also depends on authentication based on blockchain 200. For example, manipulation of the blockchain could be detected in this way. Alternatively and / or additionally, replay attacks could be prevented or detected in this way.

[0138] Step 1003: It is assumed that the gas price was lucrative and that 2 / 3 of all mining nodes 121-1 - 121-3 accepted the order. The result, i.e., the variable 214 RN of the register_randnr() function and the IP address as variable 213 IPAddr, is stored in block 202. Since the execution of the smart contract 220 also depends on the random number RandN (i.e., the smart contract 220 includes a random component), the value of the variable 214 RN is randomly selected and provides information about which IDSs 111-1 - 111-3 with the corresponding authorization 193 are requested to perform the analysis.

[0139] The value of variable 214 RN is therefore randomly chosen and provides information about which IDSs 111-1 - 111-3 are requested to submit an application to perform intrusion detection. This means that the value of variable 214 RN corresponds to a pre-selection of IDSs 111-1 - 111-3 within the authorization process. This pre-selection could be implemented as follows: In a first example: All IDSs 111-1 - 111-3 whose last 8 bits of the public key correspond to the last 8 bits of variable 214 RN are authorized to register in blockchain 200 under variable 215 IdentVar.

[0140] In a second example: The function modulo 256 (RN) and modulo 256 (PublicKey) results in an 8-bit value. All IDSs 111-1 - 111-3 where the values ​​match are authorized to register in the blockchain 200 under the variable 215 IdentVar.

[0141] There are numerous other examples of implementing this selection mechanism, e.g. checksum over RN and certificate.

[0142] From the above, it can be seen that the variable RN 214 typically applies to a plurality of preselected IDSs 111. However, sometimes only a single IDS or a specific number of IDSs are needed to perform intrusion detection. For this reason, sometimes only a portion of the IDSs that satisfy the selection condition determined based on RN are selected. The preselected IDSs are then stored in the blockchain 200 under the variable 215 IdentVar. For this reason, in some examples, it may be desirable for the IDSs to also participate in the negotiation for creating the variable 215 IdentVar: this may, for example, include an application to deposit registration information. When the registration information is actually deposited in the blockchain 200, the authorization is complete.

[0143] As an example, assume that three IDSs are being sought for intrusion detection or the analysis of log messages 191, and 30 IDS candidates are authenticated by the variable RN 214. These 30 IDS candidates can all apply in step 1003 to store their identity as part of the registration information in the variable IdentVar 215. The first three candidate IDSs that manage to register receive authorization to receive the log messages for analysis via channel 302. The selection of the three IDSs is random, since it cannot be determined which mining node 121 of the blockchain infrastructure 129 will solve the corresponding cryptographic puzzle (for storing the variable IdentVar 215 in block 203) and thus which IDSs will ultimately receive authorization.

[0144] This allows for double security: The determination of the result value, i.e., variable 214 RN, includes the random contribution; Furthermore, when depositing the registration information in the form of variable 215 IdentVar, there is also a competition whose outcome is not determined a priori. Manipulation to favor a compromised IDS 111-1 - 111-3 is therefore difficult or impossible.

[0145] This is described in further detail below: The preselected IDSs 111-1 - 111-3 attempt to have their public key stored as public cryptographic key material or their certificate, or the hash of these values, in the smart contract 220 under the variable 215 IdentVar by mining nodes 121-1 - 121-3. This means that registration information—indicative of the identity of the IDSs 111-1 - 111-3—is stored in the blockchain 200. To do this, the IDSs 111-1 - 111-3 instruct the mining nodes 121-1 - 121-3 to execute the register_pubkey() function of the smart contract 220 D1Contr. In addition, IDSs 111-1 - 111-3 send the following input parameters for the register_pubkey() function to mining nodes 121-1 - 121-3: PublicKey + GasPrice + UniqID. This corresponds to block 2003 of Fig. 2 Instead of public keys, the certificate or hash of the values ​​can also be sent as input parameters of the register_pubkey() function to the mining nodes 121-1-121-3 in order to register in the variable 215 IdentVar.

[0146] The variable 215 IdentVar can be implemented as an array of length x in the smart contract 220, each of which can store y bits. Example: If the SHA-256 hash of the certificate is to be transmitted to the mining nodes 121-1 - 121-3 as an input parameter of the register_pubkey() function, and three IDSs 111-1 - 111-3 are to be authorized to perform the final analysis, x can be chosen as 3 and y as 256.

[0147] If x=3, only three IDSs 111-1 - 111-3 can be stored in the smart contract 220 for analyzing the log messages 191. Since it is not certain which mining node 121-1 - 121-3 can solve the cryptographic puzzle, the IDSs 111-1 - 111-3 that have been registered are to be considered random.

[0148] This random component prevents attackers who control some IDSs 111-1 - 111-3 from registering specifically to analyze specific computer systems 111. It also prevents an IDS 111-1 - 111-3 from paying excessive gas to register, as this can circumvent the randomness, as all mining nodes 121-1 - 121-3 would like to earn a lot and might favor the attackers' registration requests.

[0149] A public key infrastructure can be used to verify whether IDSs 111-1 - 111-3 are actually preselected or are authorized to submit the application to register the variable 215 IdentVar. This public key infrastructure validation of the certificates / public key could be performed by smart contract 220, or by oracle 161, or by computer system 101, or natively by mining nodes 121-1 - 121-3.

[0150] Since it is uncertain whether mining nodes 121-1 - 121-3 will succeed, security against replay attacks may be desirable. To prevent replay attacks, the UniqID is also used as an input parameter for the register_pubkey() function.

[0151] The IDSs 111-1 - 111-3 can also function as a computer system 101 and participate in the blockchain 200 to have their own log messages verified by other nodes of the blockchain infrastructure. This ensures that the amount of money in the system always circulates between all computer systems, thus ensuring that the mutual analysis of log messages functions stably in the long term without the need for constant external transfer of money into the system (therefore: the money does not disappear and remains with the community. It simply constantly changes hands between the computer systems 101).

[0152] From the above description, it can be seen that the mining nodes 121-1 - 121-3 can be configured to execute the smart contract 220 in order to obtain the corresponding result in the form of the variable 214 RN. Depending on this variable 214 RN, one of the IDSs 111-1 - 111-3 can then be selected and - e.g., taking into account an application and a cryptographic puzzle - a corresponding authorization 193 can be granted to this selected IDS 111-1 - 111-3.

[0153] The identification of the computer system 101 in the form of the IP address as variable 213 is also stored in the blockchain. All of this can then be used by the one or more selected IDSs 111-1 - 111-3 to subsequently perform the analysis. Corresponding examples were described in connection with Fig. 2 : Blocks 2002 and 2004 and are described in greater detail below in connection with step 1004.

[0154] Step 1004: It is assumed that in block 203, the variable 215 IdentVar contains three entries. These entries correspond to the authorization 193 that three specific IDSs 111-1 - 111-3 (from a set of candidate IDSs) should perform the analysis of the computer system 101. For this reason, precisely these IDSs 111-1 - 111-3 establish the connection to the computer system 101 via an end-to-end secured channel 302 using the IP address (IPAddr) and authenticate themselves with their public key or certificate. This means that the selected IDSs 111-1 - 111-3 send a corresponding request. This is also indicative of the register information of the respective IDS 111-1 - 111-3 previously stored in the block chain 200, i.e., the public cryptographic key and / or the certificate. The computer system 101 checks whether the public key orthe certificate matches the entries in variable 215 IdentVar and allows the connection (additionally optional: if necessary, the public key or certificate of the respective IDSs 111-1 - 111-3 can be validated with a PKI by computer system 101). From this point on, the machine-learned algorithm D1M and the log messages 191 are transmitted from computer system 101 to IDSs 111-1 - 111-3. IDSs 111-1 - 111-3 analyze the log messages with the machine-learned algorithm and store the result either immediately, or only if an attack has been detected, or later at the end of the period D1Time in the block chain 200 (see block 204) under variable 216 Result, or as soon as possible. The result of the analysis is stored in the block chain 200 and / or can be forwarded directly to the administrator and / or the oracle and / or a third party.

[0155] Some optional implementation details related to step 1004 are described below.

[0156] The log messages 191 can either be transmitted all at once (e.g., always 1 megabyte) for analysis. However, the log messages can also be transmitted as a stream (log message stream). This means that as soon as a log message 191 has been generated by the computer system 101, it is sent to the IDSs 111-1 - 111-3 via the end-to-end channel 302. The advantage of the second method is that an attacker cannot conceal their attack trail using a log message stream, since the log messages 191 have already been transmitted to the selected IDSs 111-1 - 111-3. If the log messages were all transmitted as a whole, there is a possibility that the attacker could delete their trail from the log messages before the next transmission and thus remain undetected.

[0157] The IDSs 111-1 - 111-3 also receive additional parameters, such as the machine-learned algorithm, via the end-to-end channel. The authenticity and integrity of the machine-learned algorithm can be verified via the variable 211 D1M in the smart contract 220. It is also possible to store the machine-learned algorithm as such in the variable 211 D1M. If this is the case, the machine-learned algorithm does not need to be transmitted via the end-to-end channel, or the machine-learned algorithm does not need to be transmitted by a third party.

[0158] A public key infrastructure can be used to verify whether the IDSs 111-1 - 111-3 are actually authorized to analyze the log messages 191 and therefore establish an end-to-end channel to the computer system 101. This public key infrastructure validation of the certificates and / or the public key could be performed by the smart contract 220 or the oracle 161 or the proxy and / or the computer system 101 (for the computer system 101: at the time of establishing the communication of the end-to-end channel).

[0159] The results of the analysis can either be stored in the blockchain 200 using a MultiSig smart contract 220, or each IDS 111-1 - 111-3 verifies the integrity of the log messages 191 separately in a new block by storing the result in the variable 216 Result of the smart contract 220. The variable 216 Result could be an array with x free memory locations (x=3 in our application example).

[0160] Since the public key of IDSs 111-1 - 111-3 is stored in the variable 215 IdentVar, only these IDSs 111-1 - 111-3 can write to the variable 216 Result. Writing is again performed via the mining nodes 121-1 - 121-3.

[0161] In summary, techniques have been described above for performing an analysis of log messages 191 related to intrusion detection on a decentralized architecture based on smart contracts 220 and the blockchain 200. This differs from reference implementations in which log messages 191 are created and analyzed centrally on a trusted authority. Using the techniques described herein, such a central authority can be replaced by the decentralized architecture based on smart contracts 220 and the blockchain 200. Furthermore, the techniques described herein enable a significant reduction in the size of smart contracts 220, thereby reducing the operating costs for mining. An attacker cannot, or can only with difficulty, manipulate the analysis of log messages 191, even if they have gained control of computer system 101.

[0162] According to various examples, the analysis of log messages 191, for example, using a machine-learned algorithm, is not performed by the computer system itself. This is based on the recognition that the computer system itself could potentially be compromised. The techniques described herein make it more difficult for the attacker to gain control of the majority of all participants in the blockchain infrastructure 129, i.e., the mining nodes 121-1 - 121-3 as well as the IDSs 111-1 - 111-3, in order to falsify the intrusion detection. Specifically, this means: For a proof-of-work-based blockchain 200, the attacker must control more than 50% of all computing capacity (50% hurdle) in order to be able to store false results in the blockchain 200. Under certain circumstances, this hurdle can be reduced to 33%.With a Proof-of-Stake-based blockchain, the attacker must control more than 50% of the system currency to be able to store incorrect results in the blockchain. Furthermore, incorrect calculations incur penalties with this technology, which could make the attack economically unattractive.

[0163] The attacker cannot control which IDs 111-1 - 111-3 are stored in the blockchain 200 (variable 215 IdentVar) and are thus legitimized or authorized (variable 214 RN, random number) to perform the analysis. Therefore, the attacker has little chance of manipulating the analysis results.

[0164] Countermeasures such as gas price windows or constant gas price values ​​prevent the attacker from paying excessive gas prices to gain preferential treatment from the mining node. Furthermore, the 214 RN variable also makes it difficult for the attacker to select when they have the opportunity to apply for log message analysis at mining nodes 121-1 through 121-3.

[0165] With a stream of log messages 191, the attacker has no chance of erasing their presence or the attack process from the log messages 191, as these have already been transmitted to the IDSs 111-1 - 111-3. This makes it possible to reconstruct what happened and how the attack was carried out. When the log messages are transmitted to the oracle or proxy, the hurdle to erasing their presence or the attack process from the log messages 191 is very high, as they have already been transmitted to the oracle or proxy, and thus to the IDSs 111-1 - 111-3, protected by integrity and authenticity. This makes it possible to reconstruct what happened and how the attack was carried out.

[0166] Another advantage concerns integrity protection: Analysis results are stored in the blockchain 200 and therefore cannot be subsequently modified by attackers. All participants in the blockchain infrastructure 129 can see which computer system 101 is trustworthy / integral and which is not.

[0167] Another advantage concerns confidentiality: The content of the log messages is unreadable by participants if the log messages are transmitted confidentially and authentically / integrity-protected from computer system 101 to IDS 111-1 - 111-3. Participants and man-in-the-middle attackers can only see the results of the analyses and determine whether a computer system 101 has been attacked or not. Only the legitimate IDSs 111-1 - 111-3 can read the log messages 191.

[0168] Another advantage concerns scalability and maintenance: the easy extensibility of the peer-to-peer blockchain architecture. The blockchain community, not the operator, is responsible for all the problems of scaling and maintenance.

[0169] Another advantage concerns the size of the smart contracts 220 and the costs of operating the blockchain 200. The size of the smart contracts 220 is reduced, and therefore the operating costs are reduced. Specifically, this means: the reduced computational complexity of the smart contracts 220 means that the mining nodes are paid significantly less. Furthermore, the reduced size of the smart contracts 220 allows the technology described herein to also be operated on lightweight infrastructures. Another advantage concerns cost reduction: minimal costs on the operator side (no redundancy mechanisms, no central server needs to be operated, no high-performance system is required, no experts are needed to maintain the blockchain infrastructure, previously unfeasible business cases could become economically viable with a blockchain-based architecture).

[0170] The techniques described here can be used in a variety of applications. A few application scenarios are described below as examples. A first example application scenario concerns building technology. Here, IoT devices can analyze anomalies or log messages using smart contracts. Examples of IoT devices include intelligent building control systems, sensors, or actuators, etc. Another application scenario concerns the process industry and drives, energy management, and the digital factory: industrial components can be controlled by other industrial components via the blockchain. This can be useful, for example, in automation technology, drive technology, industrial software, and services.A third application scenario concerns mobility: signaling and control technology in rail-based passenger and freight transport, electrification solutions for rail and road transport, road traffic control and information systems, parking space management as well as electronic payment and toll systems for urban and long-distance transport can be secured by such technologies described here.

[0171] Of course, the features of the previously described embodiments and aspects of the invention can be combined with one another. In particular, the features can be used not only in the described combinations, but also in other combinations or on their own, without departing from the scope of the invention.

[0172] For example, various examples were described above in which an intrusion detection analysis is based on a machine-learned algorithm. However, this is just one example. Other examples may use a statistical algorithm or anomaly detection.

[0173] For example, various examples were described above in which a channel 302 is created between computer system 101 and IDS 111. However, this is only one example. In other examples, for example, the communication between computer system 101 and IDS 111 may be tunneled via an oracle or a proxy.

[0174] In the various examples described herein, the algorithm could be determined by an oracle or a third party. [1] Andreas M. Antonopoulos "Mastering Bitcoin: Unlocking Digital Cryptocurrencies", O'Reilly Media, December 2014 [2]Roger M. Needham, Michael D. Schroeder "Using encryption for authentication in large networks of computers" ACM: Communications of the ACM. Band 21, Nr. 12 Dezember 1978, [3]Ross Anderson "Security Engineering. A Guide to Building Dependable Distributed Systems" Wiley, 2001 [4]Henning Diedrich "Ethereum: Blockchains, Digital Assets, Smart Contracts, Decentralized Autonomous Organizations", CreateSpace Independent Publishing Platform, 2016 [5]"The Ethereum Book Project / Mastering Ethereum" https: / / github.com / ethereumbook / ethereumbook, Stand 5.10.2017 [6]Leemon Baird "The Swirlds Hashgraph Consensus Algorithm: Fair, Fast, Byzantine Fault Tolerance", Swirlds Tech Report SWIRLDS-TR-2016-01, 31.5.2016 [7]Leemon Baird "Overview of Swirlds Hashgraph", 31.5.2016 [8]Blockchain Oracles https: / / blockchainhub.net / blockchain-oracles /

Claims

1. Node (121, 121-1, 121-2, 121-3) of an infrastructure (129) of a distributed database (200) comprising a processor (122) and a communication interface (124), wherein the processor (122) is configured to load program code from a memory (123) and to execute it and to perform the following steps on the basis thereof: - implementing a smart contract (192, 220) in order to obtain a corresponding result value (214), - selecting at least one analysis device (111, 111-1, 111-2, 111-3) from a plurality of analysis devices depending on the result value (214), and - communicating with the at least one analysis device (111, 111-1, 111-2, 111-3) via the communication interface in order to grant the at least one analysis device (111, 111-1, 111-2, 111-3) an authorization (193, 214, 215) for intrusion detection for a computer system (101).

2. Node (121, 121-1, 121-2, 121-3) according to Claim 1, wherein the processor (122) is furthermore configured to perform one or more of the following steps on the basis of the program code: - receiving an application for storing registration information from the at least one analysis device (111, 111-1, 111-2, 111-3) and depending on the result value (214), wherein the application is indicative of an identity of the respective analysis device (111, 111-1, 111-2, 111-3), - storing the registration information in the distributed database in order to grant the authorization (193, 214, 215) in this way.

3. Node (121, 121-1, 121-2, 121-3) according to Claim 1 or 2, wherein implementing the smart contract (192, 220) for obtaining the corresponding result value (214) comprises at least one from a random component, a time-variable component, a situation-variable component and an authentication on the basis of the distributed database (200).

4. Node (121, 121-1, 121-2, 121-3) according to any of Claims 1 to 3, wherein the processor (122) is furthermore configured to perform one or more of the following steps on the basis of the program code: - storing an identification of the computer system (101) in the distributed database (200), and / or - storing the result value (214) in the distributed database (200).

5. Node (121, 121-1, 121-2, 121-3) according to any of Claims 1 to 4, wherein the smart contract (192, 220) is implemented if a timer event occurs and / or if an external request is obtained via the communication interface (124) and / or if an operation-related event occurs at the computer system (101) and / or if an external trigger occurs.

6. Node (121, 121-1, 121-2, 121-3) according to any of Claims 1 to 5, wherein a gas price is predefined for performing the process of storing the registration information in the distributed database.

7. System (90) comprising: - an analysis device (111, 111-1, 111-2, 111-3) comprising a processor (112) and a communication interface (114), wherein the processor (112) is configured to load program code from a memory (113) and to execute it and to perform the following steps on the basis thereof: - communicating with at least one node (121, 121-1, 121-2, 121-3) of an infrastructure (129) of a distributed database (200) via the communication interface (114) in order to obtain an authorization (193, 214, 215) for intrusion detection for a computer system (101), and - depending on whether the authorization (193, 214, 215) is obtained: carrying out the intrusion detection for the computer system (101) on the basis of an analysis of log messages (191) of the computer system (101) which are received from the computer system (101) via the communication interface (114), - the node (121, 121-1, 121-2, 121-3) according to Claim 1, and - a computer system (101) comprising a processor (102) and a communication interface (104), wherein the processor (102) is configured to load program code from a memory (103) and to execute it, and to perform the following steps on the basis thereof: - receiving registration information from the analysis device (111, 111-1, 111-2, 111-3) and via the communication interface (104), wherein the registration information is indicative of an identity of the analysis device (111, 111-1, 111-2, 111-3), - initiating a verification of the registration information, and - depending on a result of the verification: transferring log messages (191) of the computer system (101) to the analysis device (111, 111-1, 111-2, 111-3) and via the communication interface (104).