Techniques for a stimulated intrusion detection system

Abstract

The present disclosure relates generally to security solutions. More specifically, techniques (e.g., systems, methods, and apparatuses) are provided that implement an incentive-based intrusion detection system to detect malicious behavior against an asset. The incentive can entice or motivate a behavior to provide information that detects malicious behavior against the asset.

Description

[0001] Cross-reference to related applications

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 880,587, filed July 30, 2019, and also claims the benefit of U.S. Non-Provisional Patent Application No. 16 / 936,014, filed July 22, 2020, both of which are incorporated herein by reference in their entirety for all purposes. Technical Field

[0003] This disclosure generally relates to security solutions. More specifically, it provides techniques (e.g., systems, methods, and apparatuses) for implementing incentive-based intrusion detection systems to detect malicious activities against assets. The incentive can entice or encourage an actor to provide information for detecting malicious activities against assets. Summary of the Invention

[0004] This article describes techniques for incentivized intrusion detection, which can provide security solutions for one or more systems, such as information technology systems. Two common types of security solutions are detection-based (e.g., intrusion detection systems, antivirus, endpoint detection and response, etc.) and those using decoys (e.g., honeypots). Detection-based systems attempt to detect the presence of malicious actors (e.g., a device being used by a person) by using traces left on compromised systems, suspicious network traffic, and / or suspicious activity. This detection-based solution relies on comparing signatures to a database of malicious signatures. No unknown executables with newly signed signatures will be detected. Suspicious network activity provides a high false positive rate due to the overlap between malicious and benign behavior.

[0005] Decoy-based systems (such as honeypot systems) attempt to lure malicious actors into revealing their presence by mimicking a real system. Honeypot systems or other decoy-based systems do not provide valuable information, and any access to such systems is monitored by the system's and / or surveillance team. Decoy-based systems aim to detect the presence of malicious actors, rather than encouraging them to expose themselves. They are typically expensive solutions, and breach detection times are often slow (e.g., not fast enough to detect and / or identify malicious actors). Therefore, there is a need to reduce detection time and receive alerts about intrusions as quickly as possible.

[0006] The incentive-based intrusion detection techniques described herein leverage the fact that one of the primary goals of a malicious actor when intruding on an information technology system is to gain money or other incentives. For example, the incentive-based intrusion detection systems and methods described herein incentivize a malicious actor to access an asset and thus expose themselves. Accessing an asset can include downloading the asset, reading the asset, exposing the asset, etc. Instead of risking that the malicious actor will find potentially valuable information or compromise the information technology system, an incentive can be offered that the malicious actor can claim relatively anonymously. However, the presence of the malicious actor can be revealed at the time of the claim to notify the attacked party. For example, when an asset is maliciously accessed, a vulnerability of the system can be detected and information related to the vulnerability can be obtained. The incentive can enable the system to obtain the information in near real-time using a smart contract and a distributed ledger. The distributed ledger can enable tracking and ensure priority of claiming the incentive. The incentive can further deter the malicious actor from performing malicious acts. The incentive can be reduced or improved based on further actions or inactions. In some cases, the incentive can be deployed internally, in which case a customer of the system (e.g., a company or other user) can not draw unnecessary attention to the malicious actor.

[0007] The incentive can turn the attention of the malicious actor to finding and claiming the incentive instead of harming the attacked party. Additionally, the malicious actor can be tempted to claim the incentive as soon as possible because the incentive can be claimed by other malicious actors or can no longer be valid. Using distributed ledger (e.g., blockchain) technology, when the malicious actor claims the incentive through a smart contract, the information technology system (and in some cases a security team monitoring the system) is alerted to the presence of the malicious actor.

[0008] Encouraging the malicious actor to reveal their presence can reduce the time needed to detect the breach. This can be because the malicious actor is more likely to reveal themselves sooner if an incentive is available. Additionally, this will reduce the cost and impact of the breach because the information technology security team can receive an alert sooner compared to utilizing current information technology security tools.

[0009] Certain embodiments of the present disclosure include a method. The method can include configuring a repository on a digital environment. The method can also include identifying an asset for accessing the repository configured by one or more devices on the digital environment. The method can also include generating a smart contract for the asset. In some embodiments, multiple smart contracts can be generated and can be linked or chained together. Metadata can be linked to the smart contract. The asset can include the metadata and be deployed to the repository. The method can also include deploying the smart contract on a distributed ledger. The method can also include receiving at least a portion of the metadata to trigger the smart contract to provide the asset based on the access to the repository.

[0010] Certain embodiments of the present disclosure include a system. The system can include one or more data processors; and a non-transitory computer-readable storage medium containing instructions that, when executed by the one or more data processors, cause the one or more data processors to perform the methods described above and herein.

[0011] Certain embodiments of the present disclosure include a computer program product tangibly embodied in a non-transitory machine-readable storage medium including instructions configured to cause data processing apparatus to perform the methods described above and herein.

[0012] This summary of the application does not necessarily describe all features of the claimed subject matter nor does it identify key or essential features of the claimed subject matter. The subject matter should be understood by reference to the entire specification of this patent, any or all drawings and each claim.

[0013] The foregoing will be more readily understood when considered in reference to the following description, with reference to the accompanying drawings, in which: BRIEF DESCRIPTION OF DRAWINGS

[0014] The illustrative embodiments of the application will be described below with reference to the following drawings.

[0015] Figure 1 A block diagram illustrating a backend in embodiments of a blockchain incentivized intrusion detection system is shown;

[0016] Figure 2 A block diagram illustrating an application in embodiments of a blockchain incentivized intrusion detection system is shown;

[0017] Figure 3 A block diagram illustrating a reward creation method in embodiments of a blockchain incentivized intrusion detection system is shown;

[0018] Figure 4 A block diagram illustrating a subnet in embodiments of a blockchain incentivized intrusion detection system is shown;

[0019] Figure 5 A representation of a block in a blockchain in embodiments of a blockchain incentivized intrusion detection system is shown;

[0020] Figure 6 A flow diagram illustrating the actions of a malicious actor in a blockchain incentivized intrusion detection system according to some embodiments is shown;

[0021] Figure 7 A flow diagram illustrating the actions of a smart contract in a blockchain incentivized intrusion detection system according to some embodiments is shown;

[0022] Figure 8 A flow diagram illustrating a blockchain incentivized intrusion detection method according to some embodiments is shown;

[0023] Figure 9 is a flowchart of a blockchain incentivized intrusion detection method according to some embodiments; and

[0024] Figure 10 is a block diagram illustrating an example of a computing system architecture, according to some examples. DETAILED DESCRIPTION

[0025] Certain aspects and embodiments of the present disclosure are provided below. It will be apparent to those of ordinary skill in the art that some of these aspects and embodiments can be used independently and that some of these aspects and embodiments can be used in combination with others. In the following description, for the purposes of explanation, specific details are set forth in order to provide a thorough understanding of embodiments of the application. It will be apparent, however, that various embodiments can be practiced without using these specific details. The drawings and description are not intended to be limiting.

[0026] The following description is merely exemplary in nature and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the following description provides a description of exemplary embodiments according to the present disclosure. It should be understood that numerous specific details, locations, and / or configurations are set forth in order to provide a thorough understanding of the exemplary embodiments. It should be understood that the functions at attributes can be performed in a different order, and / or using configurations or apparatuses different than those set forth herein without departing from the spirit and scope of the application as set forth in the following claims.

[0027] System and network security issues are common in digital environments such as information technology systems. In digital environments, instances of unauthorized access to digital information are also common. Malicious actors can target these digital environments to gain valuable or private information, incentives, or other assets. Motivating malicious actors or intruders of information technology systems to reveal themselves is one method of learning the identity of the malicious actor, the method of attack, and information about the incident, and can be achieved using monetary incentives, recognition of their skills, or other incentives. To prove their presence, there can be certain assets (also known as artefacts) in the information technology system. The assets can include valuable information (such as private information, monetizable information, applications, recognition of skills, etc.) or any other data available in the digital environment that can motivate the malicious actor. The assets can contain certain information related to the associated smart contract, such as a monetary amount, compromised information technology property, a unique fingerprint of the asset, metadata, or other information.

[0028] A smart contract can exist on a distributed ledger (e.g., a blockchain). The smart contract can be used to connect a malicious actor and an owner of an incentive, providing relative anonymity compared to traditional client-server systems. Each of the malicious actor and the owner can have access to a digital storage device. The owner's digital storage device can be funded with an incentive to motivate the malicious actor to locate a vulnerability, and the malicious actor's digital storage device can be used to claim the incentive. Each respective digital storage device can be represented by a public key (e.g., a first public key in the attacker's digital storage device and a second public key in the owner's digital storage device). The public keys can be written within transactions and identify the sender of the transaction. For example, the owner's digital storage device can be used to transfer the necessary incentive to a smart contract, which can act as a deposit. The malicious actor's digital storage device can be used to claim the asset and receive the incentive from the smart contract. Using the unique components of the asset, only those who discover the asset can claim the incentive through the smart contract. Determining the legitimacy of the claimant can be mathematically verified using information in the asset, and the smart contract will not allow guessing the information in the asset.

