Blockchain powered

iMedDoc uses blockchain technology to store the tamper-proof logs and high integrity files. iMedDoc is the first of its kind to enable the technology on the Medical software field.


Access Management – Tamper-Proof System Logs

By making it possible to generate immutable audit trails, blockchain could prove valuable in privileged access management. Still sceptical about blockchain? Given the combination of hyperbole and vagueness that defines much of what is written and said about this emerging technology, a healthy dose of scepticism is warranted. But don’t let that blind you to the truly game-changing potential of the blockchain. Because as it continues to emerge from the often-confusing world of cryptocurrency, many potential enterprise use cases are coming into focus.

One particularly vivid example is provided by blockchain’s ability to create tamper-proof system logs for use in managing access to iMedDoc and its components


Blockchain Beyond Bitcoin

You’ve probably heard blockchain evangelists insisting that it is a technology with potential applications way beyond its origin as an enabler of cryptocurrencies. But based on your real-world experience, you may still feel that blockchain is inextricably linked to Bitcoin. Evidently, the blockchain evangelism you have been exposed to hasn’t provided any particularly credible alternative use cases.

Let’s redress that by looking at one highly specific, but also very powerful use case: leveraging blockchain to create tamper-proof system logs for privileged access management (PAM).


Safeguarding System Logs

A system log helps protect the enterprise against cybersecurity breaches because it provides an audit trail of who has accessed a network, application or database, as well as what those individuals have done while they had access. This allows enterprises to detect hackers gaining access to sensitive systems, and also makes it possible to investigate unauthorised or damaging behaviour from the users.

The blockchain becomes a decentralised, cryptographically-sealed system log. Once data has been logged, there are multiple, distributed copies of it. As all of these “validation nodes” must agree on what the correct data is, there is no single place where the audit trail can be edited. Furthermore, each block in the blockchain has a hash, which proves the veracity of all the transactions, and any attempts to tamper with the log would need to break this cryptography.


Blockchain Security in Practice

All this may sound wonderfully simple but blockchain is a complex technology, with many technical decisions to be made, impacting how effective the actual implementation proves to be. While blockchain is an inherently secure technology, it could theoretically be hacked by a malicious organisation (a nation-state, for example) with access to massive computing power or the resources required to hijack the majority of validation nodes in a network.

While these scenarios are highly unlikely right now, it would certainly be wise to future-proof the blockchain by creating the most secure network possible. When creating a blockchain for something as sensitive as an enterprise system log, it might seem logical to use a private network. But the larger, more distributed and diverse your network is, the harder it will be to achieve the levels of computing power and access required to tamper with the audit trail.

A private network should only be used if it is widely distributed. If all the validation nodes reside in one location, the bar is significantly lowered for attackers hoping to rewrite history. The greatest possible diversity—and therefore the most absolute guarantee of immutability—can be achieved by using a public network. But if this conflicts with enterprise security policies, creating a consortium network with trusted partners might be a good compromise.

Another option would be to use a public network and encrypt the data. While each block is cryptographically sealed, the transactions themselves are written in clear text. So, security can be hardened by creating the entire log in an encrypted format. This is preferable to simply writing a hash of the clear text log, which would not make it possible to recover the original log in the event of an attack.