Ask Slashdot: Could We Fight Ransomware With 'Unencryptable' Folders? 437
CaptainDork writes:
I'm a retired IT guy and ransomware was not a huge thing 3-5 years ago (at least few victims were self-reporting) and I'm very curious about protection schemes.
In my, now ancient, world we did not encrypt anything -- anywhere. Seems to me the trick would be to mark certain places as "unencryptable," similar to long-time attributes like "hidden," "system," "read-only," etc.
Do solutions exist that would mark local data folders and backup drives as "unencryptable," and if not, do you think it could be done? If so, how?
Leave your best thoughts and suggestions in the comments. Could we fight ransomware with 'unencryptable' folders?
In my, now ancient, world we did not encrypt anything -- anywhere. Seems to me the trick would be to mark certain places as "unencryptable," similar to long-time attributes like "hidden," "system," "read-only," etc.
Do solutions exist that would mark local data folders and backup drives as "unencryptable," and if not, do you think it could be done? If so, how?
Leave your best thoughts and suggestions in the comments. Could we fight ransomware with 'unencryptable' folders?
what a stupid question (Score:5, Insightful)
Re:what a stupid question (Score:5, Insightful)
Yes, this is a ridiculous suggestion.
Here is the solution to ransomware:
1. Proper security so you don't get hacked
2. Backups so you can recover
Anyone who is too negligent to do these isn't going to set up "unencryptable folders" either, even if it was possible.
Re: (Score:3, Interesting)
Yeah ... but no.
Security can make things harder to hack (or break into or steal), but the concept of perfect security is a fallacy. This is taught in Security 101, at any decent school. Layered security is one of the best approaches - e.g. firewall, TFA, sandboxed systems, encrypted data - but even that will never guarantee 100%.
And backups are great ... and not 100% either. Once had to assist in picking up the pieces from a company that went under ... the code - probably written by an insider - was writ
Re: (Score:3)
So they had a DR procedure they never tested?
Re:what a stupid question (Score:5, Informative)
I do agree that backups are important, but I would say that additional measures need to be taken to have ransomware-resistant backups.
1: You need to save backups for a longer time. Perhaps set aside monthly archives for a few years, and quarterly archives for seven years. This is to counteract ransomware that silently affects backups.
2: You need to assume all clients are hostile and use "pull" backup clients, ensuring they cannot touch the backup repository. Mainly since some ransomware will search for network shares and eradacate them.
3: You need some persistence if ($DEITY forbid) a bad guy gets into a cloud account and purges everything. For example, Glacier has Vault Locks which are not removable by the account, and one can set a time delay before stuff can be deleted. The storage provider Wasabi has a compliance mode offering a similar feature, where data once stored, cannot be removed even by the root user.
As for security, probably the best defense is AppLocker and disabling EFS on Windows. However, the next generation of ransomware will only piggyback off of a signed application and use its own encryption. In my experience, AppLocker and disallowing unsigned macros from being automatically run in Word/Excel seem to be a good line of defense. FRSM, and "canary" files are also useful.
Windows also is slowly getting there. The latest Windows 10 edition offers Controlled Folder Access which is useful, although may bring issues installing stuff.
For home/SOHO users, if I had to give one easily followed instruction for dealing with ransomware, I'd tell them to install CrashPlan, BackBlaze, or even Mozy or Carbonite. That way, there are some backups saved off securely.
Re: (Score:3)
Re: (Score:2)
Saw this recently just blocked smb from unknown IP's and added good secure passwords to the dumbass account holders. Problem solved.
Also went to the backups which were fairly up to date do to hourly incremental copies
Re:what a stupid question (Score:5, Interesting)
How can you disallow encryption?
Actually, I can very easily think of a dozen ways. This isn't a dumb question at all and I'm sure every security company right now is looking at ways to identify write patterns that look like ransomware. For instance, is it reading files from folders all over a drive or sticking to one or two folders? If it's accessing and rewriting lots of files maybe it's safe but this is a great time elevate permission to the user. "This looks like ransomware should I proceed?"
OneDrive already has this. If you try to change too many files all at once it'll trigger ransomware alerts to the user. I've had it false positive a couple times when I was wholesale transferring tens of thousands of files out. But I appreciated this very simple algorithm.
There are more ways an OS could identify patterns that look suspicious.
1) Is this application accessing many files?
2) Is this application changing more than 90% of the bytes but still resulting in a file the same file size within 10%?
Antivirus can look deeper. If you inspect the code in memory you could identify fragments of code that contain known encryption algorithms. Flag again to the user.
Is the program terminating your magic software? (Score:3)
Anything you can do, malware can do sneakier. Once the program has control over the system, it can hide its activities from any detection software.
Re:what a stupid question (Score:5, Informative)
By making it a property of the file system. This is more or less what ZFS snapshots are.
Snapshots are WORM. Once a file is snapshotted you can't go back and edit it without destroying the entire file system, you can edit the 'live' version to your hearts content but the snapshots are there.
Re: (Score:2)
If the malware is smart enough and has root, it can access of destroy ZFS snapshots. If you run it remotely via the built-in NFS snapshots will remain inaccessible to malware on the remote machine.
Also you may want to scatter a few canary files around, scan them on a schedule, and force a read-only remount should the canary fail.
Re: (Score:3)
You don't know what a snapshot is, do you?
The OP is correct, snapshots (either ZFS, or on a NetApp Filer, or whatever system you want to use) are the requested solution to the question. They're also good for encryption malware detection, because when it attempts to rewrite all the files on the system, suddenly your most recent snapshot is going to take up way more space than usual, because it's storing all those changes. At that point, all you need to do it roll back to that previous snapshot and go make su
Re:what a stupid question (Score:4, Informative)
With the caveat that this approach assumes that the attacker has not compromised the kernel itself.
No, the right answer to questions like this is never a single technology, but rather always the same three words: Defense in depth. For example:
And so on. The more of the things on that list that you've implemented, the more likely you are to survive a ransomware attack unscathed.
Re:what a stupid question (Score:4, Interesting)
I forgot a few more:
Re: (Score:2)
Yes, It can be done. Linux supports immutable files/folders. The "chattr +i somefileorfolder" will become unwritable/unencryptable at the os level even as root, until undone.
Re: (Score:3)
FreeBSD supports the sappend (for files you can only add to, like logs) and schange (for files you can't change) flags. With a reasonably configured system they can't be modified (even by root) without rebooting into single-user mode (from the console) to reset the securelevel and explicitly resetting the file flag.
It does make it a pain to upgrade and/or change configs, though, because you pretty much need to have a working console and reboot to modify anything you wanted to be secure.
The only way around i
Read-only folder (Score:3)
How can you disallow encryption?
Simple: make the folder read-only. If you can overwrite files so can the ransomware.
Re: (Score:2)
turning off the read only flag on files owned by the user is as simple as typing "attrib" in cmd. You'd have to make the folder owned by administrators, which can cause issues for regular users interacting with it.
I'll give you that there is some data that;'s just fie being permanently read-only, but for most it needs to be interacted with., so the admin-owned read-only folder would cause issues for people getting work done.
But what you're just described is Version Control Software, and it already exists.
Re: (Score:2)
Made my day. Haven't seen a WOM in years.
No malware bit (Score:5, Funny)
Re:No malware bit (Score:5, Informative)
That is already solved. Just filter every IP packet that has the "evil Bit" set (see RFC 3514).
Re: (Score:2)
Re:No malware bit (Score:4, Funny)
Sounds more like no-Win to me.
No. That is not how it works (Score:5, Insightful)
As soon as an application can read and write a file, it can encrypt it. The OS cannot judge what the application does and it cannot determine whether a file does lot look like it should. Entropy checks (basically the only thing you can do automated to determine whether something is encrypted) fail on compressed data nd on random or random enough binary data. Sure, you could "tag" files with the type of data in there and even provide methods to check whether it is in the format it should be, but that would mean rewriting the OS and basically every application.
Please stop making suggestions how difficult security problems could be solved when you do not even know the basics of how the relevant computers work.
Re:No. That is not how it works (Score:4, Interesting)
Someone will get sick of jumping through the hoops and create a nice little super user work around command to make managing all of this easy, but then the system is only as good as the OS is at stopping privilege escalation. Never mind the the average user will just be duped into clicking a button and authorizing the malware to turn off the protections or change the program that owns every file to the malware program. There are probably ways to make that a little bit harder, but ultimately you can't protect an idiot from their own stupid actions if they're insistent enough, and many of them are.
Even if you do manage to do all of this and make it workable enough that people will actually use the system, it just shifts the attack vector to something else. There are probably plenty of other ways that people who write ransomware applications could screw with a system to essentially lock out a user and deprive them of their files.
Re: (Score:2)
Yes and this is how modern OSs built from the ground up with security in mind do it. However OSs with established applications which require and expect such measures to NOT be in place stop existing OSs (eg Windows) from establishing such a model.
Windows has a shot with the Windows Store but they also adopted all the negative aspects of that model in addition to the positive ones which put a lot of people off.
Re: (Score:3)
As soon as an application can read and write a file, it can encrypt it. The OS cannot judge what the application does and it cannot determine whether a file does lot look like it should. Entropy checks (basically the only thing you can do automated to determine whether something is encrypted) fail on compressed data nd on random or random enough binary data.
Actually, encrypted data would be easy to detect, and the combination of an existing file being re-written (encrypted) by a new application (or a browser) could trigger a UAC pop-up, or at least preserve the existing data.
Re: (Score:2, Informative)
Actually, encrypted data would be easy to detect
No, and for the exact reasons he already mentioned, for the exact reason you actually fucking quoted him mentioning, while you ignored it and just defiantly said stupid shit that isnt right at all.
Re: (Score:3)
The OS cannot judge what the application does and it cannot determine whether a file does lot look like it should.
If an application attempts to dramatically increase the entropy of more than 100 files... flag it and raise a user prompt.
You clearly explained how an OS or AV system can with minimal false positives flag unusual behavior and then dismissed flagging unusual behavior as nonsense. If what you're suggesting was impossible, no anti-virus application in existence would be of any use.
There are other ways too. The OS could create files that it hides visually from the user but knows are nonsense. If an applic
Re: (Score:2)
In theory, you could limit write access to some whitelisted applications. Then $GoodOfficeApp could still overwrite or otherwise change the file, but $Malware would be blocked. Or at least trigger an UAC check or its equivalent on the OS you use.
I say in theory, because I'm not aware of such a system being commonly in use.
Re: (Score:2)
We used to on classic Mac OS: Gatekeeper [macgui.com]. Basically, there were a certain set of behaviors that were considered interesting, like reading and writing files, opening network connections, etc., and if an app tried to do something expected, it required you to confirm that it should be allowed.
Re: (Score:2)
It's rather easy to fix though.
Some AV's basically see how much a particular program is reading/writing and indeed checking entropy. If a program is maximizing randomness while replacing documents and the like, it blocks it until someone can intervene.
On the other hand, a good OS would have a filesystem that has immutable snapshots. It's in macOS and Linux, not sure why Windows hasn't natively built-in immutable snapshots yet. Doesn't help against low level (block) encryption but that also requires deeper a
Yes, that is how it works (Score:3)
As soon as an application can read and write a file, it can encrypt it.
Which then suggests a no-write setting. Like the immutable bit in Linux. I already set this on important files that I know no one has any business changing. If the malware gets admin/root access, then this is useless. However, more and more malware doesn't have admin access. Just user access. And it's using user access to just encrypt that user's files. So, for important files where you know you never (or seldomly) need to edit them, the immutable bit is an effective tool for file protection.
Now, the
Re: (Score:2)
Not too difficult to create an encryption technique that passes an entropy test, especially if you allow it to increase the size of the file. Encrypt, then add something to it. Not to mention that a good compression algorithm yields something that appears to have very low entropy. If you leave some patterns in the output, then those patterns are something you can detect and represent with fewer bits.
Better Question (Score:3, Informative)
Re: (Score:3)
Not if the bomb is inside the underwear. If you know what I mean.
More on topic, my drive is already encrypted, so I'm 100% safe. It's not like anyone could encrypt something twice, except maybe with ROT13. Besides, my native language has more than 26 letters so even that wouldn't work.
Why am I seeing this post? (Score:5, Funny)
Re: (Score:3)
Minix3 does that more or less. If it detects and error, it spins up a fresh instance of the server/driver. Quite a few moving parts to get it to work well, you may lose, some state anyways, and crashes in the core micro-kernel, or simultaneous errors in the service watcher and the service watcher watcher will still cause a hard crash.
Sure (Score:2)
Boot from ROM and mount a physically segregated device as read only. Read only memory, or unalterable memory (CD-ROM).
Or just write it to CD ROM. It's literally in the name. It cannot be encrypted.
Backups (Score:2)
Do solutions exist that would mark local data folders and backup drives as "unencryptable," and if not, do you think it could be done? If so, how?
Just make sure your backup system pulls data from the systems to be backed up.
That is, never let the systems to be backed up push their data out or do the copy of the files, and never allow them to reach the backup system directly at a network level.
Ransomware infects a computer, inserts into the filesystem driver, and silently encrypts data on the disks/volumes in the background, all while re-decrypting it to give it to the OS when asked for.
This way you and the OS doesn't notice anything amiss.
After it is
Re: (Score:2)
Do solutions exist that would mark local data folders and backup drives as "unencryptable," and if not, do you think it could be done? If so, how?
Ransomware infects a computer, inserts into the filesystem driver, and silently encrypts data on the disks/volumes in the background, all while re-decrypting it to give it to the OS when asked for. This way you and the OS doesn't notice anything amiss.
It's possible to mostly detect this sort of tomfoolery with forensic file access techniques but you are correct as far as I can see about preemptively blocking it.
Fight ransomware with.... (Score:2)
I should write something more constructive, but... (Score:2)
lol
Re: (Score:2)
Don't laugh. Technically, there is actually one form of unencryptable folder: an empty one.
WTF (Score:2)
It's clear CaptainDork is a Windows user as he mentions the "hidden" file attribute. The solution is obvious to all *nix users however - just check for the evil bit on all downloads before executing them. Then you don't get ransomwared.
<DING> next question please...
Re: (Score:2)
Old Mac OS also had a "hidden file" attribute.
I just googled a bit and: voila! https://www.howtogeek.com/2114... [howtogeek.com] you can still have hidden files and folders on Mac OS X ... well, macOS now.
Re: (Score:2)
Wait a minute (Score:2)
Now, it's easy to dismiss the question right away as being fooling given how computers, directories and files work.
However, how about simply setting flags to every damn files and folders?
"Program Microsoft Word is trying to read file my-document.doc, allow? [Yes/No]"
Yes
"Program randomware1337 is trying to read file my-document.doc, allow? [Yes/No]"
No
Re:Wait a minute (Score:5, Informative)
Re: (Score:2)
I never used Vista, so I didn't know. You learn something new every day, I guess.
Re: (Score:2)
They tried that with Vista. ;-)
Re: (Score:2)
And what happen when the ransomware pretends to be word and gives you the question
"Program Microsoft word is trying to read file my-document.doc, allow? [Yes/No]"
Yes
PS Note the spelling of "word".
Already exists (Score:5, Insightful)
The problem was never safeguarding data against ransomware. That problem was solved back in the 1960s decades before ransomware first appeared. The problem has always been that people are lazy. They either don't bother making backups; or if they do they'd rather use a "set it and forget it" system by leaving a backup hard drive always plugged in, or don't want to be bothered with shuffling multiple optical discs to backup their multi-TB drive.
Re: (Score:2)
Write-only memory. Signetics Write Only Memory 25120 Datasheet
https://www.baldengineer.com/w... [baldengineer.com]
WTF? (Score:2)
Sort of (Score:2)
You could write all your changes for that folder to a physically write-once medium, such as burning to a CD. Then you'd virtualize that as an "unencryptable" folder. It's really just backing up to a write-once device. You couldn't do it for a lot of data, because AFAIK write-once media still don't have particularly high capacity. Recovery from attack would involve running through all the changes on the CD, applying them until you had the latest revision. One broken file could make recovery difficult, s
backups (Score:4, Insightful)
Sorry to say it but its easy: backup your stuff on a incremental basis. Usually you'll see a few files change.
The day that every file changes, you'll know something has changed your system, you can check to see if its not something you did that updated them all (some service that updates metadata for example) but if its not, you can wipe and restore from the last backup. Preferably the backup software would notify you that an unexpectedly large number of files were changed (ie encrypted) and let you stop further backups to retain the good versions.
Detection is the key, if you can detect that your files have been hit with ransomware, yiou can restore them.
Unenforceable (Score:3)
Malware doesn't use the transparent file system encryption tools provided by the OS. It simply overwrites the files with encrypted versions of themselves using its own encryption scheme, silently, until it has enough leverage over the end user to display a message holding the files hostage. The OS can't tell the difference between malware and any other sort of normal write activity.
That said, a smarter OS *could* notice that user files are being read or written at a pace or breadth that is inconsistent with the user's normal activity, and it could then quarantine the processes involved until the user or administrator confirms that the activity is expected. That would of course create the usual issues of needing to whitelist certain processes, and if that is something the user can do, it's also presumably something the malware can do running under the user's privilege.
Honestly, the best *final*-tier protection is the same as it's always been -- good backups. Preferably, backups that are automatic, preserved for some reasonable period of time, and are logged and verified by someone other than the user. The vast majority of these ransomeware attacks did nothing that wouldn't have happened eventually when the users' hard drives wore out.
Versioned back ups (Score:2)
First of all if the malware "roots you" you are mostly out of luck.
However a back up system, that runs as a different user, and only has read access to your files, could write back ups on a different partition, even with versions, aka simply hold a git repository or something similar on that other partition. Actually it could simply be a folder on the main partition.
Background is: the malware running as YOU can not access or write to the folder/partition that belongs to the backup software. Should be nearly
Not really. (Score:2)
Only on read-only or offline media.
Good that he asked... (Score:2)
It's a naive question, but it's great that he asked.
A 'do not encrypt' bit in the OS wouldn't stop an attacker from encrypting files, because the OS can only prevent the OS itself from encrypting files, it can't prevent some other code from doing so, because all the OS would know is that a file is rewritten with a new version of the file.
The only way to protect youself from an attacker encrypting files is to make backups, and to keep archives that go back long enough that you can recover if a file is encryp
I have the solution.... Read Only Media (Score:2)
Simply write all your folders to read only media so that they can't be modified or encrypted. Easy peasy!
I'm not surprised (Score:2)
If we ask nicely (Score:2)
Windows has "Controlled Folder Access" (Score:2)
They don't need to be "encrypted". In fact, your "not unencryptable" wouldn't stop someone from overwriting them.
They just need to be protected. It doesn't matter how.
Windows already has a feature called "Controlled Folder Access". That's exactly what it does. You specify the folders. Nothing can write to them. If anything tries, you'll get a notification saying that it was blocked.
And then you can white-list programs that can access them. It's not [yet?] fine-grained, but that's okay today.
Re: (Score:2)
Re: (Score:2)
Then didn't you kind of authorize them to do so? Bypassing the OS isn't something that is (realistically) going to happen from just receiving a random spam e-mail. Truth is that I have no idea how far controlled folder access goes, or could go.
I'm fine with the chaos that comes from opening a strange attachment, downloading a strange executable, or intentionally visiting a strange web-site. Those are no different from accepting a package on your doorstep from some guy in a hoodie, walking into a stranger
Re: (Score:2)
I guess you don't value your comment, if you aren't even willing to put a name to it. I don't see a reason to value it any more than you do.
Re: (Score:2)
Re: (Score:2)
Wasn't willing to put a name to it. That means she didn't think it was worth even that much time. That was my point. Thanks for corroborating it. If you won't stand in front of it, and you won't stand behind it, then it ain't worth much to you.
Re: (Score:2)
my encryption software (Score:2)
Did you retire (Score:2)
because you made so much money off your algorithm that can detect encrypted files?
not necessary; just don't let them in to begin wit (Score:2)
There are already well known standards to keep this sort of attacker out of your system long before folder access becomes relevant.
See rfc-3514 for the pertinent specification.
Canaries (Score:5, Interesting)
Encryption is manipulation of bytes. Think of it as scrambling the bytes. Whether MS Word is doing it in a wanted fashion or hotAsianPr0n.jpg.exe is doing it in an unwanted fashion - that's a hard problem to solve. Bytes are changing on the filesystem - innocuous or malicious?
One way to detect it perhaps are maybe "canaries". Sections on disk monitored by say the kernel, that are supposed to be immutable. If one of those changes - it should never change - the system goes on lockdown. All reads and writes are halted.
Ransomware doesn't attack the OS - the system wouldn't be able to boot. They need the OS to relay instructions to the user about what is going on and where to send the bitcoin. So there's a bit of a fortress in the OS.
So... canaries. Section of the disk or memory that are supposed to be immutable. If they change - system halt until someone takes a look with a forensic tool. It won't save all your data but it'll save a chunk of it. And it could limit propagation of the malware.
If you kill the canary, the OS kills you.
The canaries would be set randomly every time at startup, so a malware writer wouldn't know where they are. There could be an encrypted section of memory or disk that contains pointers to the canaries.
One angle to consider.
No (Score:2)
Yes (Score:2)
Mount the drive read-only.
Backups (Score:2)
Backup your important data to a WORM (Write Once Read Many) device like a BD-R.
The answer is no (Score:2)
"Could We Fight Ransomware With 'Unencryptable' Folders?"
The short answer is no.
I actually just went through a bad ransomware attack.
First, suppose a file contained: "Hello wurld."
If I wanted to correct it... "Hello world." that requires changing a character, and saving the new file. If I decide I want to save it as "Hello Mom" instead. I've rewritten half the file. Maybe I want to change it to "Goodbye Mom". And now I've changed everything.
There is no technical difference between "Goodbye Mom" and encrypting it: "kfjq3fk4 a9a23kkj.alkrjm34kl1jcfakdjfakjn32". And
Probably impossible (Score:2)
If the data can be READ and DELETED by the attackers, then they can just encrypt it after they copy it. Or hold it ransom without encrypting it for that matter. This is the same effect as encrypting it in-place.
Dumbest Ask /. ever (Score:2)
Re:How computers work (Score:5, Funny)
Of course all malware/ransomware writers will honor the "noEncrypt" flag... won't they?
Yeah, right!
Re:How computers work (Score:4, Insightful)
Just like web sites honor "Do Not Track."
Re:How computers work (Score:5, Funny)
Surely we could just make hackers agree to an EULA before access out systems. Those things are super binding.
Re: (Score:2)
To be fair: I don't honor 'do not scrape' either. (IIRC robots.txt, not sure never look.)
Re: (Score:3, Interesting)
Take a folder and only allow whitelisted applications to access it or the files in it, that way the malware is unable to access it.
Not exactly according to the question but similar basic concept.
There may be a way to enforce unencryptable on known file types, where a copy is kept and any application trying to write the file would have to write to the default location. Then the antivirus (or anti-ransomware) software noti
Re: How computers work (Score:2)
The hardware cannot enforce rewriting the damn file with an encrypted version
Re:How computers work (Score:5, Informative)
I am. It's been tried, by tools like SELinux and mounting "immutable" filesystems with "rad-only" access. It slows down various classes of attack. But it doesn't work well with personal data, which must be mutable and editable by the user at run time. UEFI tried to do something like this to the BIOS, but created so many problems and broke so many systems unexpectedly, and left so many subtle holes in the tools used to handle it, that it's been a net loss compared to the disasters it has prevented.
Re: How computers work (Score:5, Insightful)
A person is admitting to not knowing and asking to be educated.
Give them a good pointer or shut up.
Re: (Score:3)
Give them a good pointer or shut up.
0x009d4b47 ... and something tells me the OP would not get this response :)
Re: How computers work (Score:4, Insightful)
A person is admitting to not knowing and asking to be educated.
Give them a good pointer or shut up.
The problem is not the random idiot that asked the question. The world has billions of random idiots, and they ask dumb questions all the time.
The problem is that this question is on Slashdot. Is there no filtering at all?
More than half the articles on Slashdot's current front page are about politics or corporate marketing. Even those are better than this crap.
Re: (Score:2)
Re: (Score:3)
Ehh, no, you should learn about NTFS and ACLs. Then you'd know they are software abstractions and as such easily circumventable by malware that managed to gain access to the kernel level.
If it hasn't access, it at least has access to the user-level, in which case it would be trivial to strip the users documents of that no-encryption flag. And if somehow magically it wasn't able to do that, it could just plain try to 'edit' the document. How does the operating system distinguish between something vague like
Re: (Score:3)
ACLs, in the NTFS sense, control access by user or group membership. There's no permissions that enables/disables encryption of file content.
Even if there was such a permission it would rely on Windows encryption APIs working with the file system drivers to indicate that the content being written is encrypted.
Even if such cooperation were in place there's nothing stopping a program bypassing it and using its own encryption implementation - like how Symantec used to encrypt their file content by XORing every
Fire, theft, drive failure - off-site backups (Score:5, Informative)
Creative thinking and asking questions is fine.
Since a question was asked, here is the answer:
There a a dozen ways your data can be lost - fire, theft of the hardware, ransomware, accidentally overwriting data, etc. The solution to all of these is proper, tested, off-site backups.
There are lots of ways this copy of the data could get messed up. No matter how it got messed up, what you need is another copy that isn't messed up - a backup system.
Proper backups have a few characteristics. They should be incremental, or rotated, not only a single copy from last night. If you run backups at midnight, dollars to donuts the data gets corrupted at 11:50 PM, so a poor "backup" would just give you two copies of garbage. You need to be able to go back to last week.
They need to be off-site. If your building gets burned or burgalizered, everything in the house is gone.
Ransomware reminds us of one other attribute that's often forgotten. The backups really need to be pull, not push. At least, the machine being backed up can't be allowed to delete prior backups. Ransomware (and really stupid mistakes) can wipe out network drives, so you can't give it permissions to delete (or encrypt) its own backups.
Re: How computers work (Score:5, Insightful)
Re: How computers work (Score:2)
/retired/fired/
This question is so stupid as to beggar belief
In pseudo code:
Forall F in folder
X = read( F )
Y = encrypt( X )
write( F, X )
Re: (Score:3)
It's the polygon 'tard again.
Re: (Score:2)
The data that is most interesting for ransomware is data that is constantly being changed: Email databases, text documents, spreadsheets and the like. That doesn't work with read only drives. And WORM becomes impractical with lots of changes and to expensive with big files (videos, picture collections).
And as for a cert challenge: There are lots of different programs people use to work with their data. How will you make sure those programs get through but ransomware doesn't?
Re: (Score:2)
By making anonymous methods of payment far more difficult.