Ask HN: How is encryption-based ransomware still a thing?

[pengwing]

From my understanding you only need two countermeasures (i) an append-only database (no mutable data) to store everything business critical and (ii) use virtualization on all clients to quickly re-provision a clean OS version.

So why does a recovery from ransomware take more than 300ms?

[new_guy]

Well for a start you need to know how they got into your system, sure you could patch it all up in '300ms', but they'd just hack you again straight away.

[pengwing]

Sure, but that applies to any kind of malware and is orthogonal to the actual question of ransomware. Fixing the vulnerability is more often than not simply an update of the vulnerable server software, while recovering the data and bringing the entire IT infrastructure into a functional state is currently the time consuming part.

[thesuperbigfrog]

>> use virtualization on all clients to quickly re-provision a clean OS version.

If the virtual OS has a vulnerability it will get hacked again.

If the hypervisor has a vulnerability, you won't be able to reprovision.

>> From my understanding

If your understanding is correct, wouldn't the problem already be solved?

If you DO know how to solve the problem, you could make millions by fixing the world's computer security problem. Go for it!

[pengwing]

Gonna challenge the last part. You can probably make billions with disaster recovery, but I doubt that you can make anything with disaster prevention.

[magicalhippo]

> (i) an append-only database (no mutable data) to store everything business critical

How does that change anything? If your append-only database is encrypted by ransomware, you still have to recover from backups, no?

In which case you're in the same spot with regards to external services you integrate with. That is, out of sync.

[pengwing]

Not sure whether I understand your attack scenario: If the database itself has an exploit to bypass the append-only functionality: All is lost, agree. But if some of the hosts are compromised which push garbled/encrypted data to the database, you can recover from it by simply ignoring it as it does not overwrite any prior valid data.

[magicalhippo]

> you can recover from it by simply ignoring it as it does not overwrite any prior valid data

The point I'm trying to make is that a lot of systems interact with other systems.

For example, imagine my system generates an invoice, sends the invoice to a third-party for collection, the collection system replies with a token to track the invoice in their system. Finally the invoice is marked as paid once the third-party system returns an "invoice paid" message with that token.

Now imagine the system generated an invoice and sent it to collection, and is then hit by ransomware. I restore from backup or as you say ignore the data since the attack. Except now I don't have the token, so when I get an "invoice paid" message I don't know which invoice that was for.

We have several integrations which work not entirely unlike this, and disentangling the mess of these "desynchronization events" is what has taken the majority of our time when helping a customer after after a ransomware attack. Fortunately it's only been one or two a year.