The 'silent' hacker and Encryption keys

[ortec-RW]

Hi,

The following scenario was discussed within our IT group.
What if a hacker enters your environment, and secretly replaces the Veeam Job/Repo encryption keys ? There's no way for me to detect the key was changed in Veeam B&R (I think ?). Jobs just continue as normal, putting data into Repo's and off-loading to immutable S3. As if nothing has happened.

After a certain period, lets say 2 months, the same hacker strikes again, and encrypts your entire production environment and demands a bunch of Bitcoin. You start laughing because you're sure you still have those immutable backups in S3 and an offline copy of your encryption keys. Right ?
Then you find out during the green-field restore, on a fresh new Veeam B&R server, your keys no longer work. They were replaced with unknown ones 2 months ago. And the original Veeam environment is encrypted by Ransomware just as your production environment. So, you're screwed.

You might say, "Make sure a hacker never gets into your Veeam !" Yes, I agree. That's the whole idea. But if I can do that I won't need immutable S3 in the first place. He eventually will get in. Hell, I'd even allow him into Veeam if he physically puts a gun to my head.

A similar scenario could be a hacker changing the immutability period on the S3 Repo. Lowering it to the minimum. New backup-data put into S3 will follow this new lower policy. The old backups still maintain their original policy, so those backups are safe. But older backups tend to be less valuable. In a Ransomware scenario, you want to restore your most recent immutable backup. In this scenario, the hacker doesn't even need to hang around in stealth mode for very long to still do serious damage.

So, where am I missing a vital step ?
What would you do to mitigate this risk. Start auditing encryption key-changes ? How ? Even longer immutability in S3 ? Extra offline backup copies ?
Any thoughts ?

Greetings, Richard

PS Don't worry too much. I still sleep as a baby.

[sfirmes]

Richard,

To address your concern about a hacker reducing the immutability duration, Veeam ONE has an alert just for this scenario: VeeamImmutabilityIntervalDaysDecreased

If someone changes the immutability duration on a repository, you can have alerts via email, SMS, and on the Veeam ONE dashboard notify you of the change.

And yes, I suppose a Veeam savy hacker could turn off these alerts as well. So that is where you could use the four-eyes authorization that was introduced in VBR 12.1 to prevent this sort of behavior.

Hope this helps.

Steve

[mjr.epicfail]

Hi Richard,

Make sure you have an up to date VBR config backup file somewhere, immutable for a month and then make a copy to airgap.
All encryption keys/hashes are in this backup file and or the DB of choice that you use.
You can then import this config backup into a fresh VBR and access everything, even with the unknown encryption key.

This backup config file is *VITAL* for a reason