Many ransomware attacks are not sophisticated. They may be targeted but the procedure is fairly simple: blast targets with phishing emails/texts, get them to click, done. It seems that zero-days are often not required because targets lag behind in applying patches.

Many (if not most) companies have file shares with fairly wide-open access and/or a complete lack of backups so peer-to-peer spreading within the company is enough to cause a lot of trouble.

At its root these are technological problems that we could choose to solve:

1. The program is not the user. Code running as a user shouldn't necessarily have permission to access everything the user can access.
2. New code is not treated with suspicion when it should be. New code should have its file access throttled in proportion to how many files it accesses.
3. Our systems do a terrible job of spotting unusual behavior. How many processes actually need to rewrite every file the user has access to? Almost none... rewriting 10% of the user's files should trigger an automatic throttle/stop and raise red flags.
4. As a variation on #3, most OSes these days ship parsers for a lot of common file formats... if the OS sees lots of user documents being rewritten and the parsers can no longer parse them stop allowing new rewrites and alert the user. If the user is encrypting their content on purpose they can approve it. If not you can at least limit the damage.
5. Similarly a network user that usually accesses a limited set of files should not be able to suddenly start rewriting thousands of files without some kind of intervention.
6. Our systems completely fail to take advantage of ancient technology called "file versions" (see VMS). Excess disk space should store old versions of files in a way that cannot be deleted (or the ransomware would just call that API or generate random writes to consume the space). Combine with 2/3: when there is suspicious activity on the system move into CoW mode and preserve previous versions of all files or an entire system snapshot and don't allow purging the snapshot without special intervention (eg rebooting into a special mode).
7. To go along with all of the above code should be tagged with its provenance in a system-tracked way. If a process writes a new binary to disk track that responsibility. Track it all the way back to the URL or email it came from. This entire audit trail should be attached to any of the mechanisms listed above. It should also be attached to any sort of activity monitoring program that shows you disk accesses, including historical accesses. If I see 50GB of disk reads/writes from a process group "JGjthjsfgl.exe, downloaded from p0wnme.example.farts" that is a huge red flag. Let me suspend that entire process group with a single click.

I'm sure smarter people could come up with even better ideas... but ransomware is absolutely something we can and should make nearly impossible. We could engineer operating systems to be resilient and limit the damage (eg: macOS prompting you to approve access to Desktop/Documents/Downloads) but it means giving up some sacred beliefs about how desktop operating systems should work that tends to make a subset of the HN audience extremely angry.