Abstract: Embodiments provide for detecting viruses and other malware in executing process threads based on thread patterns. According to one embodiment, detecting previously unknown malware associated with process threads can comprise capturing context information for each thread of a plurality of threads executing on a processor. The context information can define a thread pattern for the thread. The thread pattern for each thread can be compared to stored information defining one or more known patterns for thread execution based on previous execution of one or more threads. A thread pattern variation can be detected when the thread pattern for one or more threads does not match the stored information defining the known thread patterns. A determination can be made as to whether the detected thread pattern variation indicates presence of malware and actions can be performed based on determining the detected thread pattern variation indicates the presence of malware.

Abstract: A first hash of a record is retrieved. The first hash is tokenized by storing the first hash in a tokenization table that has a corresponding hash token. A request is received to validate the record. The request to validate the record comprises a second hash of the record and a second hash token. In response to receiving the request to validate the record, the record is validated by looking up the first hash in the tokenization table using the second hash token and comparing the looked up first hash to the second hash. In response to the looked up first hash being the same as the second hash, the record is validated. In response to the looked up first hash not being the same as the second hash, the record is not validated.

Abstract: A first hash of a record is retrieved. The first hash is encrypted using an encryption key to produce an encrypted hash. The encrypted hash is stored in the record by replacing the first hash with the encrypted hash or by adding the encrypted hash to the record. A request is received to validate the record. In response to receiving the request to validate the record, the record is validated by: unencrypting the encrypted hash using the encryption key to produce a second hash; hashing the record to produce a third hash; and comparing the second hash to the third hash. In response to the second hash being the same as the third hash, the record is validated. In response to the second hash not being the same as the third hash, the record is not validated.

Abstract: One or more unused locations in a software image are identified. An example of a software image may be a container image or virtual machine image. An unused location may be a location where padding is used in the software image. A first watermark is placed in the one or more unused locations to produce a watermarked software image. A request is received to load the watermarked software image. In response to receiving the request to load the watermarked software image, a second watermark is generated using the one or more unused locations in the watermarked software image and the second watermark is then compared to the first watermark. In response to the first watermark matching the second watermark, the software image is loaded. In response to the first watermark not matching the second watermark, the software image is not loaded.

Abstract: An anomaly on a computer network is identified by processing data generated by the computer network. The anomaly is identified based on a first anomaly threshold of a plurality of anomaly thresholds associated with the anomaly. In response to determining that the anomaly has met the first anomaly threshold of the plurality of anomaly thresholds associated with the anomaly, a first authentication level associated with the first anomaly threshold is identified. The plurality of anomaly thresholds associated with the anomaly have a plurality of associated authentication levels. A user interface is displayed to an administrator that includes a prompt to authenticate the administrator at the first authentication level. Authenticating the administrator at the first authentication level allows the administrator to take an action associated with the anomaly. For example, the administrator may unload an application that may likely have been compromised.

Abstract: A request to retroactively add one or more of an encryption level, an encryption type, a security level, and an authentication level to an existing blockchain is received. An authentication/encryption block is added to the existing blockchain. The authentication/encryption block comprises the one or more of the encryption level, the encryption type, the security level, and the authentication level. Based on the added authentication/encryption block in the existing blockchain, the one or more of the encryption level, the encryption type, the security level, and the authentication level are retroactively applied to at least a portion of blockchain data in the existing blockchain. In one embodiment, a data structure is used in place of the authentication/encryption block.

Abstract: A first load cycle of an application is determined to have been completed. A load cycle is where the application has been loaded, executed, and then unloaded. One or more of first load parameter associated with the first load cycle of the application, a first execution parameter associated with the first load cycle of the application, and a first unload parameter associated with the first load cycle of the application are retrieved and compared to one or more of a second load parameter associated with a second load cycle of the application, a second execution parameter associated with the second load cycle of the application, and a second unload parameter associated with the second load cycle of the application. The comparison can then be used to identify anomalies between load cycles of the application.

Abstract: An event is identified. For example, the event is that the an original blockchain has reached a threshold number of blocks. In response to identifying the event: the original blockchain is completed and a second blockchain is created. The second blockchain comprises a first consolidation genesis block. The first consolidation genesis block comprises a complete hash of the original blockchain and a first consolidation pointer that points to the original blockchain. This allows the blockchain to be divided into smaller pieces that can be verified using less processing resources. In addition, this allows for more efficient searching of blockchains.

Abstract: A first sub-blockchain and a second sub-blockchain are retrieved. The sub-blockchains are predefined fragments of a blockchain that are intended to be used to build a larger blockchain. At least one of the first sub-blockchain and the second sub-blockchain was originally stored in a read-only computer memory or was originally stored in a barcode/RFID tag. A blockchain that comprises the first sub-blockchain and the second sub-blockchain is created. The blockchain is used to track inventory of a product.

Abstract: A primary blockchain for a software application is created that comprises a first block associated with a software component of the software application. An event is received that is associated with the software component. In response to receiving the event, a component blockchain is created that is associated with the software component. The component blockchain comprises a second block associated with the event. The component blockchain links to the primary blockchain. This provides a structure for managing supply chains of software components. As new software components are received, the new software components can be managed and tracked for quality/security.

