> On 2015-09-25, at 02:11 , Yves Dorfsman <y...@zioup.com> wrote: > > > I'd like to hear from people who worked in environments requiring "separation > of duty" (SOX, PCI) and how they have dealt with: > > - continuous delivery: how do you automate deploys if a "trusted human who > is not a dev" has to sign off each deploy? > > - mixed team and separation of duty: especially on smaller teams, the ops > people might be involved in some of the developments, in some areas, both dev > and ops will be involved (build and deploy code), which leads with people with > needing both repository access to code and ops access to infrastructure. >
I’ve done plenty in mixed PCI and SOX environments, including audit response on both (okay, PCI validation response + SOX audit response). My SOX is a bit rusty, but PCI, I’ve kept current. SOX requires SoD, but generally, the details of the way the SoD are done are left to your security policy. (Updated guidance may have come out in the past two years on this subject.) A truly automated deployment I’d suggest handling as follows. For your production branch that is built automatically, require m of n before any code can be put into that branch. That means that you define some number of code reviewers. You could even have two layers if you’re really paranoid. Code goes from the general dev branches to a QA branch based on a non-developer who signs off on the commit, then a m of n (e.g. any 3 of these 5 people) to promote from QA branch to production branch. The act of building and deploying code once it is in the prod branch would be automated, but getting into that branch is where I’d put the SoD. For the second, you’re pretty close to out of luck. The sysadmin of production cannot be a developer of the application. The developer cannot have OS admin rights on production. I would not attempt to defend to a SOX auditor or a PCI QSA any violation of such, because the language of 6.4 (PCI-DSS) is rather explicit, the guidance reducing it to plain English. For SOX, the fundamental requirement of SoD is intended precisely to prevent the developer from having root in production. PCI also has the rule that compliance with one requirement cannot be used as a compensating control for non-compliance with another requirement. That makes your job even harder. Note, one side effect of the SoD requirement. Your logging infrastructure needs to be protected from your sysadmin and dev teams, both. (10.5 comes to mind, only real way to protect your logs is that the people who are being monitored don’t have write access to your central copy). Slightly rushed on the response, so I may look at this in a few hours and wonder why I responded before tea, but I think I cleaned it up enough. ---- "The speed of communications is wondrous to behold. It is also true that speed can multiply the distribution of information that we know to be untrue." Edward R Murrow (1964) Mark McCullough mark.mc...@gmail.com
_______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