[0029] Providing such a system presents challenges. First, assets needed to prove the existence of a malicious actor in an information technology network must be defined. Second, the assets must be deployed on heterogeneous information technology systems. The heterogeneous information technology systems can include physical or virtual servers with assets deployed at the operating system level, assets deployed on applications, assets deployed on online or offline information technology systems, and assets deployed at a lower level (e.g., at the chip level). Third, the smart contract must be defined with terms, conditions, and metadata to claim a monetary incentive. Fourth, the assets, incentives, and smart contracts must be managed. Fifth, the distributed ledger in which the smart contract resides and is executed must be monitored.

[0030] Current security solutions are unable to detect anomalous malicious activity in a timely manner, or are delayed or inaccurate. However, attackers will attempt to create new attack vectors (e.g., attack paths through IT systems) and modify old attack vectors to bypass traditional security solutions. This creates a constant competition between creating new attack vectors and improving attack definitions for detecting attacks.

[0031] As noted above, two common types of security solutions are detection-based (e.g., intrusion detection systems, anti-virus, endpoint detection and response, etc.) and honeypot-based systems (e.g., honeypot systems). Detection-based systems attempt to detect the presence of an attacker by using traces left on compromised systems, suspicious network traffic, and / or suspicious activity. Detection-based solutions can compare signatures against a database of malicious signatures to detect any malicious activity. Any unknown executable with a new signature will not be detected. Due to the overlap of malicious and benign behavior, suspicious network activity provides a high rate of false positives.

[0032] Honeypot-based systems (e.g., honeypot systems) attempt to lure attackers into exposing their presence by mimicking a real system. However, honeypot systems or other honeypot-based systems have no valuable information, and any access to such systems is monitored by the system and / or a security team monitoring the system. Honeypot-based systems attempt to detect the presence of an attacker, rather than encouraging them to expose themselves. Such systems can be costly and violation detection times are typically slow (e.g., not fast enough to detect and / or identify an attacker).

[0033] Another type of security solution is based on behavior analysis, which attempts to detect abnormal activity. However, due to the overlap of malicious and benign behavior, classifying suspicious activity is a difficult task. These tools typically have a high rate of false positives. Thus, a final decision by a human operator is often needed to improve the classification rate.

[0034] Vulnerability reward programs only encourage white hat participation because they need to reveal their identity. Additionally, their attack scope is well defined by the organizers and is typically time limited.

[0035] These and other problems and challenges can be addressed by implementing one or more incentivized intrusion detection techniques described herein. Embodiments of such a system can allow a customer to create a reward with the amount of proposed assets and incentives they define. After that, the customer can configure one or more target environments that are supported by the incentivized intrusion detection system. Once the target environments are configured, the incentivized intrusion detection system can create one or more child storage devices and provision them with one or more tokens from a master digital storage device for incentives. A smart contract can then be deployed on the target environments, and transactions on the smart contract can be written to a distributed ledger (e.g., a blockchain). The smart contract can be used to process incentive claims by malicious actors. One or more assets can also be deployed on the target environments. The system can monitor the claim activity on the distributed ledger (e.g., whether any incentives have been claimed) to issue alerts when needed.

[0036] Figure 1A block diagram of a back end in an embodiment of a incentivized intrusion detection system is shown. A client 105 can access the system 130 through a client interface 110, also referred to as a user interface or graphical user interface. The client 105 can be any suitable operator of the incentivized intrusion detection system, such as a system administrator, information technology specialist, or any other person capable of accessing a digital environment. The client interface 110 can be any suitable interface in operable communication with an application 115, such as a display. The application 115 can access a database 120. The database 120 can include attack records, funds injected into a digital storage device 125, or any other data useful to the application 115. The application 115 can provide the client 105 with access to the digital storage device 125. The digital storage device 125 can be configured to be funded by the client 105 in order to create an incentive to be offered on a smart contract 145. The smart contract 145 can be deployed on a distributed ledger 135 in a client system 150, which can include servers, databases, subnets, and / or other online and / or offline digital environments that can be targeted by malicious actors. For example, one asset can be deployed on one target environment 155, while multiple assets can be deployed in different physical, virtual online or offline information technology systems in the client system 150. Transactions on the smart contract 145 can be written to the distributed ledger 135.

[0037] Using the distributed ledger 135 and the smart contract 145, a malicious actor can be provided with pseudo-anonymity, and the incentive can be guaranteed to be available for claim. For example, the incentive can be a monetary reward available for digital transfer; an informational incentive, such as private or valuable data; or a recognition incentive, such as an incentive that recognizes the efforts of the malicious actor. In some cases, the malicious actor need not interact with any elements other than the distributed ledger 135, the smart contract 145, and the asset 140 to claim the incentive.

[0038] Linking the smart contract 145 and the asset 140 with a cryptographic algorithm (e.g., associated with the distributed ledger 135) can guarantee that even if the smart contract 145 can be public, only a malicious actor on a particular customer system 150 can claim the incentive associated with the smart contract. The smart contract 145 and the asset 140 can be constructed in a manner that replay attacks (i.e., repeated attacks against the same incentive) are not possible. Additionally, the asset cannot be forged and modified to claim another incentive. For example, the asset can include a nonce, an identifier (e.g., identifying the location of the asset), and the address of the smart contract 145. In one illustrative example, the asset can be composed of a concatenation of the nonce, the identifier, and the address of the smart contract 145. The asset data can then be signed (and in some cases hashed) with the private key of the contract owner, where the owner is the digital storage device 125 that generated the smart contract 145. The smart contract 145 can have the responsibility to verify that the signature is correct (e.g., that the asset 140 links to the smart contract 145). The signature verification can be done using the public address of the owner stored within the smart contract 145 during the creation phase, as further described herein. The nonce and the address of the smart contract 145 can be used to avoid replay attacks, while the identifier can identify the location of the asset, allowing the customer 105 to know which target environment 155 is compromised.

[0039] The attacker and the customer 105 can establish a relationship through the smart contract 145. When claiming the incentive, the customer 105 can only know the malicious actor's digital storage device and that a target environment 155 in the customer system 150 is compromised. The customer 105 can decide the properties of the reward (e.g., the set of incentives) to incentivize the malicious actor to expose themselves.

[0040] The alert can be triggered automatically because the properties of the distributed ledger 135 can guarantee that when the malicious actor claims the incentive through their smart contract 145, the transaction is recorded on the distributed ledger 135. The distributed ledger 135 can be monitored by the application of the incentive-based intrusion detection system (e.g., the activity manager of the application), as further described herein. The transaction associated with the incentive claim cannot be revoked, denied, or modified because it is recorded to the distributed ledger 135. Thus, by providing the incentive, the time to detect the intrusion can be reduced because the presence of the attacker is detected through the monitoring of the distributed ledger 135 as soon as the incentive is claimed.

[0041] Figure 2 A block diagram of the application in an embodiment of the incentive-based intrusion detection system is shown. As Figure 2As shown, the client 105 is a user of the application 115. The client 105 can interact with the application 115 through the management console 205. The client 105 can create and manage one or more campaigns, fund the digital storage device, and monitor and react to alerts triggered by the campaign monitoring engine 255 (described in more detail below). Multiple roles can separate the use of the application 115 and avoid client theft of incentives. For example, an auditor can audit the use of the application to see which user deployed how many assets with incentive amounts. A monitor can access alerts triggered by the campaign monitoring engine 255. A treasurer can access the digital storage manager 260 and can provide funding. An administrator can create and deploy assets and define target environments. The administrator can receive funding from a client with the role of treasurer. The administrator can be a highly trusted user with high security settings, can be configured to separate the deployment of assets and the definition of target environments, ensuring that no one knows where and when incentives are deployed. If enough target environments are defined, then deployment can be defined without knowing the exact location of the asset. A root account can have all the permissions of the application and can be used during the initial setup of the application. The root account can be used as a last resort. Any use of this account can be flagged to the auditor and the monitor.

