Hacker News Reader

Comment by tatersolid | Hacker News Reader

> This protects me against…malware attacks

Are you sure about that? Many ransomware attackers do recon for some time to find the backup systems and then render those unusable during the attack. In your case your cloud credentials (with delete permissions?) must be present on your live sou ce systems, rendering the cloud backups vulnerable to your overwrite or deletion.

There are immutable options in the bigger cloud storage services but in my experience they are often unused, used incorrectly, or incompatible with tools that update backup metadata in-place.

I’ve encountered several tools/scripts mark a file file as immutable for 90 days the first time it is backed up, but not extend that date correctly on the next incremental, leaving older but still critical data vulnerable to ransomware.

View on HN

I discovered recently that Microsoft OneDrive will detect a ransomeware attack and provide you with the option to restore your data to a point before the attack!

MS need to advertise this feature more, because I'd never heard of it and assumed all the files on the PC were toast!

Of course, the fact that a script on Windows can be accidentally run and then quietly encrypt all the users files in the background is another matter entirely!

Most cloud providers do this now. Encryption operations like this are relatively easy to detect.

Actually I think almost all malworm worms are totally automated. The attacker knows nothing about your network and backups, it just encrypts and deletes absolutely everything it has write access to.

Not true, even though that might depend on how valuable you are to a ransomware threat actor.

The DFIR report has some insights: https://thedfirreport.com/category/ransomware/

There are no delete credentials, and the WORM option is enabled when a provider supports it. I can ~always get back to point-in-time.

No delete credentials present a cost issue when moving from a provider... I've accidentally left data behind after I thought I'd deleted it. Worth the risk, and learned my lesson.

You can set a lifecycle rule. You don't need credentials to delete.

Only if you allow permissions to set a lifecycle rule...

You don't set the lifecycle rule at runtime. You set it at environment setup time. The credentials that put your object don't have to have the power to set lifecycle permissions.

You obviously don't put your environment setup user in your app. That would be utterly retarded.

Not useful for me at environment setup time because I never want any of my data deleted. The only time is if I decide to abandon that cloud provider.

And when you're moving providers you use your application credentials to do that? That makes no sense. This is nonsensical engineering. You'd use your environment credentials to alter the environment.

I'm not "engineering" anything - I'm just stopping a service. I close the account, or disable billing, or whatever that step requires. I don't even read the data back out or anything - just cancel. Doesn't really require "engineering".

Reply on news.ycombinator.com