immutability-vs-ransomware-2

Immutability vs Ransomware and file encryption

The only effective answer to ransomware is to have a clean backup. Some people say the only true weapon against ransomware is to have offline backups. Unfortunately, these are slow and not anywhere close to realtime. In our last blog, we described how immudb can offer protection against ransomware but there were still some questions unanswered. What if the attackers get root access to the immudb server? What if they encrypt the immudb files? The short answer is that you are in trouble if the bad actors gain root access for every system you are using but there are ways to make that scenario almost impossible.

Access levels and their impact

First of all immudb has to be run in a protected environment in order to add security against
ransomware. A protected environment means, that the access levels have to be different. Immudb should just be accessible at application level. For example, the attackers gain root access to many servers and encrypt every file they can get their hands on. If immudb was on one of those servers, it’s directory would be encrypted too and therefore be inaccessible. The backups have to be done on application level using immudb credentials. Even if the attackers get the credentials for immudb, they cannot encrypt immudb’s data, because records can’t be overwritten or changed. Instead, immudb is storing changing records in a history table. Clean versions of the record can later be retrieved through that table. The root access to the remote immudb server should be highly protected. Another possibility is to sync your backup with a remote storage solution, for example, Google Cloud Storage or Amazon S3.

Remote Backups with immudb and restic

Now we have learned the recipe for successfully using immudb as a backup tool. The key is to send the backups to a destination that is isolated from the production environment. Cloud storage is an obvious example. Different authentication systems will make it harder (if not impossible) for attackers to gain access. Of course, there are still some basic rules to follow like don’t safe credentials for these systems electronically in one place and never stop hardening your network security.

Immudb is high speed and can be deployed close to your application data, that’s why it makes sense to have it running in your production environment. This puts the immudb files at risk of being hit by an attack too. To avoid that, it is feasible to back up the immudb files to a remote location for example by using restic.

Back up the data in a remote restic repository. Supports SFTP, REST, Amazon S3, Google Cloud Storage and many more remote storage solutions.

restic -r <remote-restic-repository> --verbose backup /home/sebastian/immudb
open repository
enter password for repository: xxxxxxx
repository 0fc337c2 opened successfully, password is correct
created new cache in /root/.cache/restic
lock repository
load index files
start scan on [/home/sebastian/immudb]
start backup on [/home/sebastian/immudb]
scan finished in 0.291s: 533 files, 106.502 MiB

Files:         533 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Data Blobs:    609 new
Tree Blobs:      3 new
Added to the repo: 106.503 MiB

processed 533 files, 106.502 MiB in 0:00
snapshot ad1c1dd6 saved

How can you be sure that restic is not backing up by ransomware encrypted files and overwriting the clean ones? Here is the deal: immudb can proof and recalculate the files and check their consistency. Immudb carries along a Merkle tree, which is statically connected to the data, so the construct cannot be changed without knowing. That’s why if the backup is encrypted it won’t work with immudb. It can be proved by restoring the backup and starting up immudb. It is that simple.

$ restic -r <remote-restic-repository>  restore 0fc337c2 --target <target-directory> 
enter password for repository:
restoring <Snapshot of [/home/sebastian/immudb] at 2021-01-26 21:40:19.884408621 +0200 CEST> to <target-directory>

Use the CodeNotary Trusted Timestamping Service and experience immudb in action in less than a minute

Building services on immudb is fun but takes some time, that’s why we set up the free CodeNotary Trusted Timestamping Service for you to experience the power of immudb. Timestamping can be used to prove that a document/file hasn’t been altered since the timestamp was issued.

Get your API Key by signing up here CodeNotary CodeNotary Timestamp
This API Key is bound to your email address and it’s required during vcn login. This timestamping service provides full immutability for all data ever written and unique data checksum ever stored including its history.