[0042] A malicious actor (not shown) can be the target of the incentivized intrusion detection system. The malicious actor can be an individual using a computing device to attack the target environment 240 or a group of people using one or more computing devices to attack the target environment 240. The system can attempt to motivate the malicious actor to reveal his presence with one or more incentives. The reveal process can use one or more smart contracts 285 to process, which can use asymmetric keys to guarantee the pseudo-anonymity of the malicious actor to claim one or more incentives. The incentives can represent currency and utility tokens from various distributed ledgers 275. The incentives can be tokens claimable from the smart contract 285.

[0043] The asset 230 can be evidence that a malicious actor must provide when claiming an incentive using the smart contract 285. For example, the asset 230 can be data required to claim an incentive associated with the asset 230 through the smart contract 285. In some cases, multiple assets can be linked to one smart contract 285 and deployed on the same target environment 240. The smart contract 285 can be associated with a phase. The phase can be associated with a reward (e.g., the reward 250). As described in more detail below, a reward can include one or more phases, each of which can be claimed after a previous phase of the reward. In certain cases, a phase can have multiple assets. In certain cases, an asset can be associated with a particular phase. Each phase can be associated with a unique smart contract (e.g., a first phase associated with the smart contract 285, a second phase associated with another smart contract, and so on). The smart contract will define the steps or parameters required to claim one or more incentives contained in the smart contract using the asset of the phase. The asset can contain information and metadata for finding the appropriate smart contract 285, such as the amount of the incentive and / or the duration of the validity of the incentive. For example, the duration of the validity can be shortened (e.g., 30 minutes for the incentive to rotate on the target environment) to encourage the malicious actor to expose themselves quickly. To avoid anyone else using the asset 230 to claim the incentive, asymmetric cryptography and hashing algorithms can be used. A hashing protocol can be used to hash the metadata of the asset. The resulting hash can be signed with the private key of the owner of the contract. The contract can use the public key of the owner (i.e., its address) to check the validity of the signature (thus, asymmetric encryption). Any change in the metadata of the asset will modify the hash value and invalidate the signature.

[0044] The smart contract 285 can represent the terms and conditions between the parties and can reside in the distributed ledger 275. The distributed ledger 275 can include any suitable distributed ledger, such as a blockchain, Ethereum, or another distributed ledger. Additionally, the distributed ledger 275 can automatically validate and perform any type of operation that can be triggered by satisfying certain conditions. The smart contract 285 can link the asset 230 to the incentive (or in some cases, to multiple incentives). When a malicious actor finds the asset 230, the computing device used by the malicious actor can provide the asset 230 to the associated smart contract on the distributed ledger 275 to claim the incentive. When the malicious actor claims the incentive using the smart contract 285 with the appropriate parameters (e.g., metadata), the incentive can be transferred (from the digital storage device 280) to the malicious actor's digital storage device and the transaction can be written to the appropriate distributed ledger 275. To facilitate the transfer of the incentive to the malicious actor's digital storage device, a script to claim the incentive can be included with the asset 230. In this case, the script can include a command that can be executed by the malicious actor to claim the incentive using the metadata as a parameter. If the malicious actor does not trust the script, he can recreate his own equivalent script. The malicious actor can also execute the script on the target environment or a machine controlled by the malicious actor.

[0045] The customer 105 can select several options to limit the smart contract 285 and encourage the malicious actor to claim the incentive as soon as possible. For example, the value of the incentive can decrease over time, the incentive can be time-limited (e.g., the duration for which the incentive is valid can be set to a particular value), etc. Additionally, the asset can be rotated. Typically, the asset can be invalidated on the current target environment and another asset in the same target environment can be deployed, i.e., not in the exact location of the target environment, forcing the malicious actor to search for it again.

[0046] In some cases, the smart contract 285 can not necessarily contain the full amount of the incentive. For example, using the example of using a token as the incentive, the smart contract 285 can need to contain at least the number of tokens required for the asset with the maximum incentive amount. The application 115 can automatically provide and debit funds from the smart contract 285 as needed. For example, when an asset 230 is used to claim an incentive, the application 115 can provide the smart contract 285 with the funds required for the associated incentive. Additionally, if the asset is invalidated, the application 115 can debit the funds from the smart contract 285.

[0047] As described above, the reward 250 can include one or more stages. Multiple rewards 250 can exist in parallel. For a reward with multiple stages, each stage of the reward can be claimed after the previous stage of the reward (e.g., the first stage of the reward can be claimed first, then the second stage of the reward, then the third stage, and so on). Each stage can be associated with a unique smart contract (e.g., smart contract 285), each defining the parameters (e.g., metadata) required to claim the one or more incentives it includes using one of the assets of the stage. In some cases, there can be advanced stages, where an advanced stage can require third-party verification to liberate the incentives. The third party can have the decision power to liberate or not liberate funds, depending on the quality of the report provided by the malicious actor. This can require the third party to maintain a trust relationship with the actors in the system.

[0048] In some examples, there can be two types of digital storage devices 280, including a main digital storage device and a sub-storage device. The main digital storage device can be linked to one reward 250. The sub-storage device can be linked to one stage of the current reward 250. A digital storage device (main digital storage device or sub-storage device) in the digital storage devices 280 can include tokens of a particular distributed ledger 275, which can be associated with one stage of the reward 250, as described above. The client 105 can send funds to the main digital storage device. The sub-storage device can be associated with a smart contract 285 created by the reward 250 at the time of creating the reward. When the sub-storage device is used to deploy the smart contract 285, it becomes the owner of the smart contract 285.

[0049] The target environment 240 can be where the assets are deployed using the asset deployer 220. This can represent one or more information technology entities, such as a computer, a server, a database, a smartphone, a remote cloud instance (e.g., an Amazon Web Services (AWS) server), a mail server, and the like, or files and software deployed manually by the client 105.

[0050] The distributed ledger 275 can be a decentralized database that can be managed by various participants. There can be no central authority that acts as an arbitrator or watchdog. A blockchain can be a distributed ledger 275 where all data is distributed to all participants. The distributed ledger 275 can include smart contracts 285 and digital storage device 280 amounts that can be updated by transactions executed on the distributed ledger 275. Possible actions on the distributed ledger 275 can be, for example, minting (token creation), spending (transferring tokens), and destroying (claiming) tokens. One example of a distributed ledger can be a blockchain or Ethereum. Other distributed ledgers can also be used.

[0051] When a malicious actor claims an incentive from a smart contract 285 of an ongoing reward 250, the campaign monitoring engine 255 can trigger an alert. The alert can be displayed on the management console 205 and can be exported or pushed to an external alert system 270.

[0052] The customers 105 and external applications 245 can access the application 115 through its programmatic interfaces, such as the customer interface 110 and / or the API. For example, a customer 105 can query the campaign monitoring engine 255 to review any alerts that have been triggered.

[0053] The application 115 can include the management console 205, the kernel 210, the database 235, the reward manager 215, the smart contract manager 265, the asset generator 225, the asset deployer 220, the digital storage manager 260, and the campaign monitoring engine 255.

[0054] The management console 205 can be one of the components of the application 115. The management console 205 can be an interface that can display various information from different components of the application 115. For example, using the management console 205, a customer 105 can create a reward 250 program, trigger the deployment of associated assets 230, ephemeral digital storage devices 280, tokens, and smart contracts 285, and monitor the associated smart contracts 285.

[0055] The kernel 210 can be a coordinator responsible for coordinating all components of the application 115. A customer 105 can send requests to the kernel 210 through the management console 205, and the kernel 210 coordinates and dispatches the appropriate components.

[0056] The database 235 can be a component of the application 115 that stores all configurations required by the application 115, as well as information about reward 250 programs, assets 230, alerts, target environments 240, customers 105, and the like.

[0057] The reward manager 215 can be another component of the application 115. The reward manager 215 can be responsible for managing one or more rewards 250. The reward manager 215 can provide the client 105 with an appropriate selection of rewards 250 that can be created based on the total funds available in the digital storage device 280 based on prior and ongoing rewards 250. When the creation of a reward (from one or more rewards 250) is initiated, the client 105 can decide how many assets 230 the asset generator 225 will generate. The reward manager 215 can prompt the client 105 (e.g., through the management console 205) to send funds (from the digital storage device 280) to the main digital storage device generated by the digital storage manager 260. Based on the number of phases selected for the reward, the smart contract manager 265 can be queried to create one or more appropriate smart contracts 285 linked to the assets 230. The reward manager 215 can use the database 235 to track ongoing and prior rewards 250. As used herein, an ongoing reward (also referred to as a current reward) is a reward that has unclaimed outstanding incentives, while a prior reward is a reward that has claimed all incentives. A prior reward can also be an expired reward. An expired reward can automatically invalidate all assets.

