I would expect the dev environment to be closer if not actually in the same hypervisor. It's almost like the web-site we once attacked by using the java compiler on the web-site's computer sytem to modify the code in the web-site. Right now, with devops, the dev environment is probably not in the cloud/hypervisor. And, for unikernels that may also be true. But to deploy quickly in both devops and unikernel, there has to be a direct channel from dev to cloud.
In more traditional environments, there's a dev server in a separate space, a testing server in its own environment (sometimes shared with production but not touching production data), and a production server. While traditional environments don't always follow the process well, in theory the flow is developers develop on a development network with the dev server, roll their system into the testing server which runs alongside the production server with a copy of the production data and processing real or test transactions, and finally install the tested version on the production server. From my standpoint, that means I can attack the production server directly or the development server on a separate network. There has to be connectivity, but it's likely to be filtered, if only to prevent the development server from affecting the production environment. In devops and in future unikernel systems, the pace of change is, of necessity, much faster and the three roles are collapsed into one VM. The VM image is modified in place, given a new name so that rollback is possible, and the management software is told to use the new image instead of the old. One of the principles of cyberwarfare (as formulated in our paper of that name) is that some entity, somewhere, has the privileges to do whatever the attacker wants to do and the attacker's goal is to become that entity. In the case of devops and unikernel, that entity is the developer(s) who make(s) the changes to the VM. In traditional environments, the attacker might need to assume the privileges of several entities. Ray Parks Consilient Heuristician/IDART Old-Timer V: 505-844-4024 M: 505-238-9359 P: 505-951-6084 On Aug 11, 2015, at 1:50 PM, glen ep ropella wrote: > > 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
smime.p7s
Description: S/MIME cryptographic signature
============================================================ 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
