RE: Procedural Issues
- From: "Vic N" <vic778@xxxxxxxxxxx>
- Date: Mon, 08 Jan 2007 16:44:09 -0800
<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
---------------------------------------------------------------------------
---------------------------------------------------------------------------
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
---------------------------------------------------------------------------
- Follow-Ups:
- RE: Procedural Issues
- From: WALI
- RE: Procedural Issues
- References:
- Procedural Issues
- From: WALI
- Procedural Issues
- Prev by Date: SF new column announcement: PHP apps - Security's Low-Hanging Fruit
- Next by Date: ISMS plan
- Previous by thread: Procedural Issues
- Next by thread: RE: Procedural Issues
- Index(es):
Relevant Pages
|