[0058] The smart contract manager 265 can manage the smart contracts 285. When a smart contract 285 is deployed, the smart contract manager 265 includes the necessary information and metadata that links to the required assets 230 and is stored in the database 235. The smart contract manager 265 can use funds from a sub-storage device (from the digital storage device 280) that is specific to the current smart contract 285 to provide one or more incentives. The smart contract manager 265 can store information related to the smart contract (e.g., terms, incentives, metadata, etc.) in the database 235 and on one or more distributed ledgers 275.

[0059] The asset generator 225 can be responsible for generating assets 230, which, as described above, are data required to claim incentives through a smart contract. For example, a malicious actor must provide assets as evidence of using a smart contract to claim an incentive. The asset generator 225 can use the database 235 to track the assets 230 generated. When a client 105 creates a new reward 250, he can select the number of assets 230 generated for the reward 250.

[0060] The asset deployer 220 can be responsible for deploying assets 230 on target environments 240. The asset deployer 220 can use the database 235 to track the assets 230 deployed. When a client 105 creates a new reward 250, he can decide one or more target environments (e.g., including the target environment 240) on which he wishes to deploy assets 230.

[0061] The digital storage manager 260 can be responsible for managing the digital storage devices 280. The digital storage manager 260 can track the remaining amount of money in the digital storage devices 280 and can write transactions on the appropriate distributed ledger 275. When a reward 250 is created, the digital storage manager 260 can create a master digital storage device (from the digital storage devices 280) to which the customer 105 needs to send money. When a reward 250 is created, a digital storage device 280 can be created with defined incentives. These incentives can be referenced in one or more smart contracts from the smart contracts 285 associated with the reward 250. The digital storage manager 260 can store information related to the digital storage devices (e.g., amount of money, etc.) in the database 235 and on the appropriate distributed ledger 275.

[0062] The activity monitoring engine 255 can be responsible for monitoring the distributed ledgers 275 on which the smart contracts 285 reside. When a malicious actor claims an incentive of a smart contract 285 using the appropriate asset 230, the claim can trigger an alert that is forwarded to the management console 205 and / or stored in the database 235. In some cases, the activity monitoring engine 255 can forward the alert to an external alert system 270. The external alert system 270 can access the activity monitoring engine 255 through its application programming interface (API).

[0063] Figure 3 A block diagram of a reward creation method in an embodiment of the incentive-based intrusion detection system is shown. In a first step, the customer 330 initializes the reward creation at initialization step 305. During the initialization step 305, the customer 330 can apply the application 115 configuration for the target environment, the customer and the roles, and the alerts on the incentive-based intrusion detection system 300. The application 115 can be configured in multiple ways: regular settings and per-reward settings. The per-reward settings can be used on the application 115, such as the survival time of the reward program and the configuration of the reward metadata, such as information describing the reward target, on which type of target environment the asset should be deployed, the maximum amount of incentive available, etc.

[0064] Some general settings can be configured before creating the first reward. First, one or more target environments can be defined by adding the required connection details. There are many examples of supported target environments and required information. In one illustrative example, on a Linux machine, the application 115 can be able to connect to a Secure Shell (SSH) protocol based connection to place assets through, for example, a relay 415 or directly from the asset deployer 220. SSH is a cryptographic network protocol for securely running network services over an unsecured network. The SSH key used can be linked to a customer 330 that has been granted access to perform administrative functions, known as sudo privileges. Having sudo privileges can allow the following actions: placing incentives, placing assets in the root user’s home directory, opening specific ports and running a dummy application answer on that port as advertised on the website, broadcasting the presence of the application on a multicast address, and placing a text file in a known location to state that there is a reward on the machine. Similar configurations can be used on Windows machines.

[0065] Various other implementations can also be used. For example, on Kubernetes, the target environment can be a pod in a specific namespace with a specific name. In a database with credentials, the application 115 can write assets in a specific table or schema. On a mail server with a specific email account, the application 115 can create an email with details on how to find and claim the incentive. On Amazon Web Services (AWS), Azure, Google Cloud (GCP), or other cloud vendors, using API keys, the application 115 can spawn virtual machines with one or more assets deployed on each virtual machine. Manually, the application 115 can provide the customer 330 with a way to download the assets so that the customer 330 can place the assets. The assets can be of different types, such as files, programs, etc. Manual placement can be optional and can allow another customer to obtain the assets with reduced risk.

[0066] Since funds can need to be transferred to the primary digital storage device when creating a reward, the customer 330 can decide to store the funds locally or in a hardware storage device. For example, the customer 330 can store the tokens of the digital ledger on a software storage that is directly accessible from the application 115 as it processes it. Another possibility is to use a hardware storage device that is independent of the application 115 that cannot control it. The customer can provide the hardware storage device. The application 115 will request funds from the hardware storage device that requires customer confirmation. However, the hardware storage device can cause privacy-related issues since a malicious actor can obtain information about the reward.

[0067] In some embodiments, the administrator can be a customer 330. The administrator can decide to deploy assets using a multi-admin signature. The application 115 can force the customer 330 to use a multi-signature when the application 115 is configured in a way that requires a high level of security. In other words, individual customers can be prohibited from deploying assets without confirmation. Using a multi-admin signature, a reward can only be deployed when all of the specified administrator customers agree, which avoids having only one administrator customer approve an asset. The goal can be to avoid any single customer 330 deploying an asset to a known location, going to this location, and claiming the incentive. In some embodiments, manual deployment of assets can be disabled for the multi-admin signature mode. The administrator customer can decide how many rewards can be turned on at the same time and how much available funds can be claimed.

[0068] The alert can also be configured as to where the alert is sent by the activity monitoring engine 255 (e.g., via short message service (SMS), email, transmission control protocol (TCP) and transport layer security (TLS), etc.). Additionally, the fields can be configurable and can be added by the customer. The administrator can create other customers of the application 115 with more or less limited permissions. The administrator customer can also create and revoke API keys that other applications use to query various components of the application 115. The customer 330 can also create network maps with associated different risk levels. The target environments can be specified with a risk level. This can allow the application to compute a recommended incentive amount and suggest which target environment assets should be deployed to create a recommended path for an attacker.

[0069] Once initialization 305 is complete, the incentivized intrusion detection system 300 is ready to create a reward 335. The reward can be defined at a define step 310. Defining a reward can include defining the phases, assets, and target environments, and the customer 330 sends the required funds to the digital storage device. When the customer 330 creates a new reward, he can be required to create one or more assets that will be linked to the reward. As previously mentioned, each reward can have one or more phases. For example, the first phase of a reward can be defined as a malicious actor discovering an asset. The second phase of a reward can be used to provide the malicious actor with the possibility of sending a report to a trusted third party about how the system was compromised. If the report provides enough information to fix the problem, the third party can verify the correctness and can release the funds to the attacker (e.g., to the attacker’s digital storage device). The report can be defined by the trusted third party and can include any or all of the following information: date of compromise, method of vulnerability detection, method of exploit, other servers in the compromised customer environment, other potential problems discovered by the malicious actor, etc. More phases are possible, for example, to encourage the malicious actor to follow a specific path.

[0070] The number of assets for the reward is determined by the customer 330 and can be determined based on the range the customer 330 wants to set for the reward. In one example, the reward can cover gaining access to any computer used by employees of the target environment. In another example, the reward can cover a network server that has multiple assets deployed. For each asset, one or more target environments can be defined. In some embodiments, the same asset can be deployed to multiple target environments; however, the incentive can only be claimed once. Multiple assets can be deployed on the same target environment, e.g., on the same Linux machine, on the same Kubernetes cluster, etc. The amount of the incentive can be determined by the customer 330. If possible, the application can provide a recommendation for the amount based on previous rewards, the type of target environment, etc. The lifetime of the asset can also be specified. A short lifetime can be recommended to encourage malicious actors to quickly claim the reward.

[0071] The customer can define the smart contract associated with each phase. For example, the customer can decide on the amount to send to the smart contract initially (e.g., the minimum possible amount is the value of the highest incentive associated with the smart contract) and the lifetime of the incentive (i.e., how long the incentive can be claimed). The application can then create the main digital storage and require the customer 330 to transfer sufficient funds to it to cover the reward.

[0072] Once the token program 340 is defined in the definition step 310, it can be deployed in the deployment step 315. A sub-storage can be generated per smart contract. Sufficient funds for the incentive can be transferred from the main digital storage to the sub-storage. The smart contract can be deployed on the distributed ledger. The assets can be generated and deployed on the target environment.

[0073] Once the assets are deployed, they can be ready to be discovered 345 and the deployed smart contract 350 can be monitored in the monitoring step 320. The activity monitoring engine 255 can monitor for any events. When an event is detected that is related to incentive claiming, an alert can be generated.

