I don't think there's a need to go into the background here, but identification of the process may be better explored.
From a developer pov, at a high level, the files are modified, by virtue of the attack and attacker, they are modified quickly. This is an I/O operation. If I wrote a service that would monitor the IO on my machine for a large bump (configurable, process aware etc but thats implementation) could I not easily identify that; something weird is going on and shut down I/O ops for that period.
I do understand the implications of having low lvl HW control from a service/application, but lets say its a unicorn.
Is this the fastest response to 0days which wont be picked up ? To write for the HW level ? Or are there other factors involved ?
I know retail machines, even enterprise deskptops would not fly, but datacenter lvl, where backup corruption would be catastrophic would surely see some value.
The initial idea was to write for the firmware level, then maybe the bios, maybe even if advanced options of SSD's for example, I don't mean a service that will sit in the OS, as close as possible to the the HW lvl, hopefully self container like a PLC .. Well better.
// Edit 2 Comment @sir-muffington
This wasn't mentioned yet: protecting your MBR/GPT against overwriting is a good approach to protect against ransomware.