3 ms·
We could reduce our risk a lot using a combo of technology that isolates executions to certain deprivileged memory ranges with tech that blocks code injections
by nickpsecurity 8y ago
We could reduce our risk a lot using a combo of technology that isolates executions to certain deprivileged memory ranges with tech that blocks code injections in general. Think a separation kernel running a desktop OS in one partition and in another a PDF viewer written in Rust. The general tech for stuff like that was being sold commercially far back as 2005, minus Rust of course. They did have Ada runtimes, though. The NSA and military ended up retiring the concept because there was too much complexity in PC hardware they thought would lead to attacks bypassing the VM boundaries. They did.
The old approach, which I used, was to use a mix of desktop and embedded boards physically separated with a KVM switch plus controlled, sharing mechanism. Just keep the untrustworthy stuff on their own machines. It's klunky but a greater chance of working securely.
- Thriptic 8y agoWould it be possible to simply serve employees a hardened email VM on demand which included editing and composition utilities (office, Adobe)? I envision something that could be destroyed after each use to prevent persistence and could be put on a VLAN which included only the email server and specific internal services if need be to make pivoting difficult.
- irundebian 8y agoThere is something similar on the market called Bromium. It spawns micro VMs for some filetypes so that possible code execution is contained within the micro VM. Still haven't tested it. https://www.bromium.com/ https://www.bromium.com/
- nickpsecurity 8y agoThat's what I was talking about with VM risk, though. You're right back to it. Even the most secure VM will have the hardware and firmware in its attack surface. Those are getting tons of attention right now. It will reduce the number of times you get breached with associated damage. It's not as secure as physical separation, though.