[0074] The assets can be deployed in such a way that it can not be difficult for any malicious actor 355 that knows the system to understand where they can be. When a malicious actor 355 discovers the assets, the malicious actor 355 is incentivized in the incentive step 325 to claim the incentive as soon as possible using the lifetime of the asset and the smart contract and the amount of the incentive.

[0075] Figure 4 A block diagram showing a subnet in an embodiment of the incentive-based intrusion detection system. As Figure 4As shown, the application 115 can reside in the cloud. The application 115 can communicate with the relays 415, 425 that exist on the subnets 405, 410, respectively. The subnets can exist in the customer system 150. Each subnet 405, 410 can have a target environment 420, 430, respectively. In some embodiments, each subnet 405, 410 can cover a different area of the customer system 150. Although shown and described as having two subnets 405, 410, it is contemplated that any number of subnets having any number of target environments can exist in the customer system 150.

[0076] Figure 5 A representation of a block in a blockchain in one example embodiment of a incentivized intrusion detection system is shown. As used herein, the term "blockchain" can be used as an example of a "distributed ledger." An example blockchain suitable for the purposes described herein can be Ethereum, which can be used for smart contracts. Smart contracts can run on the blockchain to ensure permanent storage of their data and the extreme difficulty of their data being tampered with or altered. In some embodiments, a smart contract can run by executing a script, verifying the results of the script, and storing the smart contract and its results in a block. Generally, a block can include an incremental block number, a hash value, a reference to a directly preceding block, a proof-of-work, and / or one or more transactions of executed smart contracts. In some examples, a block can also include a timestamp, a nonce, and identifiers related to a sender and / or a recipient.

[0077] For example, Figure 5 Three consecutive blocks of a blockchain are shown: block 0 500, block 1 501, and block 2 502. Block 0 500, for example, includes an index (0) that increases as subsequent blocks are created. For example, block 1 501 has an index of 1, and block 2 502 has an index of 2. Block 0 500 also includes a timestamp that represents its date and time of creation. As shown, a block with a later index can have a timestamp with a later date and / or time than a preceding block. Block 0 500 also includes data; in this case, block 0 500 represents a +1000 funding event to produce a digital storage device. Block 0 500 can also include a hash value of its data and a previous hash value. In this case, the previous hash value can be 0 because block 0 500 is the first block of the blockchain.

[0078] On the other hand, block 1 501 represents a subsequent block in the blockchain. Block 1 501 represents a claim of an incentive through a smart contract associated with the blockchain (e.g., a smart contract associated with the first phase of the reward). Specifically, block 1 501 indicates a value of +1000 digital storage devices reduced by -55. Block 1 501 can also indicate an identifier of the claimant; specifically, attacker 1. Block 1 501 can also include a hash value of its data, as well as a hash value of block 0 500.

[0079] Similarly, block 2 502 represents a subsequent block in the blockchain that occurs at a timestamp after block 1 501. Block 2 502 represents a claim of another incentive through another smart contract associated with the blockchain (e.g., a smart contract associated with the second phase of the reward). Specifically, block 2 502 indicates a value of +945 digital storage devices reduced by -62. Block 2 502 can also indicate an identifier of the claimant; specifically, attacker 2. In some cases, the claimant can include the same claimant (attacker 1) as the claimant of the incentive associated with block 1 501. Block 2 502 can also include a hash value of its data, as well as a hash value of block 1 501. By including the hash value of the previous block of each block in the current block, the blockchain becomes unbreakable and immutable, providing a number of security benefits.

[0080] Figure 6 A flowchart showing the actions of an attacker in a incentivized intrusion detection system, according to some embodiments, is shown. After a customer creates a reward, one or more assets can be deployed on one or more target environments, and one or more smart contracts can be provided on a distributed ledger. The system can be waiting for a malicious actor to discover the assets and claim the incentives using a process that can be executed in the target environment. The target environment can be any online or offline digital environment, such as a corporate network or any other location that a malicious actor can access and can deploy assets.

[0081] At step 610, the malicious actor 605 can gain access to the target environment where the asset is deployed. At step 615, it is determined whether the malicious actor 605 discovers the asset. If the malicious actor 605 does not discover the asset, the process ends at step 620. If the malicious actor 605 does discover the asset, it is determined at step 625 whether the malicious actor 605 wants to claim the incentive. When the malicious actor 605 discovers the asset, the asset can include information needed to understand its purpose and how to use it. For example, the asset can include text that provides various information (e.g., an explanation of what the asset is, an explanation of how to verify that the incentive exists and can be claimed with the required metadata to claim, an explanation of how to claim the incentive, an explanation of any next steps, such as an explanation of where to find it, etc.), a script of an offer to claim the incentive, and the metadata needed to discover the associated smart contract and claim the incentive. The malicious actor 605 can be informed in the text that a digital storage device is needed to receive the funds. The asset can be deployed on the target environment in such a way that it is easy for the malicious actor 605 to discover it. Additionally, it can be relatively simple for the malicious actor 605 to verify the authenticity of the asset.

[0082] If the malicious actor 605 does not want to claim the incentive, the process ends at step 620. The decision to claim the incentive can be up to the malicious actor 605. Sufficient incentives are provided by the client to entice the malicious actor 605 to reveal itself. In some embodiments, the systems described herein can help make the decision by basing the sufficient incentive on several parameters and statistics. For example, the systems can apply artificial intelligence or machine learning to decide how much of an incentive amount is likely to attract the malicious actor 605. The goal can be to provide a sufficient incentive compared to how difficult it is for the malicious actor 605 to discover the asset in the target environment. This can depend on how the client prices its data and information technology systems. Additionally, statistics from previous rewards, rewards from other clients, etc. can be used. Parameters can include the number of central processing units (CPUs), random access memory (RAM), and disk storage, the number of processes running, the environment in which this target environment is located, the number of other information technology systems in the same subnet as this target environment, etc.

[0083] If the malicious actor 605 does want to claim the incentive, then at step 630 it is determined whether the claiming process should be automatic or manual depending on whether the malicious actor 605 decides to use the provided script on the target environment or another malicious actor controlled machine. If the claiming process is manual, then at step 640 the asset resolution metadata is parsed and used to claim the incentive. For example, the malicious actor 605 can download the provided script from a website to claim the incentive. The script can require the malicious actor 605’s digital storage device and the path to the asset or its metadata. In another example, the malicious actor 605 can create his own script to claim the incentive by using the metadata in the asset. If the claiming process is automatic, then the provided script (which includes the required metadata) can be used at step 635 to claim the incentive. If the malicious actor 605 wants to claim the incentive from another machine, then manual claiming can be useful.

[0084] Regardless of whether the claiming process is manual or automatic, at step 645 the malicious actor 605 can use the asset’s metadata and his digital storage address to call the claim function of the smart contract. The asset’s metadata can include, for example, the smart contract address, the asset identifier, a cryptographic random number (e.g., an arbitrary number), the incentive amount, etc. When the function of the smart contract is called, the process can move to the distributed ledger where the smart contract resides and execute its function there. The function of the smart contract can be called by the malicious actor 605 using the asset’s metadata and his digital storage address. The function of the smart contract can be called by the malicious actor 605 using the asset’s metadata and his digital storage address. The function of the smart contract can be called by the malicious actor 605 using the asset’s metadata and his digital storage address. The function of the smart contract can be called by the malicious actor 605 using the asset’s metadata and his digital storage address. Figure 7 Further steps are discussed.

[0085] Figure 7 A flowchart of actions on a smart contract in an incentive-based intrusion detection system is shown in accordance with some embodiments. Once the malicious actor 605 calls the claim function of the smart contract using the asset’s metadata and his digital storage address at step 645, it is determined whether the claim function of the smart contract is valid at step 705. This can be achieved by requesting the malicious actor 605 to provide the asset’s metadata and signature to the claim function. The smart contract can verify the validity of the signature. The claim function of the smart contract can oversee the verification of the received asset’s metadata. If it is determined that the claim function of the smart contract is not valid at step 705, then the process ends at step 710 and nothing else happens for this attack. If it is determined that the claim function of the smart contract is valid (e.g., has valid metadata and digital storage address) at step 705, then the smart contract can trigger a fund transfer at step 715. The funds specified in the smart contract can be transferred from the smart contract to the malicious actor’s 605 digital storage device. The function can emit a claim success event. Functions on the smart contract can emit events when called. The most critical event can be the claim event that can trigger a security alert. The activity monitoring engine 255 can monitor the different types of events emitted. The process can then end at step 720.

