If I understand what you're saying, you're still admitting that the attack has to happen at a greater "distance" from the target, right? Even if the dev env is "virtually close", it's still at least 1 step removed from the deployed thing.
On 08/11/2015 12:28 PM, Parks, Raymond wrote:
The security improvements of unikernels may be overstated. Look at the announcement, last week, of installing malware on LTE/3G modems built into laptops and tablets [1]. As Rich Murray pointed out in his comment on the subject in SANS Newsbites - these modems are a thing, an appliance, in the Internet of Things. The ability to fix these things is necessary to the developers of the things. Unikernels, with configuration baked in, will have similiar needs. In the case of unikernels, editing of configuration inputs and recompiling/linking will be required instead of a manufacturer's backdoor to update firmware. The development environment to make those configuration changes must be virtually close to the hypervisor runtime environment of the unikernel. That means the development environment will be a target. Of course, the real target will be the unikernel VMs that are poorly configured. The unikernel is the ultimate reaction to the exploit - but it does nothing for attacks that simply use the system as designed to do the attacker's bidding. [1] http://www.computerworld.com/article/2968274/security/internal-lte3g-modems-can-be-hacked-to-help-malware-survive-os-reinstalls.html
-- glen ep ropella -- 971-255-2847 ============================================================ FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
