OK. But what I'm still missing is this: if unikernels are more domain- and/or task-specific, then the dev environment will branch, perhaps quite a bit. I.e. one dev environment for many deployables. We end up with not just the original (false?) dichotomy between config and compiled, but meta-config and, perhaps, meta-compiled. And that may even have multiple layers, meta-meta.
So, while I agree pwning the devop role allows the attacker to infect the deployables, the attacks have to be sophisticated enough to survive that branching to eventually achieve the attacker's objective. I.e. "closeness" in terms of automation doesn't necessarily mean "closeness" in terms of total cost of attack. It just seems that the more objective-specific the deployable(s), the less likely a hacked devops process will give the desired result. I'd expect a lot more failed integration/deployment attempts if my devops process was modified. But this is all too abstract, of course. The devil is in the particulars. On 08/11/2015 01:13 PM, Parks, Raymond wrote:
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.
-- 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
