Home page logo

basics logo Security Basics mailing list archives

RE: Procedural Issues
From: WALI <hkhasgiwale () gmail com>
Date: Fri, 09 Mar 2007 17:34:43 +0400

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:
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.

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.


  By Date           By Thread  

Current thread:
  • RE: Procedural Issues WALI (Mar 09)
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]