What if you could eliminate all doubt of log corruption and hacking?
A blockchain is a decentralized, time-stamped series of immutable data records which are managed by the algorithmic relationships between blocks of data (
blocks). Each of these blocks are secured and bound to each other using cryptographic principles (
Most, if not all compliance and best practices stipulate that securing data and logs are mandatory. Some of these may be familiar but there are many others:
Traditional logging tools can be hacked, tampered with, or corrupted. For example DNC Server hackers in 2016 covered their tracks by modifying logs
Current Logging Tools are centralized in a series of identically documented servers/DBs. Logs are often encrypted, but lack provenance and immutability. Therefore, finding and/or modifying the same record in a centralized system is relatively easy.
Decentralizing data logs on a blockchain eliminates the possibility of a single source being hacked or becoming corrupt. No central source of “truth” means no central point of failure. Once a record is documented on the chain, the centralized failure point is eliminated, and the security of the entire system is increased.
Corruption or hacking attempts to individual records on the chain would appear as outliers to the chain (not matching the majority of the chain) and therefore would be discarded as erroneous.
With Blockchain-stored logs, it is virtually impossible to delete or manipulate the logs because they are immutable and have provenance. As each new block is added, we are creating not just a unique record, but a unique record with a unique history, whereby any attempt to falsify a single record would mean having to falsify the entire chain in the majority of blockchain node instances - not just one entry.
Provenance: Provenance is the chronology of the ownership, custody or location of a historical object.
Immutability: An immutable object is an object whose state cannot be modified after it is created.
Any change in a record is documented on the chain, and only after enough (majority) nodes in the chain agree with the change, will that change become “truth”. If the change cannot be verified across the chain(s), then it will become an outlier and not recognized as the truth.
Each block in the chain is informed by the block before it, resulting in a dependent algorithmic relationship & thus attempting to change a block “mid-stream” would result in an incorrect HASH calculation and splitting the chain into a new series of HASHES (more outliers).
In simple terms, hashing means taking an input string of any length and giving out an output of a fixed length. For example: bitcoin uses SHA-256 which gives an output of a fixed length of 256 bits.
Even a tiny change to a log would result in a new HASH which would be mathematically incompatible with the existing chain, thus creating outlier records.
Incoming events are hashed using LogZilla’s preduplication algorithm, then stored on a blockchain. (A REST API is also available, used primarily for queries to the blockchain).
By using the already-integrated algorithm from our preduplication, the blockchain doesn’t have to be integrated directly, rather, it lives in parallel to it. This ensures that the unparalleled speed and efficiency you have come to expect from us remains the same, now augmented by the security and provenance of a blockchain.
Configuration ability of the blockchain component is wide and diverse. Here are a few examples:
Logzilla server on prem, and fully private blockchain on prem
Logzilla server on prem, fully private blockchain both on prem and in the cloud
Logzilla server on prem, private blockchain on prem, and a periodic post to a public blockchain, such as the Ethereum mainnet
Logzilla server on prem, fully private blockchain in the cloud (single cloud provider or multiple cloud providers)
Logzilla server in the cloud, private blockchain in the cloud (single cloud provider or multiple cloud providers)
All of the above options are interchangeable.
Interested? Let us know!