[0086] Figure 8 A flowchart of a luring intrusion detection method is shown in accordance with some embodiments. In the luring intrusion detection method, a smart contract can be monitored at step 805. At step 810, it is determined what type of event occurred. If the event is a claim of a lure, an alert can be generated at step 815. If the event is another type of event (e.g., changing a contract owner, increasing or decreasing a contract balance, etc.), another action can be taken at step 820. For example, other events can be logged, written to a database record, used to determine future lures, assets, target environments, etc., and / or fed to an artificial intelligence or machine learning model.

[0087] Figure 9 A flowchart of a luring intrusion detection method is shown in accordance with some embodiments. In the luring intrusion detection method, a smart contract can be monitored at step 805. At step 810, it is determined what type of event occurred. If the event is a claim of a lure, an alert can be generated at step 815. If the event is another type of event (e.g., changing a contract owner, increasing or decreasing a contract balance, etc.), another action can be taken at step 820. For example, other events can be logged, written to a database record, used to determine future lures, assets, target environments, etc., and / or fed to an artificial intelligence or machine learning model.

[0088] At step 910, assets can be identified to entice a malicious actor to access the repository using one or more devices. In other words, the assets can be selected, provided, generated, or retrieved. In some embodiments, the assets can be identified based on a particular type of malicious actor that uses one or more devices to access the repository. The particular type of malicious actor can be targeted using the assets based on a level of knowledge, experience, or sophistication, a location of the malicious actor, a history of the malicious actor, or any other identifying characteristic of the malicious actor. In some embodiments, the assets can change over time.

[0089] At step 915, a smart contract can be generated for the assets. The smart contract can be associated with the assets based on metadata in the assets. The assets can include metadata and can be deployed to the repository. The assets can be used in conjunction with a lure to cause one or more malicious actors to execute the smart contract. In some embodiments, the metadata can include a nonce, an identifier, an address, and a token amount. In some embodiments, the metadata can be hashed and signed with a private key. At step 920, the smart contract can be deployed on a distributed ledger system (e.g., one or more of the distributed ledgers described above). As used herein, a distributed ledger can include a blockchain.

[0090] At step 925, at least a portion of the metadata can be obtained to initiate a smart contract to provide an incentive associated with the asset based on access to the repository. For example, an attacker can access the repository to gain access to the asset and, in exchange, provide at least some of the metadata (or other data) to the smart contract. In some embodiments, the at least a portion of the metadata can include a script that triggers the smart contract to provide the asset. In some embodiments, the at least a portion of the metadata can be received from a device of the one or more devices. In some embodiments, an event can be generated based on the smart contract being triggered. For example, an alert can be generated, a log entry can be made, data can be saved to a database, or a transfer of funds can occur. In some embodiments, triggering the smart contract includes writing a provision of the asset to a distributed ledger.

[0091] In some examples, the processes described herein (e.g., process 900 and / or other processes described herein) can be performed by a computing device or apparatus. In one example, process 900 can be performed by an intrusion detection system described herein. In another example, process 800 can be performed by a computing device of a computing system 1000 as shown in FIG. 10. The computing device can include any suitable device, such as a mobile device (e.g., a mobile phone), a desktop computing device, a tablet computing device, a wearable device, a server computer, a television, and / or any other computing device having the resource capabilities to perform the processes described herein, including process 900. In some cases, the computing device or apparatus can include various components configured to perform the steps of the processes described herein, such as one or more input devices, one or more output devices, one or more processors, one or more microprocessors, one or more microcomputers, one or more cameras, one or more sensors, and / or other components. In some examples, the computing device can include a display, a network interface configured to transmit and / or receive data, any combination thereof, and / or other components. The network interface can be configured to transmit and / or receive Internet Protocol (IP) based data or other types of data. Figure 10 In some examples, the processes described herein (e.g., process 900 and / or other processes described herein) can be performed by a computing device or apparatus. In one example, process 900 can be performed by an intrusion detection system described herein. In another example, process 800 can be performed by a computing device of a computing system 1000 as shown in FIG. 10. The computing device can include any suitable device, such as a mobile device (e.g., a mobile phone), a desktop computing device, a tablet computing device, a wearable device, a server computer, a television, and / or any other computing device having the resource capabilities to perform the processes described herein, including process 900. In some cases, the computing device or apparatus can include various components configured to perform the steps of the processes described herein, such as one or more input devices, one or more output devices, one or more processors, one or more microprocessors, one or more microcomputers, one or more cameras, one or more sensors, and / or other components. In some examples, the computing device can include a display, a network interface configured to transmit and / or receive data, any combination thereof, and / or other components. The network interface can be configured to transmit and / or receive Internet Protocol (IP) based data or other types of data.

[0092] The components of the computing device can be implemented in circuitry. For example, the components can include and / or can be implemented using electronic circuitry or other electronic hardware, which can include one or more programmable electronic circuits (e.g., microprocessors, graphics processing units (GPUs), digital signal processors (DSPs), central processing units (CPUs), and / or other suitable electronic circuits), and / or can include and / or use computer software, firmware, or any combination thereof, to perform various operations described herein.

[0093] The process 900 is shown as a logic flow diagram, the operations of which represent a sequence of operations that can be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, the operations represent computer-executable instructions stored, for example, on one or more computer-readable storage media that, when executed by one or more processors, perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, and the like that perform particular functions or implement particular data types. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations can be combined in any order and / or in parallel to implement the processes.

[0094] Additionally, the process 900 and / or other processes described herein can be performed under the control of one or more computer systems configured with executable instructions and can be implemented as code (e.g., executable instructions, one or more computer programs, or one or more computer applications) executing collectively on one or more processing units, by hardware, or combinations thereof. As noted above, the code can be stored on a computer-readable or machine-readable storage medium, for example, in the form of a computer program comprising a plurality of instructions executable by one or more processors. The computer-readable or machine-readable storage medium can be non-transitory.

[0095] The incentive-based intrusion detection systems and techniques described herein can be used in various types of systems or platforms, such as bug bounty platforms, capture the flag (CTF) systems, and red team / blue team events (where tokens are used for scoring and are proof of access to a system), among others. In one illustrative example, the incentive-based intrusion detection systems and techniques can be used in a bug bounty platform (e.g., a white-labeled bug bounty platform). Bug bounty companies provide bug bounty platforms that act as an intermediary between customers (e.g., companies) who want to test applications, systems, and networks against ethical hackers.

[0096] To implement the incentive-based intrusion detection techniques, a bug bounty customer can download an incentive-based intrusion detection agent (e.g., a software application, such as the application 115 in some illustrative examples) and install the agent on an application, system, and / or network that the customer wants to test. The agent can register itself with an incentive-based intrusion detection system management platform. In one illustrative example, the system management platform can include or can communicate with the application 115. The incentive-based intrusion detection system management platform allows the customer to create bounties for one or more artifacts, as described herein. The agent can then drag and drop the one or more artifacts and place them in key locations within the customer’s application, system, and / or network.

[0097] Artifacts are identified on a private blockchain (e.g., a private Ethereum blockchain) with unique identifiers and have a predefined amount of reward tokens. When a customer creates an artifact and the customer purchases a desired amount from the bug bounty platform, the customer can define that amount. In some cases, the reward tokens have no value outside of the bug bounty platform.