Abstract: Embodiments provide for detecting viruses and other malware in executing process threads based on thread patterns. According to one embodiment, detecting previously unknown malware associated with process threads can comprise capturing context information for each thread of a plurality of threads executing on a processor. The context information can define a thread pattern for the thread. The thread pattern for each thread can be compared to stored information defining one or more known patterns for thread execution based on previous execution of one or more threads. A thread pattern variation can be detected when the thread pattern for one or more threads does not match the stored information defining the known thread patterns. A determination can be made as to whether the detected thread pattern variation indicates presence of malware and actions can be performed based on determining the detected thread pattern variation indicates the presence of malware.

Abstract: A copy of a blockchain is stored. The stored copy of the blockchain is copied from a blockchain in a distributed blockchain ledger. An event associated with the blockchain in the distributed ledger is identified. In response identifying the event associated with the blockchain in the distributed ledger, a compromise of the blockchain in the distributed ledger is identified, such as, identifying one or more blocks of the blockchain that have been compromised. In a second embodiment, a request to add a new block to a blockchain is identified. In response identifying the request to add the new block to the blockchain, a consensus vote to add the new block to the blockchain is monitored. A determination is made to determine if the consensus vote is below a threshold. In response to the consensus vote being below the threshold, an audit of the blockchain is completed.

Abstract: A plurality of events associated with a communication device are received. The plurality of events relate to a plurality of changes of hardware, firmware, and/or software in the communication device. The plurality of events are stored as a plurality of blocks in a blockchain. One or more anomalies associated with the plurality of changes of the hardware, the firmware, and/or the software are identified. In response to identifying the one or more anomalies associated with the plurality of changes of the hardware, the firmware, and/or the software in the communication device, a software image of the communication device is received and added to the blockchain. A second embodiment discloses using this process for a hypervisor using virtual machines or containers.

Abstract: A copy of a blockchain is stored. The stored copy of the blockchain is copied from a blockchain in a distributed blockchain ledger. An event associated with the blockchain in the distributed ledger is identified. In response identifying the event associated with the blockchain in the distributed ledger, a compromise of the blockchain in the distributed ledger is identified, such as, identifying one or more blocks of the blockchain that have been compromised. In a second embodiment, a request to add a new block to a blockchain is identified. In response identifying the request to add the new block to the blockchain, a consensus vote to add the new block to the blockchain is monitored. A determination is made to determine if the consensus vote is below a threshold. In response to the consensus vote being below the threshold, an audit of the blockchain is completed.

Abstract: A request to load an application into memory for execution is received. The application is stored in one or more blocks in a blockchain. The application is validated by running a blockchain hash. In response to validating the application by running the blockchain hash, the application is loaded from the blockchain into a memory. The application is then executed in the memory. This provides a secure method of loading an application into memory.

Abstract: A communication stream is received. For example, the communication stream may be a part of a communication session, such as, a voicemail, a videomail, a voice conference call, a video conference call, and/or the like. A determination is made if the communication stream is completely generated using a session watermark. The session watermark is associated with the communication session. In response to determining that the communication stream is completely generated using the session watermark, the communication stream is identified as a legitimate communication stream. In response to determining that the communication stream has not been completely generated using the session watermark, the communication stream is identified as potentially a vishing communication steam.

Abstract: A request to grant control of a virtual resource is received. For example, a user may provide a set of authentication credentials that allow the user to execute a virtual machine. The request to grant control of the virtual resource uses an authentication level of a plurality of authentication levels associated with the virtual resource. The request to grant control of the virtual resource is validated. In response to validating the request to grant control of the virtual resource, control of the virtual resource is granted according to the authentication level of the plurality of authentication levels associated with the virtual resource. The user can then control/access the virtual resource based on privileges associated with the authentication level.

Abstract: A plurality of circular blockchains are created. The plurality of circular blockchains may comprise different structures. For example, the plurality of circular blockchains may include: a single genesis block where a last block in each of the plurality of circular blockchain links back to the single genesis block, a plurality of genesis blocks where a last block in each of the plurality of circular blockchain links back to individual ones of the plurality of genesis blocks, and a genesis block and one or more connection blocks that form the plurality of circular blockchains.

Abstract: A current a version of an external component (e.g., an open-source component or a third-party component) that is used in a software application is identified. A new version of the current version of the external component is identified (supply chain components). For example, the new version may have been just released by an open-source community. In response to identifying the new version of the current version of the of the external component, a series of actions are implemented that include: identifying changes to Application Programming Interfaces (APIs) in the new version of the current version of the external component; identifying new vulnerabilities in the new version of the current version of the external component; and determining a quality history associated with the new version of the current version of the external component. Based on the actions, a composite score is generated and displayed to a developer.

Abstract: A request to authenticate to a Blockchain as a Service (BaaS) is received from a tenant (e.g., a user that is acting on behalf of a corporation). An authentication credential of the tenant associated with the request to authenticate to the BaaS is determined to be valid. In response to determining that the authentication credential of the tenant associated with the request to authenticate to the BaaS is valid, a level of access is granted to the BaaS. A request is received, from the tenant, to add a transaction block to a blockchain in the BaaS. The blockchain in the BaaS is interspersed with transaction blocks from a plurality of tenants of the BaaS. The transaction block is then added to the blockchain in the BaaS. This addition to the BaaS represents both an Escrow and an Audit capability.