You're leaving off two details in your otherwise nice list. First, the backups aren't going to help you in a targeted attack if the attacker can mess with them. For this reason, I always recommended write- or append-only storage for backups. Or a second copy on these made later (i.e. batch process). I used CD/DVD-R's.
Other thing is you've hit problem (0-days) without solution (isolation). There are numerous technologies, especially separation/MILS kernels, that can isolate damage inside one or more VM's. They can also run security-critical processes outside of them directly on the kernel or in their own VM. INTEGRITY Desktop, LynxSecure, and Turaya Desktop are commercial examples. QubesOS, GenodeOS, and Muen Separation Kernel are open-source examples.
So, there are two things. We also have all sorts of interesting tech for protecting kernels in the works in academia that might transfer to rest of us eventually. Better virtualization (esp I/O), DIFT, CPU obfuscation, tags, capabilities, automatic safety/security transforms... you name it, there's already prototypes. So, all is not lost yet. :)
Good point on the seperation kernels. I really like the team behind QubesOS, who have written some of the first evil maid articles I've read, but I haven't tried it yet. Have you used any of those systems and have an insights? Are they usable or still in the works?
Of course DoD/Darpa have their nice little distros but they tend to be proprietary and expensive so I essential pretend they don't exist for my purposes.
QubesOS founder and I got into it on their mailing list so I haven't tried it. Joanna updated her blog and FAQ to try to counter every point without mentioning my name or allowing replies lol. Anyway, my worries were: the Dom0 code in TCB, Xen kernel's complexity plus bug count, no covert channel analysis, that she was unaware of all similar research/issues in that area before Qubes, that she didn't know why user-mode drivers improved system robustness, and that she cited Mach/Darwin as why microkernels like L4 weren't good foundations (?!). All troubling traits if I'm to trust what they produce against High-Strength Attackers. However, my friends that have tried it like it, praise the usability, and say (with backups) you could use it day-to-day. So, I recommend it along the same vein as whitelisting and anti-virus: stops low to mid-grade attackers along with background radiation of Internet.
Plan to try all three again soon. Muen is a straight separation kernel with static configuration. So, will be limited but usable for simple setups: appliances, trusted + untrusted VM's, main stuff in Linux w/ crypto stuff in OBSD or native partition, maybe embedded on decent hardware, etc. GenodeOS is getting rapid development for a small project with a clever, resource-management architecture that needs further evaluation by pro's. Unlike QubesOS, they follow academic work producing best-of-breed components (eg Nitpicker GUI, seL4) and try to integrate them. Project itself was result of work to make more secure architecture. Both of prior have tiny TCB w/ GenodeOS having microkernel's performance advantages (Muen situation unknown). Finally, QubesOS builds some nice architecture, excellent usability, and hardening on top of mature Xen code-base with its risks/rewards. So, not really apples to apples here with any of them. QubesOS is definitely ahead in usability and features, though.
"Of course DoD/Darpa have their nice little distros but they tend to be proprietary and expensive so I essential pretend they don't exist for my purposes."
That's true. You have to pay to get the really good shit. OSS/FLOSS never do [1] high-assurance security, though: almost always companies or academia releasing it OSS after the fact. So, I've been investigating models that combine open-source, proprietary licensing, and review. If that's a shock, it's because almost all online discussions talk either proprietary/closed or free/open. However, that's barely relevant for security in practice and narrow thinking that misses other options [2]. So, my idea is to make the software proprietary, optionally a non-profit, have pro's build it for money, put an upper bounds on licensing cost, keep purchases perpetual, simple contract terms that won't change, source provided, extensions allowed with re-submission requirements yet to be determined, paid review by pro's, rewards to encourage others, and contractually to be released Apache/GPL if company tanks or product to be discontinued. This should cover extreme sophistication and labor required to build high-security, let people extend, let people fix stuff, and being more trustworthy. Your thoughts?
Other thing is you've hit problem (0-days) without solution (isolation). There are numerous technologies, especially separation/MILS kernels, that can isolate damage inside one or more VM's. They can also run security-critical processes outside of them directly on the kernel or in their own VM. INTEGRITY Desktop, LynxSecure, and Turaya Desktop are commercial examples. QubesOS, GenodeOS, and Muen Separation Kernel are open-source examples.
So, there are two things. We also have all sorts of interesting tech for protecting kernels in the works in academia that might transfer to rest of us eventually. Better virtualization (esp I/O), DIFT, CPU obfuscation, tags, capabilities, automatic safety/security transforms... you name it, there's already prototypes. So, all is not lost yet. :)