Quick start

  1. Installer In case you use Linux or macOS, the quickest start is our install script:
    bash <(curl https://getvcn.codenotary.com -L)

You can also download the latest release

  1. Login to timestamp.codenotary.com

    vcn login --lc-host timestamp.codenotary.com # type in your API key when requested
    # or setting the API key
    VCN_LC_API_KEY=<Your-API-Key vcn login --lc-host timestamp.codenotary.com
  2. Notarize existing digital objects Once you have an account you can start notarizing digital assets to give them an identity.

    vcn n <file|dir://directory|docker://dockerimage|git://gitdirectory>
  3. Authenticate digital objects You can use the command as a starting point.
vcn a <file|dir://directory|docker://dockerimage|git://gitdirectory>

For detailed command line usage, just run vcn help.

Learn more about CodeNotary’s Trusted Timestamping Service in our timestamping blog.

Summary and outlook

Being attacked by ransomware groups is now less scary. Sometimes people start to overestimate the power those groups have. They won’t be able to hack all cloud storage providers at the same time. Immudb has key advantages, as you can store data cryptographically coherent and verifiable and you will always know if your backups have been compromised.

On top of that, the backups are not offline, therefore fast and minimizing the downtime of the affected services. Security can be leveraged by relocating the backup files to a remote location with a different access level. Using immudb as a backup database solution is a highly securable setup.
We at CodeNotary are currently working on improving immudb’s abilities for that use case by adding streaming and data splitting features.

This will enable immudb to backup files of any size. Stay tuned by leaving us a Star on Github.

immudb

BUILT ON THE FASTEST
IMMUTABLE LEDGER
TECHNOLOGY

Open Source and easy to use in new applications and easy to integrate into existing application.

MOST POPULAR

Subscribe to Our Newsletter

Get the latest product updates, company news, and special offers delivered right to your inbox.

Subscribe to our newsletter

Use Case - Tamper-resistant Clinical Trials

Goal:

Blockchain PoCs were unsuccessful due to complexity and lack of developers.

Still the goal of data immutability as well as client verification is a crucial. Furthermore, the system needs to be easy to use and operate (allowing backup, maintenance windows aso.).

Implementation:

immudb is running in different datacenters across the globe. All clinical trial information is stored in immudb either as transactions or the pdf documents as a whole.

Having that single source of truth with versioned, timestamped, and cryptographically verifiable records, enables a whole new way of transparency and trust.

Use Case - Finance

Goal:

Store the source data, the decision and the rule base for financial support from governments timestamped, verifiable.

A very important functionality is the ability to compare the historic decision (based on the past rulebase) with the rulebase at a different date. Fully cryptographic verifiable Time Travel queries are required to be able to achieve that comparison.

Implementation:

While the source data, rulebase and the documented decision are stored in verifiable Blobs in immudb, the transaction is stored using the relational layer of immudb.

That allows the use of immudb’s time travel capabilities to retrieve verified historic data and recalculate with the most recent rulebase.

Use Case - eCommerce and NFT marketplace

Goal:

No matter if it’s an eCommerce platform or NFT marketplace, the goals are similar:

  • High amount of transactions (potentially millions a second)
  • Ability to read and write multiple records within one transaction
  • prevent overwrite or updates on transactions
  • comply with regulations (PCI, GDPR, …)


Implementation:

immudb is typically scaled out using Hyperscaler (i. e. AWS, Google Cloud, Microsoft Azure) distributed across the Globe. Auditors are also distributed to track the verification proof over time. Additionally, the shop or marketplace applications store immudb cryptographic state information. That high level of integrity and tamper-evidence while maintaining a very high transaction speed is key for companies to chose immudb.

Use Case - IoT Sensor Data

Goal:

IoT sensor data received by devices collecting environment data needs to be stored locally in a cryptographically verifiable manner until the data is transferred to a central datacenter. The data integrity needs to be verifiable at any given point in time and while in transit.

Implementation:

immudb runs embedded on the IoT device itself and is consistently audited by external probes. The data transfer to audit is minimal and works even with minimum bandwidth and unreliable connections.

Whenever the IoT devices are connected to a high bandwidth, the data transfer happens to a data center (large immudb deployment) and the source and destination date integrity is fully verified.

Use Case - DevOps Evidence

Goal:

CI/CD and application build logs need to be stored auditable and tamper-evident.
A very high Performance is required as the system should not slow down any build process.
Scalability is key as billions of artifacts are expected within the next years.
Next to a possibility of integrity validation, data needs to be retrievable by pipeline job id or digital asset checksum.

Implementation:

As part of the CI/CD audit functionality, data is stored within immudb using the Key/Value functionality. Key is either the CI/CD job id (i. e. Jenkins or GitLab) or the checksum of the resulting build or container image.

White Paper — Registration

We will also send you the research paper
via email.

CodeNotary — Webinar

White Paper — Registration

Please let us know where we can send the whitepaper on CodeNotary Trusted Software Supply Chain. 

Become a partner

Start Your Trial

Please enter contact information to receive an email with the virtual appliance download instructions.

Start Free Trial

Please enter contact information to receive an email with the free trial details.