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.
Thoughts welcome.
// EDIT
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.