[0098] When a white hat hacker (e.g., selected by the bug bounty company and provided with special access to the customer's environment) discovers and claims an artifact using the provided script, the tokens are transferred to the hacker's account on the bug bounty platform. As described herein, the location of the artifact can be placed in a sensitive area of an application, system, and / or network. Thus, gaining access to the artifact provides proof of the existence of an exploited security vulnerability. In some cases, the tokens can be used to rank the hackers and allow the hackers to exchange the tokens for real monetary rewards.

[0099] As described in greater detail herein, an artifact can have multiple stages. For example, a second stage of each artifact can contain another larger amount of tokens. The hacker can claim the second stage when submitting additional information (e.g., a report detailing the method used to gain access to the location of the artifact). For example, the report can be reviewed and verified by the bug bounty company and / or the customer. Upon approval, the tokens can be released and automatically transferred to the white hat hacker. Advantages of the incentivized intrusion detection technology of the bug bounty company include, for example, providing an easy way to manage scoring, manage payouts to hackers by the customer, less conflict between the company and the hackers because claims from the latter cannot be refuted, etc. Examples of advantages of the incentivized intrusion detection technology for the white hat hackers include that, when discovering an artifact, the white hat hacker is sure that they will get a payout from the company (or receive some other incentive). For the customer, examples of advantages of the incentivized intrusion detection technology are that they can be sure that the hacker's claim is correct.

[0100] Figure 10The architecture of a computing system 1000 is shown, in which the components of system 1000 are in electrical communication with each other using a connection 1005, such as a bus. Exemplary system 1000 includes a processing unit (CPU or processor) 1010 and a system connection 1005 that couples various system components including the system memory 1015, such as the read-only memory (ROM) 1020 and random access memory (RAM) 1025, to the processor 1010. The system 1000 can include a cache of high-speed memory in close proximity to, directly connected to, or integrated as part of the processor 1010. The system 1000 can copy data from the memory 1015 and / or the storage device 1030 to the cache 1012 for quick access by the processor 1010. In this manner, the cache can provide a performance boost that avoids processor 1010 delays while waiting for data. These and other modules can control or be configured to control the processor 1010 to perform various actions. Other system memory 1015 can also be used. The memory 1015 can include multiple different types of memory with different performance characteristics. The processor 1010 can include any general purpose processor and a hardware or software service, such as service 1 1032, service 2 1034, and service 3 1036 stored in storage device 1030 and configured to control processor 1010, as well as specialized processors where software instructions are incorporated into the actual processor design. The processor 1010 can be a completely self-contained computing system, containing multiple cores or processors, a bus, memory controller, cache, etc. A multi-core processor can be symmetric or asymmetric.

[0101] To enable client interaction with the computing system 1000, an input device 1045 can represent any number of input mechanisms, such as a microphone for speech, a touch-sensitive screen for gesture or graphical input, keyboard, mouse, motion input, speech and the like. An output device 1035 can also be one or more of a number of output mechanisms known to those of skill in the art. In some examples, a multi-modal system can enable a client to provide multiple types of input to communicate with the computing system 1000. The communication interface 1040 can generally govern and manage the client input and system output. There is no restriction on operating on any particular hardware arrangement and therefore the basic features here can easily be substituted for improved hardware or firmware arrangements as they are developed.

[0102] The storage device 1030 is a non-volatile memory and can be a hard disk or other types of computer readable media which can store data that are accessible via a computer, such as a tape, flash, solid state memory device, digital versatile disks, cartridges, random access memories (RAMs) 1025, read only memory (ROM) 1020, and hybrids thereof.

[0103] The storage device 1030 can include services 1032, 1034, 1036 that are used to control the processor 1010. Other hardware or software modules are also contemplated. The storage device 1030 can be connected to the system connection 1005. In one aspect, a hardware module that performs a particular function can include the software component stored in a computer-readable medium that, in operation, facilitates the function along with other possible components used to facilitate the function. For example, a hardware module can include software component stored in a computer-readable medium that, when executed, facilitates an imaging function as well as other possible components such as processor 1010, connection 1005, output device 1035, etc.

[0104] As used herein, the term "computer-readable medium" includes, but is not limited to, portable or fixed storage devices, optical storage devices, and various other mediums capable of storing, containing or carrying instruction and / or data. A computer-readable medium can include a non-transitory medium in which data can be stored and that does not include carrier waves and / or transitory electronic signals propagating wirelessly or over wires, cables, or other communication mediums. Examples of a non-transitory medium can include, but are not limited to, a magnetic, optical, or other disc storage, a flash memory, a memoiy or memories, or a cad memory or memories. A computer-readable medium can be any available medium or

[0105] In some embodiments, the computer-readable storage devices, media and memories can include cables or wireless signals containing bitstreams, etc. However, in the mentioned cases, non-transitory computer-readable storage media expressly excludes media such as energy, carrier signals, electromagnetic waves, and signals per se.

[0106] In the above description, specific details are provided to provide a thorough understanding of the embodiments and examples provided herein. However, a person of ordinary skill in the art will understand that the embodiments can be practiced without these specific details. For the purpose of explanation, in some instances, the technology can be presented as including a specific functional block that comprises a functional block that includes a device, a component of a device, a step or routine in a method implemented in software or hardware, or combinations of hardware and software. Additional components can be used in addition to or instead of the components illustrated in the figures and described herein. For example, circuitry, systems, networks, processes, and other components can be illustrated as components in block diagram form to avoid obscuring the embodiments. In other instances, well-known circuitry, processes, algorithms, structures, and techniques can be shown without unnecessary detail in order to avoid obscuring the embodiments.

[0107] The above-described embodiments can be described as a process or method of a process or method depicted as a flowchart, flow diagram, data flow diagram, structure diagram, or a block diagram. Although a flowchart can describe operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations can be re-arranged. A process is terminated when its operations are completed, but could have further steps not included in a figure. A process can correspond in part to a method, function, routine, sub-routine, or

[0108] Processes and methods according to the above-described embodiments can be implemented using computer-executable instructions, which can be stored or otherwise available from computer-readable media. Such instructions can include, for example, instructions and data which cause or otherwise configure a general purpose computer, special purpose computer, or a processing device to perform a particular function or group of functions. Portions of computer resources used can be accessible over a network. The computer executable instructions can be, for example, binaries, intermediate format instructions such as assembly language, firmware, source code, etc. Examples of computer-readable media that can be used to store instructions, information used, and / or information created during methods according to described examples include magnetic or optical disks, flash memory, USB devices provided with non-volatile memory, network storage devices, etc.

[0109] Devices implementing processes and methods according to these disclosures can include hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof, and can take any of a variety of form factors. When implemented in software, firmware, middleware, or microcode, the program code or code segments to perform the necessary tasks can be stored in a computer-readable or machine-readable medium. A processor(s) can perform the necessary tasks. Typical examples of form factors include laptops, smartphones, mobile phones, tablet devices or other small form factor personal computers, personal digital assistants, rackmount devices, standalone devices, etc. Functionality described herein also can be embodied in peripherals or add-in cards. Such software can be downloaded from the Internet or received on a computer-readable medium, such as a floppy disk, a CD-ROM, a flash memory card, a USB key, a ROM, a RAM, or any other computer-readable medium, via one or more communication interfaces (for example, a network adapter). Functionalities described herein also can be implemented in incoming communication connecting a stationary or portable device with the server and the database.

[0110] Instructions, media for conveying such instructions, computing resources for executing them, and other structures used to support such computing resources are example means for providing the functionality described in this disclosure.

[0111] In the foregoing description, aspects of the application are described with reference to particular embodiments thereof, but those skilled in the art will understand that the application is not limited to these embodiments. Thus, while the example embodiments of the application have been described herein, the present disclosure is intended to include any and all modifications and variations of the example embodiments herein that are within the scope of the present disclosure. Accordingly, the appended claims are intended to encompass within their scope all such alternatives, modifications and variations of the example embodiments of the application. Various features and aspects of the above-described application can be used individually or jointly. Further, the application can be utilized in any number of environments and applications beyond the type described herein without departing from the broader spirit and scope of the present disclosure. Therefore, the specification and drawings are to be regarded as illustrative in nature and not as restrictive. For the purposes of illustration, methods were described in a particular order. It should be appreciated that in alternate embodiments, the methods can be performed in a different order or concurrently.

[0112] One of ordinary skill in the art will appreciate that the less than (“<”) and greater than (“>”) symbols or terminology used herein can be replaced with less than or equal to (“≤”) and greater than or equal to (“≥”) symbols without departing from the scope of the present description.

[0113] Where components are described as being “configured to” perform certain operations, such configuration can be accomplished, for example, by designing the electronic circuitry or other hardware of the components to perform the operation, by programming the components to perform the operation, or by any combination of such mechanisms.

[0114] The phrase “coupled to” means that any component is directly or indirectly connected to another component, and / or any component is in direct or indirect communication with another component (e.g., connected to another component through a wired or wireless connection, and / or other suitable communication interface).

[0115] Language reciting a “at least one of’ or “one or more of’ a set indicates that a member of the set or multiple members of the set satisfy the statement. For example, language reciting “at least one of A and B” means A, B, or A and B.

[0116] The various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein can be implemented as electronic hardware, computer software, firmware, or combinations thereof. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans can implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

[0117] The techniques described herein can also be implemented in electronic hardware, computer software, firmware, or any combination thereof. Such techniques can be implemented in any of various devices such as a general purpose computer, a wireless communication device handsets, or an integrated circuit device having multiple uses including application in wireless communication device handsets and other devices. Any features described as modules or components can be implemented together in an integrated logic device or separately as discrete but interoperable logic devices. If implemented in software, the techniques can be realized at least in part by a computer-readable data storage medium comprising program code including instructions that, when executed, performs one or more of the methods described above. The computer-readable data storage medium can form part of a computer program product, which can include packaging material. The computer-readable medium can comprise memory or data storage media, such as random access memory (RAM), read only memory (ROM), non-volatile random access memory (NVRAM), electrically erasable programmable read only memory (EEPROM), FLASH memory, magnetic or optical data storage media, and the like. The techniques additionally, or alternatively, can be realized at least in part by a computer-readable communication medium that carries or communicates program code in the form of instructions or data structures and that can be accessed, read, and / or executed by a computer.

[0118] The program code can be executed by a processor, which can include one or more processors, such as one or more digital signal processors (DSPs), general purpose microprocessors, application-specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuitry. Such a processor can be configured to perform any of the techniques described in this disclosure. A general-purpose processor can be a microprocessor; however, in the alternative, the processor can be any conventional processor, controller, microcontroller, or state machine. A processor can also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Accordingly, as used herein the term "processor" can refer to any of the foregoing structure, any combination of the foregoing structure, or any other structure or apparatus suitable for implementation of the techniques described herein. In addition, in some aspects, the functionality described herein can be provided within dedicated software modules or hardware modules within the computing device.

[0119] Example 1 : A method for deploying one or more smart contracts. The method comprises: configuring a repository in a digital environment; identifying assets available for access to the repository by one or more devices; generating a smart contract associated with the assets deployed in the repository, the smart contract being associated with the assets based on metadata in the assets; deploying the smart contract on a distributed ledger system; and obtaining at least a portion of the metadata based on access to the repository to initiate the smart contract to provide an incentive associated with the assets.

[0120] Example 2: The method of example 1, further comprising providing data to the smart contract to verify the provision of the incentive.

[0121] Example 3: The method of any of examples 1 or 2, wherein the at least a portion of the metadata comprises a script to initiate the smart contract to provide the incentive.

[0122] Example 4: The method of any of examples 1 to 3, wherein the at least a portion of the metadata is received from a device of the one or more devices.

[0123] Example 5: The method of any of examples 1 to 4, further comprising generating an event based on the smart contract being initiated.

[0124] Example 6: The method of any of examples 1 to 5, wherein triggering the smart contract comprises writing the provision of the incentive to the distributed ledger system.

[0125] Example 7: The method of any of examples 1 to 6, wherein the metadata comprises a nonce, an identifier, an address, and a token amount.

[0126] Example 8: The method of any of examples 1-7, wherein the metadata is hashed and signed with a private key.

[0127] Example 9: The method of any of examples 1-8, wherein the asset changes over time.

[0128] Example 10: A computer program product tangibly embodied in a non-transitory machine-readable storage medium including instructions that, when executed by one or more processors, cause the one or more processors to perform operations comprising: configuring a repository in a digital environment; identifying an asset available upon access to the repository by one or more devices; generating a smart contract associated with the asset deployed in the repository, the smart contract associated with the asset based on metadata in the asset; deploying the smart contract on a distributed ledger system; and obtaining at least a portion of the metadata based on access to the repository to initiate the smart contract to provide an incentive associated with the asset.

[0129] Example 11 : The computer program product of example 10, further comprising providing data to the smart contract to validate the provision of the incentive.

[0130] Example 12: The computer program product of any of examples 10 or 11, wherein the at least a portion of the metadata comprises a script to initiate the smart contract to provide the incentive.

[0131] Example 13: The computer program product of any of examples 10-12, wherein the at least a portion of the metadata is received from a device of the one or more devices.

[0132] Example 14: The computer program product of any of examples 10-13, further comprising generating an event based on the smart contract being initiated.

[0133] Example 15: The computer program product of any of examples 10-14, wherein triggering the smart contract comprises writing the provision of the incentive to the distributed ledger system.

[0134] Example 16: The computer program product of any of examples 10-15, wherein the metadata comprises a nonce, an identifier, an address, and a token amount.

[0135] Example 17: The computer program product of any of examples 10-16, wherein the metadata is hashed and signed with a private key.

[0136] Example 18: The computer program product of any of examples 10-17, wherein the asset changes over time.

[0137] Example 19: A system comprising one or more processors and one or more non-transitory machine-readable storage media containing instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising: configuring a repository in a digital environment; identifying assets available upon access to the repository by one or more devices; generating a smart contract associated with the assets deployed in the repository, the smart contract associated with the assets based on metadata in the assets; deploying the smart contract on a distributed ledger system; and obtaining at least a portion of the metadata based on access to the repository to initiate the smart contract to provide an incentive associated with the assets.

[0138] Example 20: The system of example 19, further comprising providing data to the smart contract to verify the provision of the incentive.

[0139] Example 21 : The system of any of examples 19 or 20, wherein the at least a portion of the metadata comprises a script to initiate the smart contract to provide the incentive.

[0140] Example 22: The system of any of examples 19-21, wherein the at least a portion of the metadata is received from a device of the one or more devices.

[0141] Example 23: The system of any of examples 19-22, further comprising generating an event based on the smart contract being initiated.

[0142] Example 24: The system of any of examples 19-23, wherein triggering the smart contract comprises writing the provision of the incentive to the distributed ledger system.

[0143] Example 25: The system of any of examples 19-24, wherein the metadata comprises a nonce, an identifier, an address, and a token amount.

[0144] Example 26: The system of any of examples 19-25, wherein the metadata is hashed and signed with a private key.

[0145] Example 27: The system of any of examples 19-26, wherein the asset changes over time.

Claims

1. A method for detecting intrusion, comprising: configuring a repository in a digital environment; identifying assets stored on the repository, wherein the assets are accessible by one or more devices; generating a smart contract associated with the assets deployed in the repository, wherein the smart contract is based on metadata related to the assets stored on the repository; deploying the smart contract on a distributed ledger system; based on access to the assets in the repository by at least one device, retrieving at least a portion of the metadata to initiate the smart contract to provide an incentive associated with the assets; and detecting intrusion of the digital environment based on the initiation of the smart contract.

2. The method of claim 1, further comprising: providing data to the smart contract to verify the provision of the incentive.

3. The method of claim 1, wherein, the at least a portion of the metadata includes a script to initiate the smart contract to provide the incentive.

4. The method of claim 1, wherein, the at least a portion of the metadata is received from a device of the one or more devices.

5. The method of claim 1, further comprising: based on the initiation of the smart contract, generating an alert associated with the intrusion of the digital environment.

6. The method of claim 1, wherein, triggering the smart contract includes writing the provision of the incentive to the distributed ledger system.

7. The method of claim 1, wherein, the metadata includes a nonce, an identifier, an address, and a token amount.

8. The method of claim 1, wherein, the metadata is hashed and signed with a private key.

9. The method of claim 1, wherein, the assets change over time.

10. A non-transitory machine-readable storage medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform operations comprising: configuring a repository in a digital environment; identifying assets stored on the repository, wherein the assets are accessible by one or more devices; generating a smart contract associated with the assets deployed in the repository, wherein the smart contract is based on metadata related to the assets stored on the repository; deploying the smart contract on a distributed ledger system; based on access to the assets in the repository by at least one device, retrieving at least a portion of the metadata to initiate the smart contract to provide an incentive associated with the assets; and detecting intrusion of the digital environment based on the initiation of the smart contract.

11. The non-transitory machine-readable storage medium of claim 10, wherein, the operations further comprising: providing data to the smart contract to verify the provision of the incentive.

12. The non-transitory machine-readable storage medium of claim 10, wherein, the at least a portion of the metadata includes a script to initiate the smart contract to provide the incentive.

13. The non-transitory machine-readable storage medium of claim 10, further comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising: based on the initiation of the smart contract, generating an alert associated with the intrusion of the digital environment.

14. The non-transitory machine-readable storage medium of claim 10, wherein, triggering the smart contract includes writing the provision of the incentive to the distributed ledger system.

15. The non-transitory machine-readable storage medium of claim 10, wherein, the assets change over time.

16. A system for detecting intrusion, comprising: one or more processors; and One or more non-transitory machine-readable storage media containing instructions that, when executed on the one or more processors, cause the one or more processors to perform operations comprising: configuring a repository in a digital environment; identifying an asset stored on the repository, wherein the asset is accessible by one or more devices; generating a smart contract associated with the asset deployed in the repository, wherein the smart contract is based on metadata related to the asset stored on the repository; deploying the smart contract on a distributed ledger system; based on access to the asset in the repository by at least one device, retrieving at least a portion of the metadata to initiate the smart contract to provide an incentive associated with the asset; and detecting an intrusion into the digital environment based on the initiation of the smart contract.

17. The system of claim 16, wherein, The operations further comprise: providing data to the smart contract to verify the provision of the incentive.

18. The system of claim 16, wherein, The at least a portion of the metadata comprises a script to initiate the smart contract to provide the incentive.

19. The system of claim 16, wherein, The one or more non-transitory machine-readable storage media further contain instructions that, when executed on the one or more processors, cause the one or more processors to perform operations comprising: based on the initiation of the smart contract, generating an alert associated with the intrusion into the digital environment.

20. The system of claim 16, wherein, Triggering the smart contract comprises writing the provision of the incentive to the distributed ledger system.

Images