RE: Procedural Issues

Hi Vic

Thanks for your helpful reply earlier on this topic. It took a while for 
initiating this segregation of duties into the system.

Having initiated, I came across a few more hiccups. Foremost of which is an 
understanding on my part and that is, should the development/test and live 
environments, be physically and totally segregated or is it a matter of 
having just logical access controls in place , in the form of 
user/developers denial of Active directory rights in the production 
environment will do?

The reason that this question arose is because I was wondering, if the 
auditors will talk about residual risk in an event the developer leaves a 
backdoor/ malicious code within an application which would allow him the 
access to that application bypassing all logical access control mechanisms.

So, what do we technically mean from network design point of view when we 
say that development,test and live environments should be different with 
developers having no rights on production?




At 04:44 PM 1/8/2007 -0800, Vic N wrote:
> <opinion>
> Operational personnel should promote code into production.  The risks of 
> having a developer promote code include (but are not limited to):
>
> 1.The ability to make undetected (unauthorized) changes to production.
> 2.The ability to introduce security or financial reporting holes into 
> production (fraud or access) with unauthorized code changes.
> 3.Disrupt business operations due to lack of proper QA (Change Control).
>
> Moving code from dev to prod should include an intermediary QA process by 
> which someone other than the developer reviews and tests the code for bugs 
> or impact to production.  Only code that has been subjected to such a 
> review should be implemented by operational teams.   Such code can be 
> released by a release controller (QA Lead) to operations or by operations 
> checking out approved code from a CVS repository.
>
> Typically operational personnel are not developers and do not have the 
> same capability to modify code (as a developer does).  However, 
> operational personnel should generate unique audit trails and not be a 
> part of the formal code review process (although they may perform their 
> own testing of a new release to obtain a level of comfort new code won't 
> break things).
>
> If you have one person writing code, one person performing QA and one 
> person deploying it - statistically speaking, the likelihood of fraud 
> occuring where all 3 have to participate in the fraud is much less than 
> one person performing all 3 functions.
>
> Obviously the effort should be proportional the size of the team and the 
> operation and the risk associated with the particular code.  Practically 
> speaking, it is usually the rush to release code that breaks operational 
> systems (change control).  A formal release process that includes a QA 
> process can help prevent that by introducting basic sanity checks into the 
> release process.
>
> I have heard auditors  argue that a lack of segregation of duties presents 
> an "unbounded risk" or one that cannot be adequtely measured.  Even a 
> simple setup of segregation of duties can save you hours of open-ended 
> discussion with auditors.
> </opinion>
>
>
> > In a software development environment, what risks do we have if we 
> > allowed software development team leader, access to Live production servers?
> >
> > Security demands that the two environments be segregated.
> >
> > If I segregate the two environments, who would shift the code from 
> > development to Live?
> >
> >
> > ---------------------------------------------------------------------------
> > This list is sponsored by: ByteCrusher
> >
> > Detect Malicious Web Content and Exploits in Real-Time.
> > Anti-Virus engines can't detect unknown or new threats.
> > LinkScanner can. Web surfing just became a whole lot safer.
> >
> > http://www.explabs.com/staging/promotions/xern_lspro.asp?loc=sfmaildetect
> > ---------------------------------------------------------------------------