I'm so outta this conversation! Could one of us give a brief explanation of unikernels and the related tech being discussed?
On Tue, Aug 11, 2015 at 2:49 PM, glen ep ropella <[email protected]> wrote: > > 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 >
============================================================ 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
